SQL 2012 Always On Availability Groups on vSphere 5.5U1 Part 1: Overview


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.

Capture-WSFC-SQL-AG

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.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1024051

The wording in the above KB article clearly states:

You may choose to protect VMware vCenter Server using third-party clustering solutions including, but not limited to: 
 
  • MSCS (Microsoft Cluster Services) 
  • Microsoft SQL Server 2012 AlwaysOn
  • VCS (Veritas Cluster Services)
VMware does not certify these third-party solutions. VMware will offer best effort support for any issues encountered with an environment that uses third-party solutions for protecting against VMware VirtualCenter downtime. However, if your issue is determined to be related to the third-party clustering solution, VMware will refer to our third-party software policy. For more information, see the VMware third-party hardware and software support policy.
 
VMware is not stating that they won’t support you if you use these technologies, however, it falls back to a “best effort” support model.  I would recommend that you hold off on using Always On Availability Groups until VMware explicitly calls it out like they did for WSFC:
 
As of vCenter Server 5.5 in vSphere 5.5, VMware introduced support for using Microsoft SQL Cluster Service for use as a back end database. Previously, using Microsoft SQL Cluster was not supported for any version of vSphere. For more information, see Enabling Microsoft SQL Clustering Service in VMware vCenter Server 5.5 (2059560).
 
Over the course of the next couple of days, I will be releasing a series of articles continuing through this process. The articles will be broken down into a few sections as you can see below. In the next article, we will go over the SQL Always On Availability Group Prerequisites and installation of SQL 2012 R1 Enterprise along with setting up a test Database.
 
INDEX
Part 2: Prereqs and SQL Installation, creating Test Database
Part 3: Cluster Setup and Availability Group setup and testing
 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s