SQL 2012 AlwaysOn Availability Groups for SharePoint FarmsMichael Noel

Convergent Computing

Michael Noel

Author of SAMS Publishing titles “SharePoint 2010 Unleashed,” “SharePoint 2007 Unleashed,” “SharePoint 2003 Unleashed”, “Teach Yourself SharePoint 2003 in 10 Minutes,” “Windows Server 2008 R2 Unleashed,” “Exchange Server 2010 Unleashed”, “ISA Server 2006 Unleashed”, and many other titles .Partner at Convergent Computing (www.cco.com / +1(510)444-5700) – San Francisco Bay Area based Infrastructure/Security specialists for SharePoint, AD, Exchange, Security

What we will coverSQL 2012 AlwaysOn

What is SQL 2012 AlwaysOn?AlwaysOn Failover ClusteringAlwaysOn Availability Groups

Why AlwaysOn Availability Groups for SharePoint?Requirements and PrerequisitesStep by Step guide to implementing AlwaysOn Availability GroupsDemonstration

SQL 2012 AlwaysOnHype or Reality?

Two distinct technologies that share the same nameAlwaysOn Failover Clustering is a different thing!

A Failover Cluster Instance (FCI) uses traditional Shared Storage Clustering (one copy of data shared by multiple nodes)Same marketing name, but completely different technology

AlwaysOn Availability Groups correspond to the new version of SQL Database Mirroring – High Availability and Disaster Recovery at the Data Tier

History of AlwaysOn Availability GroupsBackground and Predecessor Technologies

Original concept was log shipping in SQL 2000 – making a duplicate copy of your databases on another serverMirroring itself introduced in SQL 2005 SP1, improved in SQL 2008 and SQL 2008 R2Works by keeping a mirror copy of a database or databases on up to four additional SQL instances.AlwaysOn Availability Groups introduced with SQL 2012, added up to four mirror copies, and moreThis is a huge change to data tier design for SharePoint

High Availability and Disaster Recovery

SQL Server Solution

Potential Data Loss

(RPO)

Potential Recovery

Time (RTO)

Automatic Failover

Readable Secondaries

AlwaysOn Availability Group - synchronous-commit

Zero Seconds Yes 0 - 2

AlwaysOn Availability Group - asynchronous-commit

Seconds Minutes No 0 - 4

AlwaysOn Failover Cluster Instance NA Minutes Yes NA

Database Mirroring - High-safety (sync + witness)

Zero Seconds Yes NA

Database Mirroring - High-performance (async)

Seconds Minutes No NA

Log Shipping Minutes Minutes-to-hours

No Not duringa restore

Traditional Backup, Copy, Restore Hours to days

Hours to weeks

No Not duringa restore

Comparison of AlwaysOn with other SQL HAGreatly Improved HA and DR

AlwaysOn Availability GroupsDesign Options

Create up to four additional copies of each database on a different SQL nodeCopies can be a mix of synchronous (exact copy) or asynchronous (works across low latency link, but only supports content DBs and Secure Store DB)Create a synchronous copy when connectivity is 1Gb or greater and latency is no more than 10msCreate asynchronous copies across WAN links, for Disaster Recovery or when architecting a read-only farm

AlwaysOn Availability GroupsRead-only Farms

Unlike SQL Mirroring, AlwaysOn Availability Groups allow for read-only access to the content on a remote SQL instanceAllows for the DR copy of the data to be used as part of a view-only SharePoint farm in a remote locationRequires a separate SharePoint farm from the production read/write farm

Design Options for SQL 2012Sample Design

• Two AGs• Content AG

with four replicas – Synch and Asynch

• Service App/Farm DBs on separate AG, 2 Synch copies only

• Read-only farm in remote office attached to content DB copy

• DR farm in remote DC on standby to connect to content DB copy

AlwaysOn Availability GroupsSynchronous vs. Asynchronous Database Support

All SharePoint 2013 (and nearly all SharePoint 2010) databases now support Synchronous Replication (either via Mirroring or AOAGs)Only Content Databases and the Secure Store Database support Asynchronous ReplicationThis is why it is considered best practice to create at least two AOAGs for SharePoint…one for the Content Databases, which can be replicated to remote locations, etc., and one for the remainder of the databases, which can only be replicated locallyThis is a key point, remember, you CANNOT replicate databases synchronously unless you have 1Gb+ bandwidth and less than 10ms of latency!

AlwaysOn Availability Groups for SharePointImproving Data Tier High Availability and Disaster Recovery

Completely changes the design options for the data tierAllows for ‘Exchange Server’ like multi-copy database server failover on multiple replicas at the same timeThe equivalent of running a constant backup of your databasesCan be used to create HA/DR copies of your SharePoint databasesSharePoint no longer needs to be ‘aware’ of the mirrored copy (in fact, it won’t failover if you configure it manually in SPCA.) SharePoint connects to the listener (Client Access Point) which is clusteredSharePoint 2010 Service Pack 1 supports SQL 2012 fully

CAVEAT: Be sure to understand that synchronous mirroring copies need to be in close proximity and have very good bandwidth, as data needs to be written into all replicas before the transaction is committed. SharePoint will lock up if there are any interruptions at the data tier.

AlwaysOn Availability GroupsVersion Requirements

Windows Server 2008 R2 (w SP1 ideally, as patches are required) – Enterprise Edition

One per nodeCan use Virtualization licensing optionsShould also work on Windows 8 Server

SQL Server 2012 Enterprise EditionMS has moved away from per-socket licenses. Licenses are now 1/4th the cost, but are now per each core.Legacy licenses of SQL 2008/2005 Enterprise are ‘grandfathered in’ if you have upgrade assurance

