Upload
daisy-goodman
View
248
Download
0
Tags:
Embed Size (px)
Citation preview
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