As IT systems have become increasingly critical to the smooth operation of a company, the importance of ensuring the continued operation of those systems, and their rapid recovery, has increased. In this session we will take a deeper look at the new concept of AlwaysOn Availability Groups for SQL 2012 and how you can configure it with SharePoint Server 2013. Furthermore we will learn how to increase SharePoint and SQL performance by using the availability group Read-Intent and Backup Priority features. You will learn about the different Disaster Recovery Options for SharePoint 2013 as well as how they work and how to use them. I will also show you a live demo on how to configure SQL 2012 Availability groups, and we will simulate a Disaster to see how well it reacts.
3. Vlad Catrinescu
Founder at www. SharePoint-Community.Net
SharePoint Consultant – Victrix, Montreal
Started working with SharePoint since 2009
MCITP: SharePoint 2010
MCSA : Windows Server 2012
Main Focus
• SharePoint Server
• PowerShell
• Disaster Recovery/High Availability
Contact
@vladcatrinescu
vladcatrinescu@hotmail.com
www.absolute-sharepoint.com
www.sharepoint-community.net
4. AGENDA
Some SQL History
High Availability
VS
Disaster Recovery
Availability Groups in
Details
SQL Server Availability
Groups
Prerequisites
Sample Topologies
DEMO
10. SQL Server
2000
• Log Shipping
• Failover Clustering
SQL Server
2005
• Database Mirroring
SQL Server
2008
• Improved DB Mirroring
SQL Server
2008 R2
• Improved DB Mirroring
SQL Server
2012
• Always On Availability Groups
SQL Server
2014
• ImprovedAlways On AG
11. DATABASE MIRRORING
Pros
• Database Stored on two different servers
• SharePoint 2010/2013 supports HA with
Mirroring
Cons
• Got to Backup/Restore
Databases Manually.
• Got to enter the server as
“Failover Database Server”
for every Database
• Database can only be stored
on two servers.
http://technet.microsoft.com/en-us/library/dd207314(v=office.14).aspx
http://blogs.technet.com/b/praveenh/archive/2010/12/29/sharepoint-2010-is-now-mirroring-
aware.aspx
12. FAILOVER CLUSTERING
PROS
• Connect to Cluster trough
Alias = Easy!
• Easy to setup Automatic
Failover
http://elementalsql.blogspot.ca/2010/02/creating-sql-server-2008-cluster-in.html
CONS
• Data Stored on only 1
Storage
• Disaster Recovery will only
depend on BackUps
• Required SAN Storage
13. SQL SERVER 2012 ALWAYS ON
AVAILABILITY GROUPS
• Database Stored on 2+ different servers
• Connect to Cluster trough Listener = Easy!
• No need for SAN storage (Not like SQL Cluster)
• Automatic failover
• More cool features we will see later!
Windows
Server
Failover
Cluster
Availability Group Listener
SQL-SP
Primary
Replica
Secondary
Replica
Secondary
Replica
15. LICENSING
Every Node needs to have aWindows Server Enterprise License
Supported in SQL Enterprise Edition
Only
You may not need to pay for ALL
your SQL Servers.
Talk to your Microsoft Sales Rep!
16. SOFTWARE
REQUIREMENTS
All nodes must be in the same AD domain.
All servers should be in a single windows cluster.
Install individual SQL servers on each machines, not cluster aware.
18. DATABASE
REQUIREMENTS
Database needs to be in FULL Recovery Mode
Database needs to have at least ONE Full Backup
You need at least one DB that meets those requirements to create your
Availability Group (Can be a dummy DB)
20. COOL NEW FEATURES
Read only secondary replicas.
Backups can occur on the replica databases.
Automatic Failover and ZERO Data Loss.
Synchronous AND Asynchronous mode in the same AG
Not Limited to only 2 nodes
21. AVAILABILITY MODES
Synchronous-commit
Under synchronous-commit mode,
before committing transactions, a
synchronous-commit primary replica
waits for a synchronous-commit
secondary replica to acknowledge
that it has finished hardening the log.
Zero Potential Data Loss
Supports ALL SharePoint Databases
Requires Conectivity of 1Gb or greater
& latency no more than 10ms
Useful for High Availability
Asynchronous-commit
Under asynchronous-commit
mode, the primary replica commits
transactions without waiting for
acknowledgement that an
asynchronous-commit secondary
replica has hardened the log.
A few seconds of Potential Data Loss
Supports Content Databases
Works across WAN links!
Useful for Disaster Recovery
You can have BOTH of them in the same topology
22. LIMITATIONS AND CONSIDERATIONS
Synchronous Commit – up to 2 mirrored replicas.
Asynchronous Commit – up to 4 mirrored replicas.
Read only secondary replicas & Backup on Secondary
Replicas = Additional License Costs.
Readable secondary replicas are currently not supported
for SharePoint 2013 runtime usage.
24. HIGH AVAILABILITY
AG_Listener
Primary SQL Replica1
Synchronous
Protects you Against:
-Software Failures
-Hardware Failures (unless they’re all on same HOST)
-Synchronous Mode = Zero Data Loss and very little
downtime.
Doesn’t Protect you Against:
-Large Scale Disaster
28. DEMO
1. Create aWindows Server Cluster
2. Enable the AlwaysOn SQL Feature
3. Create an Availability Group & Listener
4. Install SharePoint 2013 in that AG
5. Simulate a Disaster!
29. SESSION SUMMARY
SQL 2012 AlwaysOn Availability Groups are the new preferred design option for
HA and DR at the data tier level!
Make sure you Understand Licensing and Limitations
Disasters Can Happen at AnyTime. Be prepared!
If you use Synchronous Mode, Make sure the replicas are close and have a High
Bandwith Connection between them!
30. Join our local users
groups
Toronto SharePoint Users Group
http://www.meetup.com/TorontoSPUG/
Toronto SharePoint Business Users Group
http://www.meetup.com/TSPBUG/
High Availabilityminimize the probability of a failuremore local in nature and generally tolerate smaller amounts of data loss and downtime
Disaster Recovery restoring operational service after a failurea catastrophic event occurs and an extended outage is necessary to get back and running
SQL 2000 Log ShippingFailover ClusteringSQL 2005Database MirroringSQL 2008Improved DB MirroringSQL 2008R2Improved DB MirroringSQL 2012Always On Availability GroupsSQL Server 2014Improved Always On AG
Under synchronous-commit mode, before committing transactions, a synchronous-commit primary replica waits for a synchronous-commit secondary replica to acknowledge that it has finished hardening the log.ZeroPotential Data LossRequires Conectivity of 1Gb or greater & latency no more than 10msUseful for HighAvailabilityUnder asynchronous-commit mode, the primary replica commits transactions withoutwaiting for acknowledgement that an asynchronous-commit secondary replica has hardened the log. A fewsecondsof Potential Data LossWorks across WAN links!Useful for Disaster Recovery