As we already know the VMware vSphere Metro Storage Cluster (vMSC) Recommended Practices, we need to consider the vCLS VMs as well. The vCLS VM is a system component and there is a default datastore selection logic.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-6C11D7F9-4E92-4EA8-AA63-AABAD4B299E7.html
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-96BD6016-4BE7-4B1C-8269-568D1555B08C.html
A vSphere admin would like to place important system components for different and good reasons apart from his productive datastores. This requirement starts to get respected in version 7.0.3. System components like SRM or vSAN block their storage resources to avoid the placement of vCLS VMs on them.
On a blog about how to configure a non-uniform stretched storage according to the vMSC recommendations, we took an example based on DataCore SANsymphony.
https://cloudadvisors.net/2021/12/15/vmware-vsphere-ha-vsphere-metro-storage-cluster-vmsc-mit-datacore-sansymphony/
A key setting was the definition of dedicated datastores for heart-beating. Now, we add an additional datastore on each side with respect to the data locality principle. In total we see 3 non-mirrored datastores served by each SAN node to all ESXi cluster members. To guarantee the capacity, the thin provisioned SAN vDisk was configured with 100% reserved space. 20GB is not set in stone. You can configure a reasonable capacity. If this will no longer fit in later versions, feel free and increase the capacity without downntime. In our example this is a cool feature provided by the SAN vendor (DataCore – SANsymphony).
With such a configuration there are always enough datastores available for vCLS VMs and heartbeat datastores.
Sources:
https://www.yellow-bricks.com/2021/09/28/vsphere-7-0-u3-contains-two-great-vcls-enhancements/
https://kb.vmware.com/s/article/80472
Recent Comments