On the community forums, a question was asked around the use of site locality in a vSAN Stretched Cluster. When you create a stretched cluster in vSAN you can define within a policy how the data needs to be protected. Do you want to replicate across datacenters? Do you want to protect the “site local data” with RAID-1 or RAID-5/6? All of these options are available within the UI.
What if you decide to not stretch your object across locations, is it mandatory to specify which datacenter the object should reside in?
The answer is simple: no it is not. The real question, of course is, would be: should you define the location? Most definitely! If you wonder how to do this, simplicy specify it within the policy you define for these objects as follows:
The above screenshot is taken from the H5 client, if you are still using the Web Client it probably looks slightly different (Thanks Seamus for the screenshot):
Why would you do this? Well, that is easy to explain. When the objects of a VM get provisioned the decision will be made per object where to place it. If you have multiple disks, and you haven’t specified the location, you could find yourself in the situation where disks of a single non-stretched VM are located in different datacenters. This is, first of all, terrible for performance, but maybe more importantly also would impact availability when anything happens to the network between the datacenters. So when you use site locality for non-stretched VMs, make sure to also configure the location so that your VM and objects will align as demonstrated in the below diagram.
Hi Duncan,
The other factor to consider here is that some services don’t require that level of availability in the platform itself. They are themselves inherently available – think Domain Controllers etc. There would be little point in replicating their data between sites.
The way I tend to look at things like stretched clustering is that it’s infrastructure making up for availability shortcomings in the applications.
Oh I get that, this post wasn’t about the use case, more about the options you have when configuring and why you should select a site.
So, if one creates a policy with “None – keep data on Preferred (stretched cluster)”, then the data will reside in the fault domain that is set to preferred?
In our stretched cluster, site A is set as the preferred fault domain.
We do have a number of virtual machines with policies that “stretch” them between site A and B, i.e. PFTT = 1.
However we also have virtual machines with a storage policy that is set to “None – keep data on Preferred (stretched cluster)”, i.e. PFTT = 0. These virtual machines also have a “should” DRS rule that keeps the virtual machines running on hosts located in site B.
Two questions based on the above:
1. Does this mean that those VMs running in site B with “None – keep data on Preferred (stretched cluster)”, are actually having their reads and writes served from site A?
2. To expand on the above question, for the VMs that are “stretched” between both sites with PFTT = 1, where does their reads get served from? Would it be the host that they are running on (and the site they are currently located in)?
Sorry for the slow response, hadn’t noticed this question.
1. Correct, ALL reads and write will go across the network. And if the connection between sites fail the VM also has a huge problem. I would recommend against this configuration.
2. For any VM that is stretched, reads will always be served from the local fault domain. vSAN keeps track of this for you and will ensure that reads will come from the local fault domain.
I seem to be getting different answers from VMware Support depending on who I speak too.
We are running the GA release of vCenter 6.7 along with 6.7 ESXi.
So just to confirm, in your understanding …
In a stretched VSAN cluster, with PFTT=0, and a preferred site being configured, VMs in BOTH site A and site B, will have their reads/writes coming out of the preferred site?
I will send you an email Glenn, but I can guarantee you that what I am stating is accurate.
a question about site locality and a backup proxy (like used with Avamar)
example:
Stretched cluster (4 nodes per site)
Site A (preferred site)
Site B (secondary site)
Storage policy used
“None – standard cluster”
PFTT = 1
Data locality = none
VM1
running at Site A
VM3
running at site B
VM3 (Avamar proxy)
running at Site B
as attached a snapshot from VM1 , to backup to Avamar
1) is this a recommended storage policy for our setup?
We want to protect our VMs only against a Site failure, and keep read/writes inside the Site were the VM is running.
2) VM1
read and writes are served from the local Site A, Site B, or both Sites?
3) VM2
read and writes are served from the local Site B, Site A, or both Sites?
4) VM3
the attached snapshot from VM1, where are the read served from local Site B (local for VM3), Site A or both Sites?