SharePoint Business Continuity Management with SQL Server AlwaysOn Brendan Griffin Microsoft

Me.About() Brendan Griffin, MCM Contact Details Senior Premier Field Engineer @ Microsoft Microsoft Certified Master (SharePoint 2010) SharePoint-er since 2004 Contact Details Twitter: @brendankarl Email: brendan.griffin@microsoft.com Blog: aka.ms/fromthefield

Agenda High Availability and Disaster Recovery Definition What is SQL Server AlwaysOn? High Availability with SQL Server AlwaysOn Disaster Recovery with SQL Server AlwaysOn

High Availability “A system design approach and associated service implementation that ensures a prearranged level of operational performance will be met during a contractual measurement period.” High Availability is about protecting the Service Level Agreements (SLAs) and the agreed Fault Domains

Service Level Agreements Agreed levels of service usually between vendors, suppliers and clients or inter organisational departments (OLAs) Availability % Downtime / Year Downtime / Month Downtime / Week 99% 3.65 days 7.20 hours 1.68 hours 99.9% 8.76 hours 43.20 minutes 10.10 minutes 99.99% 52.56 minutes 4.32 minutes 1.01 minutes 99.999% 5.26 minutes 25.90 seconds 6.05 seconds 99.9999% 31.50 seconds 2.59 seconds 0.61 seconds

Fault Domains “Group of physical or virtual infrastructure pieces with a common configuration that share a single point of failure”

Can you Identify the Problem? Fault Domain Fault Domain

Disaster Recovery “The process, policies and procedures that are related to preparing for recovery or continuation of technology infrastructure which are vital to an organization after a natural or human-induced disaster.” Disaster Recovery is about recovering the critical operations that enable the business to function

Defining Disaster Recovery Requirements Recovery Point Objective (RPO) Recovery Time Objective (RTO) RPO RTO Example: RPO of 1 hour RTO of 3 hours “I can lose 60 minutes worth of data, and all of my data can be inaccessible for three hours.”

How can SQL Server AlwaysOn Help? Introduced in SQL Server 2012 – “Kind of” Clustering and Mirroring Provides HA & DR capabilities for SQL databases Databases are placed into Availability Groups Each Availability Group has a Listener (Virtual Name and IP Address) Availability Group can reside on any server within the Cluster

AlwaysOn Availability Groups Logical grouping of databases for failover Maximum of 8 secondary's (copies) in SQL Server 2014 2 x Synchronous (HA): No Data Loss 8 x Asynchronous (DR): Potential Data Loss

AlwaysOn Availability Groups All SharePoint databases support Synchronous Replicas (HA) Not recommended for the Usage database Asynchronous Replicas (DR) not supported for: Admin Content Config Search Usage UPA Sync State https://technet.microsoft.com/en-us/library/jj841106.aspx

How Many Do I Need? It depends! Typically advise to split logically, example: Configuration – Config and Central Admin Content DB Content – Content DBs Service Apps (Sync) – Service Apps supporting Sync Service Apps (Sync/Async) – Service Apps that support both Sync and Async

SQL AlwaysOn Pre-Requisites Failover Clustering Virtual IP Address File Share Witness Active Directory Permissions Create Computer Objects Read all Properties

Clustering Top Tips – Quorum More than half of the voting nodes need to be online for the cluster to be healthy Exclude nodes hosted in the DR site from voting

Clustering Top Tips – Quorum Use a File Share Witness if you have an even number of voting nodes to prevent a “tie” Dynamic Quorum introduced in Windows Server 2012 provides additional intelligence If using Windows Server 2012 R2 always configure a witness

Creating a Windows Failover Cluster for SQL AlwaysOn

Demo Environment – End

What’s Next? Enable SQL AlwaysOn on each node Create Availability Groups Configure SharePoint Test failover!

What’s Next? Enable SQL AlwaysOn on each node Create Availability Groups Configure SharePoint Test failover!

What’s Next? Enable SQL AlwaysOn on each node Create Availability Groups Configure SharePoint Test failover!

AlwaysOn Tips – Backups Use Backup Preferences to reduce the performance impact of backups on the Primary Replica

AlwaysOn Tips – Backups Configure SQL on each node to store backups in a common share

AlwaysOn Tips – Firewall Ports 5022 required for SQL AlwaysOn End-Points 1433 for SQL Connectivity A SQL alias is required on each SharePoint server if the Availability Group uses a non-standard SQL port

AlwaysOn Cmdlets for SharePoint 2013 were added in the April 2014 CU What’s Next? Enable SQL AlwaysOn on each node Create Availability Groups Configure SharePoint Test failover! AlwaysOn Cmdlets for SharePoint 2013 were added in the April 2014 CU

What’s Next? Enable SQL AlwaysOn on each node Create Availability Groups Configure SharePoint Test failover!

Demo Environment – Start

Demo Environment – End

Demo Summary Created 4 x AlwaysOn Availability Groups (AGs) Updated SharePoint to reference the AG Listener for SP-Config using Add-DatabaseToAvailabilityGroup Failed over the SP-Config and SP-Content AGs from SQL 1 to SQL2 SharePoint still worked!!!

Top Tip – MultiSubnetFailover Recommended to enable MultiSubnetFailover on each database Even if all SQL servers are in the same subnet Addresses potential connectivity issues

What about Disaster Recovery? Can be complex! Depends on Service Applications being used Use Asynchronous Commit between replicas Failover Processes Planned Un-Planned Essential Reading http://technet.microsoft.com/en-us/library/ff877957.aspx

What about Disaster Recovery? Search is a special case Usage and Analytics updates to Index are not replicated Site Collection & Web level configuration are not replicated Options for DR SSA Backup and Restore using OOTB tooling Attach Search Admin DB to DR farm and perform full crawl Essential Reading https://technet.microsoft.com/en-us/library/dn715769.aspx

What about Disaster Recovery? Deploy solutions to both Live and DR Ensure that Farm and Web App scoped features are activated in the DR farm Ensure that farm-wide configuration changes are replicated to the DR farm

What about Disaster Recovery? Replicate settings for Service Applications that don’t use a database Excel Services PerformancePoint Services PowerPoint Conversion Visio Graphics Service Work Management

High Level Process – Setup Add a 3rd node to the Cluster in the DR site Configure AlwaysOn Asynchronous Replica Provision a DR SharePoint farm Create failover plan

High Level Process – Recovery

Configure and Test Disaster Recovery for SharePoint

Demo Environment – Start

Demo Environment – End

Demo Summary Added 3rd replica (Asynchronous) into the Availability Groups Failed over Content, UPS and MMS databases to SQL3 in the DR environment Attached databases to DR SharePoint farm Tested access

What about the Cloud??? Don’t have DR facilities? You could host SharePoint DR farm and 3rd SQL Cluster Node in Azure

What about the Cloud??? Considerations: Connectivity: Site to Site VPN / ExpressRoute required Supporting Services: AD, DNS etc AlwaysOn: Only one Availability Group is supported Performance: Use Premium Storage Cost: Keep the SharePoint servers shutdown until failover

Questions???

Thank you for attending! Brendan Griffin