VMware Cloud Community
AlbertWT
Virtuoso
Virtuoso
Jump to solution

Deploying SQL Server cluster Always On without using Shared disks, physical RDM and SCSI bus sharing

Hi Everyone,

I need some suggestion to deploy 2x SQL Server Enterprise node VMs (Always On HA - MSCS), so that it does not use Shared disksphysical RDM and SCSI bus sharing in VMware.

I wonder what will be the consequences without using the Shared disks, physical RDM and SCSI bus sharing apart from that it can be backed up with backup software like Veeam Backup & Replication?
Requirements and Limitations - Veeam Backup Guide for vSphere 

Thanks in advance.

/* Please feel free to provide any comments or input you may have. */
Labels (3)
Reply
0 Kudos
1 Solution

Accepted Solutions
pdirmann01
Enthusiast
Enthusiast
Jump to solution

I typically go with File Share Witnesses. To me it avoids the "complexity" of shared disks at the VM level. It also doesn't limit your vMotion capabilities like shared disks could. I'll also always recommend to use the pvSCSI controller where possible. You can't really see it in the snapshots, but those VMs are maxed out with 4 pvSCSI controllers - 1 for OS, page file, SQL level backups, and SQL binaries, the second has SQL MDFs, third has SQL logs, and the 4th has TempDB. 

View solution in original post

4 Replies
pdirmann01
Enthusiast
Enthusiast
Jump to solution

SQL Always On Availability Groups do not make use of shared disks at all, unless you make use of a quorum disk over a file share witness (I'll always opt for the file share witness). In fact, they have stand alone copies of the data. That is actually one consequence - you are doubling (or Xing, where X is however many nodes you put into the AOAG) your data consumption. 

From a VMware's perspective, they are just two normal, independent guests. Veeam can back them up just as a normal VM with snapshots, unlike when they are shared with physical bus sharing enabled (where you would need to use an agent). From the vCenter side, you'd want to put in an Anti-Affinity rule to separate them onto different hosts in the event of a failure. Here's some snippits from a geographically-dispersed cluster that I recently deployed just to show you that they are different disks on different datastores (in different data centers). Let me know if you need some further detail behind this.

pdirmann01_1-1619211931219.png

 

 

AlbertWT
Virtuoso
Virtuoso
Jump to solution

@pdirmann01 thank you for the detailed sharing of the VM configuration. Yes, the existing cluster is Failover Cluster Instance(FCI) using Quorum:

AlbertWT_0-1619273492196.png

Hence the Veeam backup created the 3PAR Storage Array Snapshot that always stuns this VM which has caused failover after every successful Veeam backup. I wanted to avoid this one from happening, hence the only solution is installing the Veeam Endpoint Backup agent.

So I assume, your cluster also using Quorum disk like in the above screenshot?

Did you deploy the VMs using the pvSCSI for the SCSI controller?

/* Please feel free to provide any comments or input you may have. */
Reply
0 Kudos
pdirmann01
Enthusiast
Enthusiast
Jump to solution

I typically go with File Share Witnesses. To me it avoids the "complexity" of shared disks at the VM level. It also doesn't limit your vMotion capabilities like shared disks could. I'll also always recommend to use the pvSCSI controller where possible. You can't really see it in the snapshots, but those VMs are maxed out with 4 pvSCSI controllers - 1 for OS, page file, SQL level backups, and SQL binaries, the second has SQL MDFs, third has SQL logs, and the 4th has TempDB. 

AlbertWT
Virtuoso
Virtuoso
Jump to solution

That's great, thank you @pdirmann01 for your explanations 🙂

/* Please feel free to provide any comments or input you may have. */
Tags (1)
Reply
0 Kudos