Since VMware allows use of RDM disks to setup a Windows cluster using VMs, which can be used to install SQL cluster, we decide to go this route.
However, now after installing the Windows cluster, I am finding out that you cannot do snapshot of these VMs due to shared disks (physical RDM, as recommended). This also means you cannot do Veeam or other backups.
We, of course, can do OS and SQL server backups, but restore from them will be quite time-consuming in a disaster. SAN level backup will require purchase of separate expensive software for just 2 VMs.
To me this is a very serious limitation of using VMs to create a Windows/SQL cluster. If I go with a single VM SQL server, I will still avoid single-point hardware failure due to VMware HA. Only disadvantage will be some down-time when server needs to reboot, for Windows updates, etc. This is a very minor inconvenience, compared to not having any VM-level backups. (There is hardly any difference in performance of RDM vs VMFS.)
Am I missing something? Is my conclusion wrong? Please share your experience and/or viewpoints. Thanks.
Jay Kulsh
for the vast majority of workloads HA based resilience may in fact be good enough, in fact as SQL Cluster failover is not instantaneous, I too feel that it is an unnecessary complexity, when working in a virtual environment, however if you have Enterprise plus licenses and a 10GB infrastructure (also the necessary extra 10GBe ports) you could gain instantaneous recovery and failover by using Fault Tolerance. with Ent+ licensing you can do 4 CPU SMP on your SQL server.
Tom, Thanks for reply. Can "4 CPU SMP" mean 4 sockets? Most SQL servers need multiple cores. We need 2 sockets with 8 cores each -- a total of 16 cores. Can that be done in FA configuration? Thanks.
Jay
no it means four vCPU's, either a VM with 4 vCPU's, a dual vCPU with 2 Cores or a single vCPU with 4 cores.
It has no relevance to the underlying physical CPU set
Hi ,
Only for two vms you don't need to buy another backup solution , as a workaround you can configure SQL database backups (configured on sql level )to shared location and take a vm backup of that one .
I am not sure if FT will be a good option if the SQL servers are quite IO intensive and heavy resource utilization.
Also if an environment has multiple SQL environments, it adds to the resource utilization.
while budgeting one should also consider the SQL licences
This is a design decision, do you go tall and build a couple of very large SQL servers and host many instances or do you go wide and build multiple single/small use SQL: servers? both are valid positions and this decision depends on your Users requirements. FT is just a tool and has its uses, it also has it's constraints and pre-reqs too.
I'm far from an expert in SQL Clustering, I frankly don't like the idea of clustering anything at the OS level when there's HA available at the host level but I have had to set it up before. I never mess with RDMs due to the snapshot issue, just thick eager VMDKs. Last time I did a MS cluster with SQL was using three Server 2012 R2 VMs, two running SQL server and a third was strictly as an iSCSI target role, the SQL db itself sat on this shared storage iSCSI target server and all VMs sitting on RAID-10.