Clustering your SQL Servers can increase availablity for your databases but, first of all, it let´s you perform maintenance on your SQL Server without downtime. Database servers have a lot of dependencies and can be really tough to reboot in a production Environment. If you also have two VMware clusters running on separate hardware then you´re a few steps closer to full redundancy.
I´m currently working on a clustering solution on behalf of a client. Two virtual Windows Server 2012 R2 nodes with SQL Server 2012 on top of vSphere 5.5 and with shared iSCSI-storage on Netapp.
Clustering in a virtual environment is fully supported by Microsoft and VMware. Great! Then I found this kb article on the VMware knowledge base where you can find out the real truth. What do you know, DRS and vMotion is NOT supported. Everything will work as expected except that you won´t be able to move your VMs around between host.
Other things I have stumbled upon
- The paravirtual SCSI adapter (PVSCSI) is not supported in a Microsoft Failover Cluster (MFCS)
- Use separate disk controllers for your local drives.
- You cannot use Managed Service Accounts (MSAs or GMSAs) in a cluster.
- TempDb is now supported to run on local disk because it is flushed every time you restart the SQL Server service.
- Use mount Points instead of drive letters. Best practice is to create a separate disk that holds all of your mount Points and it doesnt have to be big. However, it must be over 3 Gb if one of the mount Points is were you will install the SQL binaries. The installer checks free space on the root disk and can´t see that your mounted disks, one step down in the tree structure, is large enough. I read in Microsofts documentation that mount Points are totally transparent. No, not really!
- Manage your shared disks through SnapDrive. ALWAYS! Do not remove disks in Failover Cluster Manager. If you do, you can look forward to a few extra hours of disk removal, cleaning up LUN mappings and starting over from the beginning with adding your disks (speaking from experience here).
- Sometimes the SQL Server installer can´t move your cluster disks to the SQL Server cluster role and stops with an error message and an incomplete installation. This requires an uninstall and a reboot of the Windows node your working on Before you are back on track. Create a new cluster role and choose “create empty role”. Rename it to “SQL Server (MSSQLSERVER)” which is the default name the installer would suggest. Now you can move your disks to the new role and next time you run the installer it will detect this and skip this part.
Read more in this article by Chandra550 (many thanks)
To be continued…