March 1, 2024

vSAN 6.7 U3 – WSFC with Shared Disks & SCSI-3 Persistent Reservations

In vSAN 6.7 we introduced Windows Server Failover Cluster (WSFC) support when using vSAN iSCSI Service. This support is for physical or virtual WSFC nodes. This feature made it very easy for customers who needed block devices for WSFC clusters that use shared disks.

Customers that moved much of their infrastructure to vSAN, could still provide block storage to physical systems that they weren’t yet ready to virtualize. WSFC nodes that had been virtualized could still use the same iSCSI-based block devices.

With vSAN 6.7 Update 3, we now support using shared vmdks with virtualized WSFC cluster configurations. This removes the additional configuration tasks associated with iSCSI presented storage and networks. This is possible with the addition of SCSI-3 Persistent Reservations (SCSI-3 PR) support in vSAN 6.7 Update 3.

SCSI Reservations & Shared Disks

When different hosts, or guests in the case of virtual machines, share a common disk, SCSI protocols ensure that only one of the systems has the ability to update metadata. SCSI reservation support allows multiple nodes accessing a device, while blocking other devices.

SCSI reservations supported in the SPC-2 specification provided persistent reservations as well as reserve and release functionality. These were independent of each other and had some of their own limitations when compared to the SPC-3 specification where SCSI-3 PR was introduced.

Some of the enhancements introduced in SCSI-3 PR, included the ability to persist reservations across host restarts, the ability to have reservations with multiple paths, as well as more resilient behavior from host or connectivity failures. This provides better performance and availability, while reducing the overall risk of potential data corruption.

SCSI-3 PR for WSFC with Shared Disks

Windows Server 2008 introduced the requirement for SCSI-3 PR, departing from the use of SCSI-2 Reserve/Release in Windows Server 2003.

Storage systems must be able to support native SCSI-3 PR to support Windows Server Failover Clusters (WSFC) in a shared disk configuration. This can include WSFC installed on bare metal systems with shared storage, WSFC installed in a virtual machine using shared storage, or in some cases a combination of physical & virtual machines sharing storage. Raw Device Mappings (RDMs) or virtual disks (vmdks) can be used in different supported configurations.

VMware KB 2147661 addresses the supported configurations when using RDMs or when using vmdks on vSphere. Support for running WSFC clusters using shared disks with vVols was introduced in vSphere 6.7.

WSFC with Shared Disk support on vSAN

vSAN 6.5 introduced the ability to provide iSCSI-based block services for non-vSAN workloads. This was validated to support WSFC shared disk configurations with the release of vSAN 6.7.

These shared disks are presented to Windows, not to a virtual machine. These vSAN-backed iSCSI LUNs do have the benefit of being able to use Storage Policies to adjust performance and protection characteristics of the shared disks consumed by the WSFC cluster. In comparison the lifecycle management of RDMs can be tedious and inconsistent across multiple generations or vendors of different storage systems.

vSphere 6.7 simplified the deployment of shared disks for WSFC on supported vVols-based storage, removing the requirement for RDMs. Performance and protection storage policies can be easily selected upon deployment, or adjusted over time, based on the policies supported by the underlying non-vSAN storage.

vSAN 6.7 Update 3 expands WSFC with shared disk support to include native vSAN-based shared disks for virtualized WSFC clusters. This brings all the storage policy-based management capabilities to WSFC shared disks on vSAN, without the need for external vVols-backed storage. It also enables better storage mobility between vSAN and vVols-backed storage for customers who have embraced software-defined storage.

WSFC configurations using physical hosts or virtual machines residing on different vSAN clusters, still require using the vSAN iSCSI service for shared disks.

This was originally posted on the VMware Virtual Blocks site: