VMware vSAN continuously enhances the feature set to provide the best-hyperconverged infrastructure (HCI) to host virtualized Microsoft SQL Server (SQL Server) workloads. In addition to the long-existing capabilities to host SQL Server Always On Availability Groups or to provide support for iSCSI targets, the new feature, recently introduced in VMware vSAN 6.7 Update 3, – SCSI-3 Persistent Reservations (SCSI3-PRs) native support – makes it possible to host SQL Server Failover Cluster Instances on WSFC on VMDK on vSAN.
SCSI-3 Persistent Reservations (SCSI3-PRs) native support on VMware vSAN
SCSI3-PRs native support enables customers to create a new or move an existing Windows Server Failover Cluster (WSFC) with up to 6 nodes and 64 shared disks to VMware vSAN backend VMDKs. SCSI3-PRs commands, used by WSFC to claim the ownership of a shared disk, are transparently passed to a VMDK and are arbitrated on the vSAN layer to simulate a dedicated LUN. To facilitate the ability to use direct SCSI commands, it’s required to set the SCSI bus sharing on a vSCSI controller of a VM, node of a cluster, hosting clustered VMDK(s), to physical. It’s recommended to set an Independent-persistent mode for all clustered disks to exclude them from snapshots. Consult this great technical article for more details on how to prepare vSAN for a WSFC deployment.
With the release of vSphere 7.0 support for shared VMDKs for WSFC is now available for on-premises VMware vSAN, clustered VMDKs on VMFS, and VMware Cloud on AWS.
Note: You might see references on the Internet suggesting using the multi-writer feature in conjunction with WSFC. Please be advised that the multi-writer feature must not be used for a clustered disk resource for WSFC.
Migrating existing WSFC to VMware vSAN
For many customers actively using or just planning to use VMware vSAN the question “how to migrate my current clustered SQL Server workload to vSAN platform” is a key in the journey to adopt an HCI solution. VMware supports the ability to cold migrate SQL Server FCI configurations using physical RDMs (regardless of the underlying storage protocol – FC, iSCSI or FCoE) to VMware vSAN. The migration does not require complex operations and consists of the following steps:
- Preparing a WSFC cluster hosting SQL Server FCI with physical RDMs for a cold migration – you need to shut down the WSFC cluster and power-off all nodes of the cluster;
- Executing cold migration of the first node of the cluster to a datastore backed by vSAN (vSAN 6.7 Update 3 is required). During this step physical RDM(s) will be converted to VMDK(s) on VMware vSAN;
- Migrating of other nodes, if non-shared disks should be migrated as well. Before the migration, all VMs hosting remaining (non-migrated) nodes of the cluster should be reconfigured: shared pRDMs should be removed from the VM configuration;
- Adding back clustered disk resources using VMDKs from the first migrated VM;
- Validating cluster functionality and starting the cluster on VMware vSAN;
- Applying configuration and performance optimization recommendations for SQL Server workloads and vSAN.
Refer to the document SQL Server Failover Cluster Instance on VMware vSAN™ Native for more technical details and the enhanced migration procedure.
Summary
Support for SCSI3 persistent reservations and the ability to host WSFC on VMware vSAN provides flexibility and adds design choices for customers looking to host high available SQL Server solutions on the hyper-converged infrastructure. This blog article and the migration document provide all necessary technical details and guidelines on how to prepare, create or migrate, and maintain a SQL Server Failover Cluster Instances on VMware vSAN.
This blog post would not be possible without all the hard work done by Tony Wu (Sr. Solution Architect, Storage Product Marketing, VMware Inc).
