The release of SQL Server 2012 provides for unprecedented high availability and disaster recovery options for SharePoint farms in the form of AlwaysOn Availability Groups, the newest form of Database Mirroring. Using this new technology, SharePoint architects can provide for near-instant failover at the data tier, without the risk of any data loss. This technology, which will be demonstrated live, completely changes the data tier design options for SharePoint and revolutionizes high availability options for a farm. This session covers in step by step detail the exact configuration required to enable this functionality for a SharePoint 2010 or SharePoint 2013 farm, based on the Best Practices, tips and tricks, and real-world experience of the presenter in deploying this technology in production.
5. History of AlwaysOn Availability Groups
Background and Predecessor Technologies
6. Comparison of AlwaysOn with other SQL HA
Greatly Improved HA and DR
High Availability and Disaster Potential Potential
Automatic Readable
Recovery Data Loss Recovery
Failover Secondaries
(RPO) Time (RTO)
SQL Server Solution
AlwaysOn Availability Group - synchronous- Zero Seconds Yes 0-2
commit
AlwaysOn Availability Group - asynchronous- Seconds Minutes No 0-4
commit
AlwaysOn Failover Cluster Instance NA Minutes Yes NA
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
Traditional Backup, Copy, Restore Hours to Hours to No Not during
days weeks a restore
9. 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
10. AlwaysOn Availability Groups
Synchronous vs. Asynchronous Database Support
you CANNOT replicate
databases synchronously unless you have 1Gb+
bandwidth and less than 10ms of latency!
13. AlwaysOn Availability Groups
Prerequisites and Requirements – Windows OS
http://support.microsoft.com/kb/976097
http://support.microsoft.com/kb/2494036
http://support.microsoft.com/kb/2531907
http://support.microsoft.com/kb/2616514
http://support.microsoft.com/kb/2654347
http://support.microsoft.com/kb/980915
http://support.microsoft.com/kb/2578113
http://support.microsoft.com/kb/2582281
15. 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