Do you have any Raw Disk Mappings (RDMs) in your environment? If so, you might want to learn more about Clustered VMDKs.
Clustered VMDKs vs RDMs
Before Clustered VMDKs, clients would have to use RDMs to present a shared disk between VMs. RDMs were basically LUNs passed directly through the ESXi host to the Virtual Machines. The cluster software then handled writes and locking directly with the SAN. You could abstract the interactions a bit more by using Virtual Raw Disk Mappings (vRDMs), but the gist of the issue was a single logical unit number (LUN) per disk. This made managing RDMs a bit cumbersome.
With the release of vSphere 7.0 in March 2020, VMware introduced Clustered VMDKs. This enabled a special type of datastore that allowed for shared VMDKs to live on it. This allowed clients to create multiple VMDK files on a single LUN and allow multiple VMs to access them simultaneously. VMware would handle the file locking and read/write orders. The main advantage, in my opinion, is the easy manageability of the VMDK file and associated LUNs. Overall, the solution is a lot less complicated.
Requirements
Now that we know we want to use them, what are the requirements? First, all hosts connected to the clustered VMDK datastore must be on ESXi version 7.0 or higher and managed by the same vCenter instance. The Virtual Machine File System (VMFS) version must be 6 and there is a special cluster attribute that must be enabled. If you are still running 6.x, you will need to upgrade, and you should regardless, since it is now out of support.
You will also need to run on Fiber Channel storage. Pure Storage is one of the vendors that we recommend, but if you are still running iSCSI, you will need to stick with either VVols or RDMs for now. The storage array will need to support SCSI-3 reservation type WEAR, but it’s been my experience that most do. The vSphere UI will verify support when you try to enable the Cluster flag.
Once you have the storage presented to the ESXi hosts and the datastore created, it is just a simple matter of creating your VMs with shared VMDKs. Keep in mind, any Windows Server Clusters created will require DRS Affinity Rules to separate the VM nodes to different ESXi hosts. Cluster in a Box is not supported.
Another requirement is that the VMDK will need to be formatted in Eager Zeroed Thick and connected to a separate SCSI controller on the VMs. The controller requirement is similar to RMDs and VVOLs. Like these other situations, you will need to set the controller to Physical mode.
Some of the limitations of implementing VMware Clustered VMDKs that you should keep in mind are actions like snapshots, cloning, and storage vMotion are not supported as of this writing. This means backup of nodes at the VMware layer is not possible because backup software typically uses snapshots. Also, there's a maximum of five VM nodes in a Windows Cluster but I haven’t had that come up as a roadblock yet.
Hopefully you see the benefits of Clustered VMDKs and if you have RDMs, you look to migrate them over for a much easier management experience.
Until next time, Happy Virtualizing!
Carlo