View
755
Download
0
Category
Tags:
Preview:
DESCRIPTION
Slides for my talk at SharePoint Saturday Netherlands 2013
Citation preview
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
Recommended