Updated VMware support policy on MSCS
August 2010 I wrote an article on support for Exchange CCR clustering on VMware with iSCSI.
VMware’s response then was very simple and straight forward. Exchange CCR clustering on VMware is not supported on iSCSI!
When asked if VMware had plans to change this support issue in the future the response was promising.
“The Exchange team within VMware requested the vSphere product team to support iSCSI for CCR and DAG clusters. They also would like to remove the RDM requirement for CCR and DAG.
Response from the product team is that they are testing and will update the support stance in a future release.”
Well, the future is now. I stumbled upon a VMware KB article, released May 5, which provides clear guidelines on the vSphere support status when running various Microsoft clustering solutions on VMware vSphere 4.
In short, Exchange CCR clustering on VMware with iSCSI is supported now.
Looking at the table the first thing I noticed was, that VMware distinguishes between Shared disk and Non-shared Disk.
- Shared Disk – data resides on the same disk(s) and the VMs share the disks
- Non-shared Disk – data resides on different disks and uses a replication to keep the data in sync (Exchange 2007 CCR).
For the purpose of this document, SQL Mirroring is not considered by VMware to be a clustering solution. VMware fully supports SQL Mirroring on vSphere with no specific restrictions.
- To avoid unnecessary cluster nodes failover due to system disk I/O latency , its virtual disk must be created using EagerZeroedThick format on VMFS volumes only regardless of the underlying protocol. This means that they cannot reside on NFS volumes;
- Shared storage must be attached to a dedicated virtual SCSI adapter in the clustered virtual machine. For example, if the system disk (Drive C:\) is attached to SCSI0:0, the first shared disk would be attached to SCSI1:0 and the data disk attached to SCSI1:1;
- The shared storage SCSI adapter for Windows Server 2008 must be the LSI Logic SAS type, while earlier Windows versions must use the LSI Logic Parallel type;
- Configurations using shared storage for quorum and/or data must be on Fibre Channel (FC) based RDMs. RDMs on other than FC are not currently supported;
- Virtual Disks used as shared storage for Clustered virtual machines must reside on VMFS datastores and must be created using the EagerZeroedThick option. This can be done by using the vmkfstools command from the console or the vSphere CLI or from the user interface. Note: VM must be powered off to perform this action;
- Using Round Robin PSP is not supported for LUNs mapped by RDMs used with shared storage clustering. If you chose to use Round Robin PSP with your storage arrays or if the vSphere version in use defaults to Round Robin PSP for the array in use, you may change the PSP claiming the above RDM LUNs to another PSP.
Configurations using non-shared storage clustering do not require additional VMware considerations regarding specific storage protocol or number of nodes and can be deployed on virtual just like on physical.
One last thing to keep in mind when using third party multipathing plugins. When using N+1 cluster configurations where physical machines are backed by nodes in virtual machines, the physical node cannot be configured with multipathing software.
- StarWind compared to VMware and Hyper-V by Sander Martijn
- What’s new in vSphere 6 Storage by Erik Scholten
- What’s new in vSphere 6 Availability by Erik Scholten
- Webinar: How to build Microsoft Scale-Out File Server by Sander Martijn
- MS SQL high availability support for vRealize Automation by Erik Scholten
The founder and driving force behind VMGuru. With over 20 years experience in IT, he now works as a Cloud Management Specialist at VMware Benelux. He worked as technical consultant, pre-sales and solutions architect for several systems integrators.
He’s a long time VMware VCP, VCP Desktop, VCA, VSP and VTSP, vExpert Cloud (2017) and 9 year vExpert (2009 – 2017).