AlwaysOn Availability GroupsPrerequisites and Requirements – Windows OS

Cannot be installed on a Domain ControllerMust be either x86 (non-WOW64) or x64 Windows Server 2008 or later versions.Must be a node in a Windows Server Failover Clustering (WSFC) cluster.Ensure that WSFC cluster contains sufficient nodes to support your availability group configurations.Ensure that all applicable Window hotfixes have been installed on every node in the WSFC cluster, OS patches required for SQL 2012 AlwaysOn Availability Groups include the following:

http://support.microsoft.com/kb/976097 (Asymmetric Storage)http://support.microsoft.com/kb/2494036 (Node Weight Fix)http://support.microsoft.com/kb/2531907 (SCSI Device Test Failure)http://support.microsoft.com/kb/2616514 (Unneeded Reg Key Change Notifications)http://support.microsoft.com/kb/2654347 (Net 35 Always On Features)http://support.microsoft.com/kb/980915 (IPSecConnection Delay) - Not needed if you aren’t using IPSechttp://support.microsoft.com/kb/2578113 (IPv6 Long Failover) - Not needed if you aren’t using IPv6http://support.microsoft.com/kb/2582281 (Slow Failover with No Router) – Not needed in most scenarios, review to determine if it applies to you

NOTE: SP1 for SQL 2012 is out and supersedes some of these patches. Good to double-check, however

AlwaysOn Availability GroupsPrerequisites and Requirements – SQL Server

If you plan to use a SQL Server failover cluster instance (FCI) to host an availability replica, ensure that you understand the FCI restrictions and that the FCI requirements are met (Manual config required)All the server instances that host availability replicas for an availability group must use the same SQL Server collation.If any databases that use FILESTREAM will be added to an availability group, ensure that FILESTREAM is enabled on every server instance that will host an availability replica for the availability group.

AlwaysOn Availability GroupsCluster Witness and Voting Fundamentals

• Automatic failover clustering requires servers to have the proper number of votes to ‘turn on’ a database copy.

• There must always be a majority of votes to enable the node.

• If a majority cannot be reached (for example, if there are only an even number of votes) the DBs will remain offline.• File Servers can act as File

Share Witness (FSW) servers (additional votes.)

• This avoids split-brain scenarios where multiple copies of a DB are online.

• Be sure to give the Cluster Computer Account Full control to the FSW Share

Creating AlwaysOn Availability GroupsStep 1: Create Windows Server Failover Cluster (WSFC)

Install Windows Server 2008 R2 w/SP1 on multiple nodesPatch with Critical, Security, and the specific OS patches listed in previous slideEnable the Failover Cluster Feature on each nodeUse the Failover Cluster Manager Wizard to create a cluster.Name the cluster a unique name that will be separate from the instance name that will be used for SharePoint

Creating AlwaysOn Availability GroupsStep 2: Prepare Nodes

Install .NET Services 3.5 Feature on each SQL nodeInstall SQL 2012 Enterprise Edition Database Services (Also recommend adding SQL Management Tools – Complete)Ensure proper Windows Firewall ports are openService Account for SQL

Use the same service account for all nodesDon’t use Network ServiceIf using Kerberos, make sure all SQL names have SPNs associated with the service account

Make sure databases are set to FULL recovery modeEnsure that the file paths and drive letters are consistent throughout all instances (ideally, or config will have to be manual)Copy or Create SharePoint databases on Primary node only (use SQL Alias to change name later)Perform a full backup of your SharePoint databasesCreate a file share location that is accessible by all nodes that will be used for the shared backups (i.e. \\SQL1\Backups)Transfer Security logins between nodes (http://support.microsoft.com/kb/918992/)

Creating AlwaysOn Availability GroupsStep 2: Enable AlwaysOn on each SQL Node

Enable AlwaysOn High Availability in SQL Server Configuration ManagerRepeat on Each NodeRestart SQL Services

Creating AlwaysOn Availability GroupsStep 3: Create the Availability Group

Ideally use the New Availability Group Wizard, it automates the process

Creating AlwaysOn Availability GroupsStep 3: Create the Availability Group – Continued…

Be sure to have a shared network location for the backup files (Created in earlier step)Depending on size of databases, this could take a whileBackups can also be pre-staged (Join Only)

Creating AlwaysOn Availability GroupsStep 3: Create the Availability Group – Continued…

Validation should show all green (some exceptions)The listener (‘SQL’ in this example) will be created later, and is required for SharePoint to connect to

Creating AlwaysOn Availability GroupsStep 4: Create the Availability Group Listener

After the wizard completes, manually create the Availability Group ListenerThis is the shared name that SharePoint will connect to and will provide failover (Also called the ‘Client Access Point’)Modify the DNS record for this listener to have a low TTL (60 seconds or less) for cross-subnet failover scenarios

Creating and Testing AlwaysOn Availability Groups for SharePoint Farm Failover

Throw away all previous data tier designs for SharePoint!SQL 2012 AlwaysOn Availability Groups are the preferred design option for High Availability and Disaster Recovery at the data tierSQL 2012 is fully supported by SharePoint 2010 Service Pack 1 databasesFollow closely the guidelines, ensure data paths are the same, double-check security requirements

Session SummarySQL 2012 AlwaysOn Availability Groups for SharePoint 2010

Thanks for attending!Questions?

Michael NoelTwitter: @MichaelTNoel

www.cco.comSlides: slideshare.net/michaeltnoel