• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

Site locality in a vSAN Stretched Cluster?

Duncan Epping · May 28, 2019 ·

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.

 

Related

Server 6.7, u1, u2, virtual san, VMware, vmware vsan, vsan

Reader Interactions

Comments

  1. Ben Tanner says

    28 May, 2019 at 18:50

    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.

    • Duncan Epping says

      29 May, 2019 at 10:39

      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.

  2. GL says

    5 June, 2019 at 11:54

    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)?

    • Duncan Epping says

      12 June, 2019 at 09:18

      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.

      • Glenn says

        12 June, 2019 at 09:53

        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?

        • Duncan Epping says

          12 June, 2019 at 12:52

          I will send you an email Glenn, but I can guarantee you that what I am stating is accurate.

  3. Geert says

    10 July, 2019 at 12:55

    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?

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007), the author of the "vSAN Deep Dive", the “vSphere Clustering Technical Deep Dive” series, and the host of the "Unexplored Territory" podcast.

Upcoming Events

May 24th – VMUG Poland
June 1st – VMUG Belgium

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2023 · Log in