VSAN Stretched cluster - query on HA Isolation address and drs settings for VMs with local storage

[anandgopinath]

Dear Community 

 We have a stretched cluster as below.

We have a couple of queries related to HA Settings  &  DRS Rules to be set for some VMs pinned to specific fault domain storage. 

Appreciate your quick response  . 

============

On both Data nodes ,

we have the management VMK now having 2 tags management + vsan witness and having management vlan x ip

we have the VSAN VMK with just vsan tag with default gateway ( as gateway does not matter since network is l2 stretched ) having vsan data vlan y ip

On the witness,

we have management vmk0 having management tag and having management vlan A ip

we have the vsan vmk1 with vsan tag and having the vsan witness vlan z ip ( routable with vlan x )

==========

1. For the HA settings , is it ok if we just set a single HA isolation address ( ie gateway of vlan y ) via das.isolationAddress0 instead of the 2 recommended by VMWARE ?

2. We plan to pin some VMs to specific Fault domains via the below vsan policy settings . Our requirement is that in case of a planned maintenance activity ( other than disk failure ) , we are able to move the VM storage to the other site temporarily .

For such VMs, which type of DRS rules is recommended ? Should or must ?

Site disaster tolerance None - keep data on Secondary (stretched cluster)
Failures to tolerate No data redundancy

Site disaster tolerance None - keep data on Preferred (stretched cluster)
Failures to tolerate No data redundancy

[depping]

VMware recommends to set 2 isolation addresses so that if a double failure occurs the isolation address is reachable. It is perfectly fine to set 1 isolation address if that isolation address is always available in both locations of the stretched cluster.

When it comes to the VMs you are not replicating between locations there are a couple of things to consider:

1. if the VM isn't replicated and you do a full site maintenance, than vMotion is useless as the storage components would be useless
2. MUST rules are NEVER violated, so should rules are probably more useful if you ever want the VMs to be moved to the other location.

[anandgopinath]

@depping  . Thanks for the quick help  . much appreciated

I am still a bit lost on the VMs pinned to each site 

Please can you confirm if my below understanding is correct  w.r.t the 2 scenarios ? 

 VMs pinned to One site with  "Must" rules 

==============================

  VM to be recovered from backup during  disk / diskgroup failure 

  If disks are intact and the host / site goes down , VM to be available once the site is available again 

For planned events , disable must rules and change VM policy  to point to the other site site  storage and vmotion VM to other site 

2.   

 VMs pinned to One site with  "should" rules 

==============================

  VM to be recovered from backup during  disk / diskgroup failure 

  If disks are intact and the host / site goes down , VM to be available once the site is available again 

For planned events ,  change VM policy  to point to the other site site  storage and vmotion VM to other site 

[depping · Accepted solution]

• correct, if hosts are back up then the VMs would also be available again.
• yes, that would work, if you disable the rules and change the policy then a normal vmotion would work even, you don't need storage vmotion, as the storage would already be resynced to the other location via vSAN

hope that helps

[anandgopinath]

@depping  :  Thanks Alot  once again 

Proud to be part of this great Community  ..