House of Brick Principal Architect
Over the last month, I have been exploring the new features within SQL Server 2012. I have paid special attention to AlwaysOn, a new feature that effectively blurs the lines between high availability (HA) and disaster recovery (DR).
In previous versions of SQL Server, these two items were mutually exclusive. Both were managed separately and, in some cases, even managed by different people.
Historical Options for High Availability include:
Microsoft Failover Clustering – A SAN must be used to present storage to all of the cluster nodes. Dealing with the quorum and the shared drive failover was cumbersome, and even routine maintenance like rolling patches could cause headaches. Most people continue to cringe at the mention of MSFC.
Database mirroring – Mirroring in synchronous mode worked well, but since the mirrored pair presents two IP addresses for the application to connect to, the application needed to be mirror-aware. This was easier said than done; mirroring only worked in pairs, but was configured to fail over at a single database level. Consideration was not given to applications that had two or more databases, such as Microsoft SharePoint. Scripting was needed to fail over more than one database.
Historical Options for Disaster Recovery include:
Database mirroring – Mirroring in asynchronous mode also worked well but the application still needed to be mirror-aware. Scripting was still needed to fail over more than one database.
Transaction log shipping – This option was complex and failover was not automatic. However, you could have multiple nodes in the background for reporting or other purposes.
SQL Server 2012 AlwaysOn takes the best of these technologies, adds features to fill in some gaps, and presents it in an extremely simple to manage package.
Microsoft Failover Clustering, running without shared storage, handles the virtual IP address for all cluster nodes. Availability Groups, or groups of databases common to an application or purpose, can even have their own virtual IP address.
AlwaysOn allows you to set up four nodes in the Availability Group. Each secondary node can be configured for synchronous or asynchronous replication. Each can be configured to allow read-only access and database backups and reporting can now be processed from these nodes. Asynchronous nodes can be set up at a DR location for branch-level reporting and failover and failback is automatic.
Each Availability Group can contain multiple databases, which eliminates the need to manually script and keep things up to date as the environment changes.
In the terms of raw manageability, the amount of time saved by using these features is easily demonstrated through reduced complexity and simplification of maintenance procedures.
In the event of an HA or DR event, you want the simplest, most robust solution possible. Your business demands the highest uptime possible. Can your business afford NOT to evaluate SQL Server 2012 AlwaysOn?
