This is a cross-post of my article on SharePointEduTech.
Bill Baer (@williambaer) gave an excellent presentation on the next version of SQL Server, codenamed Denali that will feature AlwaysOn. AlwaysOn is a new high-availability solution for SQL Server.
AlwaysOn provides both database and instance level protection. So how does AlwaysOn provide an “integrated, flexible, solution?â€
There are 2 components for AlwaysOn:
- Availability Groups (database protection – like resource groups in clustering) which includes active secondaries (where you can read data).
- FCI (Failover cluster instances) – Provides instance level protection.
AlwaysOn is cost effective because the secondary can be used for backups, reporting, active farms that provide read-only content, etc (any read only operation).
Requirements:
- Must have Windows Failover Cluster service enabled (for distributated state, and inter-node health detection). SQL boxes don’t have to be clustered.
- Must be joined to the same AD domain andd use a domain account to create the failover cluster.
- KB 2494036 hotfix is recommended for Windows 2008 R2. (allows a specified node to have more votes/weight than another node).
- SharePoint Server 2010 with Service Pack 1
Pre-requisistes:
- Server instances must reside on Win Server Failover Clustering, must all be in the same cluster
- Must use same SQL Server system collation (SharePoint has restrictions that comply with this already).
Availability Group
- Essentially combines log shipping and database mirroring.
- Compression & Encryption built-in
- Multiple secondaries
- Synchronous and Asynchronous
- Automatic or manual failover
- Automatic Page Repair (can ask Secondary for copy of page if torn)
With AlwaysOn, connections are re-tried (instead of failed) when there is a failover.
My notes:
AlwaysOn can span subnets so content can be replicated and used elsewhere on a read-only secondary (such as high I/O backups). Roles can be changed manually or automatically, without reconfiguration. This means, no DNS changes or changing connection strings.
Easy transition from either database mirroring or log shipping to AlwaysOn; just a few minor configuration changes.
A flexible failover policy allows control over the condition when a failover should be initiated. This will prevent false failovers. There’s also increased detail in logging that will allow admins to determine why a failover occurred.
AlwaysOn provides the best RTO and RPO, over Failover Clustering, Log Shipping and Restore from backup.
Learn more about SQL Server High-Availability and AlwaysOn on microsoft.com.