SQL 2012 ALWAYSON AVAILABILITY GROUPS FOR

SHAREPOINT 2013By Vlad Catrinescu

Thanks to our sponsors!

Vlad CatrinescuFounder at www. SharePoint-Community.Net

SharePoint Consultant – Victrix, Montreal

Started working with SharePoint since 2009

MCITP: SharePoint 2010MCSA : Windows Server 2012

Main Focus• SharePoint Server• PowerShell• Disaster Recovery/High Availability

Contact

@vladcatrinescuvladcatrinescu@hotmail.comwww.absolute-sharepoint.comwww.sharepoint-community.net

AGENDA

Some SQL History

High Availability VS

Disaster Recovery

Availability Groups in Details

SQL Server Availability Groups

Prerequisites

Sample Topologies

DEMO

HIGH AVAILABILITY VS

DISASTER RECOVERY

Anything and everything!- Hardware: CPU, cards, memory, disk-Software: OS, Services, Drivers, Updates

WHAT CAN FAIL?

HIGH AVAILABILITY

Software and Hardware Failures

Very Local

Small outage period.

DISASTER RECOVERY

Natural or Human-induced Disaster

Some Outage Acceptable to get back running

Needs an offsite Data Center

SOME SQL HISTORY

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

• Improved Always On AG

SQ

L D

R/H

AH

ISTO

RY

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).aspxhttp://blogs.technet.com/b/praveenh/archive/2010/12/29/sharepoint-2010-is-now-mirroring-aware.aspx

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

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 ListenerSQL-SP

Primary Replica

Secondary Replica

Secondary Replica

SQL SERVER AVAILABILITY GROUPS PREREQUISITES

LICENSING

Every Node needs to have a Windows 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!

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.

HARDWAREREQUIREMENTS

Minimum Hardware Requirements for SQL Server 2012

Matching Hardware between nodes NOT Required

Same Drive Letters on all Nodes otherwise you will have errors!

DATABASEREQUIREMENTS

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)

AVAILABILITY GROUPS IN DETAILS

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

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

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.

SAMPLE TOPLOGIES

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

DISASTER RECOVERY

AG_Listener

Primary SQL Replica1 DR Replica

Asynchronous

Toronto Montreal

HA & DISASTER RECOVERY

AG_Listener

Primary SQL Replica1

Toronto Montreal

DR Replica

Synchronous Asynchronous

DEMO

DEMO

1. Create a Windows 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!

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 Any Time. Be prepared!

If you use Synchronous Mode, Make sure the replicas are close and have a High Bandwith Connection between them!

Join our local users groups

Toronto SharePoint Users Grouphttp://www.meetup.com/TorontoSPUG/Toronto SharePoint Business Users Grouphttp://www.meetup.com/TSPBUG/

THANKS FOR ATTENDING!

Questions?

Vlad Catrinescu@vladcatrinescu

vladcatrinescu@hotmail.com

www.sharepoint-community.net

www.absolute-sharepoint.com