How to Choose an Availability Strategy for SQL Server on vSphere

When designing the architecture for your SQL Server virtualized on VMware vSphere, your requirements will determine which SQL availability or vSphere availability features you should use. There are several availability features packaged with SQL server before you even get to vSphere features like Distributed Resource Scheduler, High Availability, Fault Tolerance, or vMotion, each of which have their own considerations when interacting with SQL.

To get started, you’ll want to ask yourself a few questions about your SQL deployment.

• What am I trying to protect?
• Will my IT team abilities, licensing, Windows Server version, SQL server edition, or vSphere version have any effect on my availability strategy?
• What applications is the SQL server talking to?
• What are my Recovery Point Objective (RPO) and Recovery Time Objective (RTO)?

Because you have several options both at the SQL server level and the vSphere level, there are many ways to ensure availability. The main difference between the SQL and vSphere features is that vSphere focuses on protecting the entire VM, while SQL protects the data itself, usually with a point-in-time backup.

If you have a larger IT team with specialized administrators, some of your decision making may boil down to who you want managing the availability. Do you already have VMware administrators working on HA strategies and daily upkeep? Or do you want your SQL admins managing availability? In most cases, database administrators handle these duties, but they’ll have to work closely with your virtualization team to choose the ideal combination of SQL and vSphere availability tools.

One critical side note is that you can not deploy Availability Groups or failover clusters in SQL server without Windows Server configured as a Windows Server Failover Cluster (WSFC). Each VM participating in this cluster is known as a node. The amount of nodes possible depends on your version of Windows Server.