SharePoint 2013 & SQL Server 2012 Availability Groups

Thomas Vochten

The Rough Guide

About Me

Thomas Vochten

@thomasvochtenthomasvochten.comlinkedin.com/in/thomasvochten

SharePoint consultant. Platform architect. Speaker. Trainer. Accidental DBA.

SharePointSQL Server

Agenda• Acronym Soup• Before SQL 2012• Availability Groups• Demonstration

Acronym Soup

Setting the stage…

HA• High Availability• Protecting against component failures:

operating system problemapplication pool crashwindows update gone badunplugged network cable…

Protection is typically automatic

DR• Disaster Recovery• Protecting against catastrophic failures:

storage is downdatacenter power is outnetwork backbone is down…

Protection is typically manual

RPO• Recovery Point Objective• How much data can you afford to lose?

Business decision!

RTO• Recovery Time Objective• How fast do you want to be online again?

Business decision!

RPO & RTO in Perspective

time

RPO RTO

last backup at 20:00 full recovery at 12:00outage at 08:00

12h 4h

3 days, 15 hours

8 hours, 45 mins

52 mins, 34 secs5 mins, 15 secs

99%

99,9%

99,99%

99,999%

downtime per year

SLA• Number of nines

Before SQL 2012

Failover Clustering• Tried and true technique• Evolved over time• Typically shared storage• Instance level protection• Automatic failover• Can do multi site without shared storage

Transparent for SharePoint

Mirroring• Introduced in SQL 2005 SP1• Deprecated with SQL 2012• No shared storage• Synchronous mode (high safety)• Asynchronous mode (high performance)• Automatic failover possible• Configured per database

Pre-SharePoint 2010: use sql aliasesSharePoint 2010/2013: native support

SharePoint & Mirroring• PowerShell

$db = Get-SPDatabase [UglyGuidGoesHere]$db.AddFailoverServiceInstance(“servername”)$db.Update()

• User Interface

Log Shipping• Introduced in SQL 2000• Very reliable (backup / restores)• Configured per database• Multiple secondaries• Readable secondaries• Failover is manual

Typically for SharePoint standby farms

Common Topologies

© Microsoft TechNet

Other Techniques• SQL Replication• Backup/Restore• SAN Replication

Availability Groups

SQL 2012 AlwaysOn• AlwaysOn Failover Cluster Instances• AlwaysOn Availability Groups

Both techniques are based upon Windows Server Failover Clustering (WSFC)

AG Concepts• Availability Group• Availability Replica• Availability Database• Availability Group Listener

Introducing AG• Mirroring done better• Protects groups of databases• Requires a WSFC for resource management• Up to 4 secondaries• Readable secondaries• Automatic or manual failover• Synchronous (protection)• Asychronous (performance)

Protecting SharePointHA (Single farm)

• Synchronous commits• Non readable secondaries• Auto failover

DR (Standby farm)

• Asynchronous commits• Readable secondaries• Manual failover

Other AG Benefits• Redirect read-only traffic• Redirect backup operations

Comparing TechniquesSQL Server solution

Potential data loss (RPO)

Potential recovery time (RTO)

Automatic failover Readable

secondaries

AlwaysOn Availability Group (synchronous-commit)

Zero Seconds Yes 0 - 2

AlwaysOn Availability Group (asynchronous-commit)

Seconds Minutes No 0 - 4

AlwaysOn Failover Cluster Instance

Does not apply

An FCI itself does not provide data protection. The amount of data loss depends on the storage system implementation.

Seconds to minutes Yes Does not apply

Database mirroring - High-safety (synchronous mode + witness server)

Zero Seconds Yes Does not apply

Database mirroring - High-performance (asynchronous mode)

Seconds Minutes No Does not apply

Backup, copy, restore

Hours or zero if the tail of the log can be accessed after the failure.

Hours to days No Not during a restore

© Microsoft TechNet

SharePoint Databases• Most databases support sync commits• Some databases support async commits• Content databases are supported for sync & async commits

Requirements• Windows Server 2008 or later• Windows Server Failover Cluster (WSFC)• Sufficient number of WSFC nodes• Use a domain account for SQL Server• SQL Server 2012 Enterprise only• Same SQL configuration on each node• Full recovery model only

Set Up• Wizards! For involuntary DBA’s like us • Don’t install SQL in cluster mode! Install SQL as standalone• Don’t use clustering tools to manage AG• Full recovery model needed

Steps• Configure WSFC on all nodes• Install SQL 2012 on all nodes• Enable AG on all nodes with config mgr• Full backup of all databases involved• Create AG with wizard or T-SQL to

add servers to the AGrestore full backupsconfigure optionscreate a listener

Install WSFC on all nodes

Validate & Configure WSFC

Install SQL Server on all nodes

Activate AG

DEMO

SharePoint HA• Synchronous commit• Secondaries not readable• Single farm, single datacenter• Auto failover

SharePoint DR• Asynchronous commit• Readable secondaries• Multi farm, multi datacenter• Manual failover

SQL Server 2014

• 8 secondaries in stead of 4• More reliable secondaries• Azure VMs as replicas

Currently in CTP1

Hot or Not?• All good stuff combined • Very flexible • Relatively easy to setup • Works with SharePoint • Synchronous for HA • Asynchronous / Read Only for DR • Not all databases supported • Requires SQL Server Enterprise

Getting Started – Resources

Very good collection of informationby Brent Ozar:http://thvo.me/alwayson-res

“Supported high availability and disaster recovery options for SharePoint databases”on TechNet:http://thvo.me/alwayson-sp

Q & A

@thomasvochten#spsnl13

THANK YOU