How to: Configure SQL Server 2012 AlwaysOn
Scope and Architecture
This is the first post in a series to provide step-by-step instructions on how to setup and configure a SQL Server 2012 AlwaysOn in a dual data-center Windows clustered environment using shared storage in multiple subnets.
When I say, step-by-step, what I mean is that I will cover the steps which are specific to using AlwaysOn in a dual data-center Windows clustered environment using shared storage in multiple subnets. This does not include generic setup procedures for Windows Failover Clusters and installation of SQL Server Failover Cluster Instances. The basics will be touched on with references but only the steps specific to this architecture and AlwaysOn will be presented in detail.
Scope:
There is a large amount of information already out on the internet about AlwaysOn and I will attempt to link out to these sources as much as possible when it comes to background information and concepts of AlwaysOn. The scope of this blog series is to provide step-by-step instructions on how to setup a particular architecture (architecture explanation is below). I have chosen an architecture which includes Windows clustering (required for AlwaysOn), two data-centers, and a combination of AlwaysOn database level fail-over and Windows clustering instance level fail-over. The most desirable aspect of this architecture is the ability to use shared storage to minimize disk space usage but still provide multiple data-center capabilities. The steps provided here were tested only with the target architecture but in most cases apply to all OS and SQL versions that AlwaysOn is available to.
Terminology disclaimer: You see that I’ve used the word AlwaysOn a bunch of times already. AlwaysOn refers to both Windows Server Failover Clusters and SQL Server Availability Groups. In this architecture we are using both, which makes AlwaysOn acceptable but the features should be referenced individually whenever possible.
Background:
Target Architecture:
In this setup we are looking to produce two SQL Server Fail-over Cluster Instances (FCI), one in Data Center 1 and one in Data Center 2. Each data center has two physical nodes to the cluster but all four nodes are technically a member of the same Windows Fail-over Cluster (WCF).
Before we get into too much more detail I want to explain why I’m doing this. AlwaysOn has the ability to build this same architecture without using FCIs; instead it just uses normal standalone instances on each node but it produces a replica copy on each instance for up to four total replicas. There are two situations I can think of where you would want to use the FCIs as I’m targeting. The first is if you have a large cluster such as five nodes in Data Center 1 alone and you still want to add more to fail-over to Data Center 2. With a limit on replica copies you might constrain yourself to smaller clusters. The second scenario I can think of is if you have disk space limitations with very large databases (VLDB). This second reason was why I set this up at my organization, I had a 7 TB database that I didn’t want multiple copies of. I accepted the need for two copies (one in each data center) but I didn’t want to go any further than I had to while still maintaining automatic fail-over locally and manual fail-over cross data centers.
In addition, this step-by-step guide will cover the entire range of options that you could use to setup your AlwaysOn architecture. That makes this architecture a good tool for anyone.
Back to the details; below is a list of the hardware and software specs used during this demonstration.
Hardware
- Nodes A and B
- 4 CPUs
- 4 GBs of RAM
- 60 GB local storage (C:)
- 20 GB ISCSI SAN attached storage (E:)
- Located in Data Center 1
- Nodes C and D
-
- 4 CPUs
- 4 GBs of RAM
- 60 GB local storage (C:)
- 20 GB ISCSI SAN attached storage (also named E:)
- Located in Data Center 2
Software
- Windows Server 2008 R2 Enterprise SP1 (for Windows Server 2012 R2 check out Perry Whittle‘s post here)
- 64-bit
- SQL Server 2012 Enterprise w/ CU2 (11.0.2325)
Wrap-up:
That should set the basis for what we will accomplish with this blog series. Follow the links below to move on through this tutorial.
- Scope and Architecture – Part 1 of 7
- Building the Environment – Part 2 of 7
- Configuring AlwaysOn – Part 3 of 7
- Building Availability Groups – Part 4 of 7
- Explanation of Implicitly Created Components – Part 5 of 7
- How to: Fail-Over – Part 6 of 7
- The Availability Group Listener – Part 7 of 7
Leave a Reply