As a Virtualization Engineer, we must have a solid understanding of all the Core pieces that make up a Virtual Infrastrucutre, from Network, Storage, Compute and OS Layers. From my experience, it’s clear that the Microsoft Core product set is equally important and VMware seems to think so dedicating an entire Partner Competency (VBCA) around some of these products. SQL, Exchange and SharePoint are common in customer environments today and are traditionally at the center of business serving applications, data warehousing, and collaborative functions.
It’s no secret that SQL is very popular, in fact, 90%+ of my vSphere Implementations have SQL as the db of choice. For this very reason, i’m picking up where I left off in 2002-2003, and getting back into the Microsoft learning/certification mode.
SQL has come a long way with functionality, especially around protection. There are many ways to build a resilient SQL Environment, from Failover Clustering, Database Mirroring, Log Shipping, and now Always On Availability Groups. I will also point out that in some cases you can use a combination of these Technologies to tackle not only SQL resiliency but also SQL Node resiliency as well.
For the sake of this article, we will be focusing on SQL 2012 SP1 Always On Availability Groups. Straight from Microsoft: The Always On Availability Group feature is a high-availability and disaster-recovery solution that provides an enterprise-level alternative to database mirroring. Introduced in SQL Server 2012, Always On Availability Groups maximizes the availability of a set of user databases for an enterprise. An availability group supports a failover environment for a discrete set of user databases, known as availability databases, that fail over together. An availability group supports a set of read-write primary databases and one to eight sets of corresponding secondary databases. Optionally, secondary databases can be made available for read-only access and/or some backup operations.
You can see in the previous diagram we have a Windows Server Failover Cluster containing five nodes, each with it’s own SQL Server Instance Install. In this example there is an Availability Group called ‘MyAG’ which contain the set of Database Primary and Secondary Replicas.
In our use case, we will not be using Shared Storage. Each SQL Instance Storage will be provided via .vmdk’s, in essence, local disks to the guest OS (Windows Server 2012 R2). We will be using Windows Server Failover Clustering to manage the single cluster namespace only. We will not be using Windows Server Failover Clustering for SQL Instance Resiliency but Availability Groups providing database granularity replication and protection.
Let’s get into the use case. SMP (my place of employment) has a rather nice Demo/Test Environment called the Solution Center. The Solution Center is made up of two primary Datacenters, and two “ROBO” instances, one connecting to each Datacenter. The two Datacenters are broken down by our Core Partners, one Datacenter Housing Cisco/EMC/VMware products, the other housing Dell/VMware products. The ROBO that connects to the Cisco/EMC/VMware Datacenter is made up of a vBlock 100. The ROBO that connects to the Dell/VMware Datacenter is made up of a VRTX.
These environments are housed in a single building, and simulating separate Datacenters, however, for ease of manageability, and movement of Virtual Machine Workloads, they share common Layer 2 networks and Domain/DNS and as you can imagine the connectivity between the two is robust.
Since our goal is to be able to demonstrate and test VMware’s products, you can imagine we have quite a bit of these products and many versions installed, however they were sitting on a Single Database within the environment. As we looked through the Solution Center Architecture this was identified immediately as the highest risk which needed to be addressed.
Now, let’s get to the “elephant in the room” so to speak. You’re probably saying to yourself, “they can’t use Always On Availability Groups with vSphere, it’s not supported. Only Microsoft Clustering was just announced as supported with vSphere 5.5.”
Let’s look at the KB article a bit more in depth shall we? I also want you to keep in mind that this is a Demo Environment and not Production and in no way would I recommend this in a Production Environment.
The wording in the above KB article clearly states:
- MSCS (Microsoft Cluster Services)
- Microsoft SQL Server 2012 AlwaysOn
- VCS (Veritas Cluster Services)