Using SQL Server 2012 AlwaysOn Availability Groups for SharePoint 2013 Farms Michael Noel @MichaelTNoel
Michael Noel • Author of SAMS Publishing titles “SharePoint 2007 Unleashed,” the upcoming “SharePoint 2010 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, U.S.A. based Infrastructure/Security specialists for SharePoint, AD, Exchange, Security
What we will cover SQL 2012 AlwaysOn • What is SQL 2012 AlwaysOn? – AlwaysOn Failover Clustering – AlwaysOn Availability Groups • Why AlwaysOn Availability Groups for SharePoint? • Requirements and Prerequisites • Step by Step guide to implementing AlwaysOn Availability Groups • Demonstration
SQL 2012 AlwaysOn Hype or Reality? • Two distinct technologies that share the same name • AlwaysOn 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 Groups Background and Predecessor Technologies • Original concept was log shipping in SQL 2000 – making a duplicate copy of your databases on another server • Mirroring itself introduced in SQL 2005 SP1, improved in SQL 2008 and SQL 2008 R2 • Works 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 more • This is a huge change to data tier design for SharePoint
Comparison of AlwaysOn with other SQL HA Greatly Improved HA and DR High Availability and Disaster Recovery Potential Potential Automatic Readable SQL Server Solution Data Loss Recovery (RPO) Time (RTO) Failover 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 Seconds Yes NA -to-minutes Database Mirroring - High-safety (sync + witness) Zero Seconds Yes NA Database Mirroring - High-performance (async) Seconds Minutes No NA Log Shipping Minutes Minutes No Not during -to-hours a restore Backup, Copy, Restore Hours Hours No Not during -to-days a restore
AlwaysOn Availability Groups Design Options • Create up to four additional copies of each database on a different SQL node • Copies 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 10ms • Create asynchronous copies across WAN links, for Disaster Recovery or when architecting a read-only farm
AlwaysOn Availability Groups Read-only Farms • Unlike SQL Mirroring, AlwaysOn Availability Groups allow for read-only access to the content on a remote SQL instance • Allows for the DR copy of the data to be used as part of a view-only SharePoint farm in a remote location • Requires a separate SharePoint farm from the production read/write farm
Design Options for SQL 2012 Sample 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 Groups Synchronous vs. Asynchronous Database Support • Al 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 Replication • This 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 locally • This 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 SharePoint Improving Data Tier High Availability and Disaster Recovery • Completely changes the design options for the data tier • Allows for ‘Exchange Server’ like multi-copy database server failover on multiple replicas at the same time • The equivalent of running a constant backup of your databases • Can be used to create HA/DR copies of your SharePoint databases • SharePoint no longer needs to be ‘aware’ of the mirrored copy (in fact, it won’t failover if you configure it manual y in SPCA.) SharePoint connects to the listener (Client Access Point) which is clustered • SharePoint 2010 Service Pack 1 supports SQL 2012 ful y 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 al replicas before the transaction is committed. SharePoint wil lock up if there are any interruptions at the data tier.
AlwaysOn Availability Groups Version Requirements • Windows Server 2008 R2 (w SP1 ideally, as patches are required) – Enterprise Edition – One per node – Can use Virtualization licensing options – Should also work on Windows 8 Server • SQL Server 2012 Enterprise Edition – MS 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 Groups Prerequisites 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) • Al the server instances that host availability replicas for an availability group must use the same SQL Server col ation. • If any databases that use FILESTREAM wil be added to an availability group, ensure that FILESTREAM is enabled on every server instance that wil host an availability replica for the availability group.
AlwaysOn Availability Groups Cluster 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 Groups Step 1: Create Windows Server Failover Cluster (WSFC) • Install Windows Server 2008 R2 w/SP1 on multiple nodes • Patch with Critical, Security, and the specific OS patches listed in previous slide • Enable the Failover Cluster Feature on each node • Use 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 Groups Step 2: Prepare Nodes • Instal .NET Services 3.5 Feature on each SQL node • Instal SQL 2012 Enterprise Edition Database Services (Also recommend adding SQL Management Tools – Complete) • Ensure proper Windows Firewal ports are open • Service Account for SQL – Use the same service account for al nodes – Don’t use Network Service – If using Kerberos, make sure al SQL names have SPNs associated with the service account • Make sure databases are set to FULL recovery mode • Ensure that the file paths and drive letters are consistent throughout al instances (ideal y, or config wil have to be manual) • Copy or Create SharePoint databases on Primary node only (use SQL Alias to change name later) • Perform a ful backup of your SharePoint databases • Create a file share location that is accessible by al nodes that wil be used for the shared backups (i.e. \\SQL1\Backups)
Creating AlwaysOn Availability Groups Step 2: Enable AlwaysOn on each SQL Node • Enable AlwaysOn High Availability in SQL Server Configuration Manager • Repeat on Each Node • Restart SQL Services
Creating AlwaysOn Availability Groups Step 3: Create the Availability Group • Ideally use the New Availability Group Wizard, it automates the process
Creating AlwaysOn Availability Groups Step 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 while • Backups can also be pre-staged (Join Only)
Creating AlwaysOn Availability Groups Step 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 Groups Step 4: Create the Availability Group Listener • After the wizard completes, manually create the Availability Group Listener • This 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 AlwaysOn Availability Groups Manual Process: Adding a DB to an Availability Group • Required in specific situations, such as when a DB is encrypted • First, add the DB to the primary server (where the DB is attached to with the fol owing syntax: – ALTER AVAILABILITY GROUP SPDBCONTENT – ADD DATABASE SPF1_Content_TDE – GO • Then restore the DB onto the secondary server, ensuring that you choose ‘RESTORE WITH NORECOVERY’ from the Options tab • Finally, add the DB to the AG on the Secondary server – ALTER DATABASE SPF1_Content_TDE SET HADR AVAILABILITY GROUP = SPDBCONTENT; – GO
Creating and Testing AlwaysOn Availability Groups for SharePoint Farm Failover
Session Summary SQL 2012 AlwaysOn Availability Groups for SharePoint 2010 • 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 tier • SQL 2012 is fully supported by SharePoint 2010 Service Pack 1 databases – but remember that only content databases and the secure store DB support asynchronous replication! • Best Practice is to create at least two AGs for SharePoint – One for Content DBs and the other for the remainder of the farm DBs. • Follow closely the guidelines, ensure data paths are the same, double-check security requirements
Your Feedback is Important Please fil out a session evaluation form drop it off at the conference registration desk. Thank you!