One of the most compelling features in the upcoming SQL Server 2012 release (formerly code named Denali) is the new AlwaysOn Availability Groups.
Microsoft's use of the term AlwaysOn is a bit confusing. AlwaysOn actually refers to two separate but related technologies: AlwaysOn Failover
Clustering and AlwaysOn Availability Groups. AlwaysOn Failover Clustering is essentially the same thing as SQL Server failover clustering in earlier
releases. It entails running a SQL Server instance on a Windows failover cluster. However, the AlwaysOn Availability Groups feature is completely new
to SQL Server 2012, and it brings several new availability enhancements to SQL Server. If you're using database mirroring, AlwaysOn Availability Groups
could be a good reason to upgrade to SQL Server 2012.
After I describe the availability enhancements you'll find in AlwaysOn Availability Groups, I'll tell you about the system requirements and the basic
system setup. I'll also show you how easy it is to configure and manage AlwaysOn Availability Groups.
The Availability Enhancements
The AlwaysOn Availability Groups feature is the next evolution of database mirroring. Database mirroring is an effective technology for enhancing
single database availability. However, database mirroring has several significant limitations:
ยท It's limited to a single failover partner. Although you can setup multiple database mirroring partnerships, each partnership can consist of only
two systems and the optional witness (which doesn't actually maintain the mirrored data).
-
It's capable of failing over only a single database at a time. Although this works for simple applications, it doesn't adequately protect more
complex multiple-database applications.
- It must be implemented either synchronously or asynchronously. You have to choose one or the other.
-
The databases on the mirror server are in a state of constant recovery, so they can't be directly accessed. To use the data in the mirrored
databases, you must take point-in-time snapshots of them.
AlwaysOn Availability Groups address all these limitations. They provide support for one primary replica and up to four secondary replicas, where each
replica is located on a separate SQL Server instance running on different Windows failover cluster nodes. More important, AlwaysOn Availability Groups
can contain multiple databases, all of which can be automatically failed over as a unit. This means that AlwaysOn Availability Groups can protect
multiple related databases and fail them over simultaneously. For example, if your application uses ASP.NET forms integration for authentication, you
can fail over the default aspnetdb database in addition to your application's primary database. That way, the user authentication information can go
along with your production data.
Another important advantage with AlwaysOn is that you don't have to choose between asynchronous mode and synchronous mode, like you did with database
mirroring. AlwaysOn can have both synchronous and asynchronous replicas at the same time. Synchronous connections are typically used in
high-availability scenarios, where there's automatic failover. Asynchronous connections are typically used in disaster recovery scenarios, where
there's geographical distance between the different servers. AlwaysOn Availability Groups enable you to have both types of protection simultaneously
and can support a maximum of three synchronous replicas. In addition, the replica databases are able to provide read-only access. This enables the
replicas to be used for both reporting and backup purposes, potentially offloading some of the workload and I/O from the primary server.
The Requirements
On the hardware side, AlwaysOn Availability Groups require at least two server systems and can work with as many as four systems. They can be either
physical server systems or virtual machines (VMs). In addition, AlwaysOn Availability Groups require Windows failover clustering, which means you have
to use the Enterprise Edition (or higher) of Windows Server 2008 R2 or Windows Server 2008. (The Standard Editions of Server 2008 R2 and Server 2008
don't support failover clustering.) At the time of this writing, it hasn't been announced which editions of SQL Server 2012 will support AlwaysOn
Availability Groups, but most of the high-availability features have traditionally been provided in the Enterprise Edition or higher.
The AlwaysOn Availability Groups' requirement for clustering means additional complexity compared with database mirroring. Fortunately, Windows
failover clustering became much easier to set up beginning with Server 2008. It's important to note that although AlwaysOn Availability Groups require
a Windows failover cluster, they don't require installing SQL Server as a clustered application. (That's the purview of AlwaysOn Failover Clustering.)