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

SharePoint Business Continuity Management with SQL Server AlwaysOn

Brendan GriffinMicrosoft

Me.About() Brendan Griffin, MCM

Senior Premier Field Engineer @ Microsoft Microsoft Certified Master (SharePoint 2010) SharePoint-er since 2004

Contact Details Twitter: @brendankarl Email: [email protected] 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

DemoCreating a Windows Failover

Cluster for

SQL AlwaysOn

Demo Environment – End

What’s Next?

Enable SQL AlwaysOn on each nodeCreate Availability GroupsConfigure SharePointTest failover!

What’s Next?

Enable SQL AlwaysOn on each node

Create Availability GroupsConfigure SharePointTest failover!

What’s Next?

Enable SQL AlwaysOn on each nodeCreate Availability GroupsConfigure SharePointTest 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

What’s Next?

Enable SQL AlwaysOn on each nodeCreate Availability GroupsConfigure SharePointTest failover!

AlwaysOn Cmdlets for SharePoint 2013 were added in the April 2014 CU

What’s Next?

Enable SQL AlwaysOn on each nodeCreate Availability GroupsConfigure SharePointTest 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 usedUse Asynchronous Commit between

replicasFailover 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 crawlEssential 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

DemoConfigure and Test Disaster

Recoveryfor

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