My buddy Pete Koehler put together a good post a few days ago about SPBM Policies with vSAN Stretched Clusters: vSAN Operations: Use separate SPBM policies for VMs in stretched clusters
In that post, he covers definition changes from Number of Failures to Tolerate (FTT) which was available in pre vSAN 6.6 builds, to Primary Failures to Tolerate (PFTT) in vSAN 6.6 and higher. This change was added to address the addition of local protection within a Stretched Cluster. This is accomplished using the secondary rule, Secondary Failures to Tolerate (SFTT), to determine the local protection within a Stretched Cluster Fault Domain (Preferred or Secondary). Pete covers this in the above post.
A question came up last week specific to the behavior of a VM’s swapfile in vSAN when using vSAN Stretched Clusters. There has been some confusion with my documentation on StorageHub, which I’m currently updating, but I wanted to post something specific to how a VM’s swapfile behaves.
I’ve setup a Stretched Cluster with a single VM on it for a little clarity. Once site is “Denver” and one is “Colorado Springs” in my demo environment. Since I’ve moved to CO, I figured I’d use some naming that has local flair.
Pre vSAN 6.6 Stretched Cluster Behavior (vSAN 6.1, 6.2, & 6.5)
In vSAN Stretched Clusters before 6.6, each object had 1 component in each Fault Domain (Preferred/Secondary) and a Witness component on the vSAN Witness Host. *If an object is greater than 255GB in size, it will be broken into multiple components (on each site) for every increment of 255GB.
Here’s a standard policy for Pre-vSAN 6.6 Stretched Clusters: