Brainbugg
vSAN has its own network. If
vSAN and vSphere HA are enabled for the same cluster, the HA interagent traffic flows over this storage network rather than the management network. vSphere HA uses the management network only if vSAN is disabled. vCenter Server chooses the appropriate network if vSphere HA is configured on a host.
Read this blog for more details on ROBO and Stretched cluster since the settings would remain same for both:
https://cormachogan.com/2015/09/16/vsphere-ha-settings-for-vsan-stretched-cluster/
Specifically this:
Note: If there is a host failure, the virtual machines that reside on this host will be restarted on the remaining hosts in the cluster. However, the recommendation is to have vSphere HA restart the virtual machines on hosts on the same data site, and not have them restarted on the other data site.
The reason for this is that if there was a failover to the other site, the virtual machines would read from the local copy of the data on the remote site and thus will have to rewarm their cache on that site, so there will be a temporary performance dip. We want to avoid this by keeping VMs on their selected site as much as possible, and thus using the local copy of the data and cache on that site.
VM/Host affinity groups and rules should be created to achieve this, and these rules should be “soft”. By being “soft” or “should” rules, it means that all attempts are made to restart the VMs on the local site, but if that is not possible (e.g. full site failure), then the “soft” rules can be broken and the VMs may be restarted on the other site.I will delve into this in greater detail in a future post, as it plays an important role in VSAN stretched cluster.
For regular 4 node vSAN; settings would remain defaults. The non-defaults from the blog would apply simply to Stretched and ROBO.
One example would be isolationaddress1 which is not required on a regular vsan cluster.
