1. SharePoint Business Continuity Management with SQL Server AlwaysOn
Brendan Griffin
Microsoft

2. Me.About() Brendan Griffin, MCM Contact Details
Senior Premier Field Microsoft
Microsoft Certified Master (SharePoint 2010)
SharePoint-er since 2004
Contact Details
Blog: aka.ms/fromthefield

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

4. 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

5. 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 %
31.50 seconds
2.59 seconds
0.61 seconds

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

7. Can you Identify the Problem?
Fault Domain
Fault Domain

8. 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

9. 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.”

10. 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

11. 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

12. 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

13. 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

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

15. 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

16. 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

17. Creating a Windows Failover Cluster
for
SQL AlwaysOn

21. Demo Environment – End

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

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

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

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

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

30. 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

31. 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

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

35. Demo Environment – Start

36. Demo Environment – End

37. 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!!!

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

39. 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

40. 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

41. 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

42. 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

43. 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

44. High Level Process – Recovery

45. Configure and Test Disaster Recovery
for
SharePoint

51. Demo Environment – Start

52. Demo Environment – End

53. 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

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

55. 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

56. Questions???

57. Thank you for attending!
Brendan Griffin