- VMware Enhanced Authentication Plug-in—Why do we still need it with vSphere 7.0? - Fri, Jul 3 2020
- VMware VCSA 7 backup - Fri, Jun 26 2020
- vSphere 7.0 unsupported CPUs and ESXi 7.0 hardware requirements - Fri, Jun 12 2020
Before, you had to use RDMs in order to configure and use WSFC. Now, with vSphere 7.0, you can enable support for clustered VMDK in a datastore. This provides some advantages, but it also entails many requirements.
The WSFC support is valid for Microsoft Cluster Service, WSFC, and Microsoft SQL Server Always-On Failover Cluster Instances.
Note that SQL server Always On Availability Groups or Exchange Database Availability Groups do not require special storage configurations, such as clustered VMDK support. So these solutions can be used on traditional VMFS or NFS datastores without special storage configuration.
This VMware solution is supported by VMware from a vSphere perspective, but also from Microsoft's side when the Windows Server 2012 and higher OS must be used.
We'll look at the requirements below. One of them is the fact that you can use shared VMDKs only with an array that is connected via fiber channel (FC). This requirement eliminates many arrays connected via ethernet.
Shared VMDK requirements ^
- A fiber channel array only.
- The array must support ATS, SCSI-3 PR–type Write Exclusive–All Registrant (WEAR).
- The datastore must be formatted with VMFS 6 (VMFS 5 is not supported).
- VMDK must be Eager Zero Thick (no thin provisioned VMDKs).
- If you have DRS configured in your environment, you must create an anti-affinity rule so that the VMs can run on separate hosts.
- vCenter server 7.0 and higher.
- Snapshots, cloning, and storage vMotion are not supported (no backup of nodes is possible, because backup software uses snapshots).
- Fault tolerance (FT), hot change to the VMS virtual hardware, and hot expansion of clustered disks are not
- vMotion is supported, but only for hosts that meet the same requirements.
Enable Clustered VMDK support on a datastore ^
The clustered VMDK is configured on a per-datastore level. So if you have different arrays connected to your cluster, be sure to create and configure only the correct datastore. As of this writing, only FC storage arrays is supported, but VMware is working on supporting other types of arrays as well.
Here are the steps:
Open the vSphere client, go to Storage, and choose the correct datastore.
Right-click the parent object and select Create a New Datastore.
Follow the assistant to create a datastore by selecting VMFS 6 format and the default partition settings.
Once you have created the datastore, go to Storage view > Select > Configure > General > Datastore capabilities > Clustered VMDK > Enable and click on Enable.
VM-creation workflow ^
VM-creation workflow consists of creating a new VM and changing an SCSI bus-sharing configuration option to Physical.
Add a new SCSI controller. Choose the recommended one, VMware Paravirtual. In our case, SCSI Controller 1 is created and added to the VM.
Add the new VMDK formatted with Eager Zero Thick (EZT) and store this VMDK on the new datastore that you have just created. Then assign the new VMDK to the SCSI controller.
The overview of the virtual hardware looks like this. Note that we do not use the Multi-writer parameter for our clustered VMDK datastore.
Note: The boot disk (and all unshared disks) should be attached to a separate virtual SCSI controller with bus sharing set to None.
Create additional VM nodes ^
Here are the steps for the second VM, which will be the second node of the cluster and will use the existing disk that we created for the first node (remember, you can have up to five nodes):
Create a second VM > Assign resources, CPU and memory > Select ESXi host > Click OK to finish the wizard.
Add a new virtual SCSI controller (again using the recommended VMware Paravirtual).
Set the SCSI bus-sharing option of that controller to Physical > Point to an existing VMDK from the first node (you will use the Add an Existing Hard Disk option).
Now assign the VMDK to the new vSCSI controller that you created before. You should use the same SCSI IDs (virtual device node) when assigning disks to all additional nodes.
VMware Kb article 2147661 can give you further help when you are creating and configuring Microsoft WSFC on VMware vSphere.
Other requirements and limitations:
- You cannot mix clustered and unshared disks on a single virtual SCSI controller. It is unsupported.
- Mixing clustered VMDKs and other types of disks (vVOLS, pRDMs) is not supported either.
- A maximum of five nodes are supported.
- The maximum number of clustered VMDKs per host is 128.
- Cluster across box is supported (but Cluster-in-a-Box is not supported).
Final words ^
VMware has added many small and big features in vSphere 7.0. Although most use cases of architectural decisions were possible in previous releases of vSphere, for some use cases, options were missing or unsupported. VMware Clustered VMDK provides support at the datastore level.
For example, this is true of Virtual Hardware 17, new in vSphere 7.0, which has brought support to Virtual Watchdog Timer, enabling guest OS monitoring of multi-VM applications.
VMware does not recommend using a cluster-enabled VMDK datastore for storing unclustered VMDKs; nevertheless, it is a supported configuration.
Clustered VMDK datastores with vSphere 7.0 are an evolution of the configuration that gives enterprise architects more ways of building Microsoft WSFC environments.