Deciding upon a SQL High-Availability Strategy for SharePoint EnvironmentVictor Isakov

APT008

Victor IsakovVictor Isakov is a Database Architect / Trainer / Author who provides consulting and training services to various organizations in the public, private and NGO sectors globally. He participates in different capacities at various international events and conferences. Victor specializes in:• Designing SQL Server infrastructure solutions and upgrade

strategies• Architecting OLTP, DSS and DW database solutions• Performance troubleshooting and optimization• Customized on-premise training and mentoring

Email victor@sqlserversolutions.com.au

Blog www.victorisakov.com

Twitter @victorisakov

LinkedIn www.linkedin.com/in/victorisakov

Website www.sqlserversolutions.com.au

AbstractDesigning a High-Availability solution for SharePoint at the SQL Server level has traditionally been difficult due to a different release cadence. In this session Victor Isakov (MCA, MCM, MCT, MVP) will present on the different SQL Server high-availability technologies available for a SharePoint farm. Victor will discuss their respective pros and cons, as well as Microsoft’s strategic direction in this space, which will help you decide what high availability solution suits you best.

Agenda

• Decision Criteria• Fail-over Clustering• Availability Groups• Database Mirroring• Log Shipping• General Recommendations

Decision Criteria

• Primary Considerations• Secondary Considerations• SQL Server Considerations

Decision CriteriaPrimary Considerations

• Business needs to define high-availability requirements• Define Service Level Agreements (SLAs) around availability

• Important to understand the technology• Important to get the quorum model right

• Design is everything!• Need to think about redundancy at every level

Decision CriteriaSecondary Considerations

• Ease of implementation• Ease of administration• Are you implementing Remote BLOB Storage

(RBS)?• How are you going to achieve HA for RBS?

Decision CriteriaSQL Server Considerations

• Availability Groups are only available in SQL Server Enterprise Edition

• SQL Server Standard Edition supports only 2 nodes in a fail-over cluster

• From SQL Server 2008 R2, Standard Edition supports only 64GB of RAM

• Microsoft changed DR licensing in SQL Server 2012• You can have only one DR SQL Server instance for free

High-Availability Comparison

Technology Commit

RPO RTO Automatic Failover

Readable Secondaries

Minimum SQL Server

Edition Version

Failover Clustering

Zero sec - min Yes No Standard 2005

Availability Groups

Sync Zero sec - min Possible Possible Enterprise

2012

Async sec – min

sec – min No Possible Enterprise

2012

Database Mirroring*(High-Safety)

Sync Zero sec – min Possible No Standard 2005

Database Mirroring*(High-Performance)

Async sec – min

sec – min No No Standard 2005

Log Shipping min min – hr No Possible* Standard 2005

Failover Clustering

• Architecture• Pros• Cons

Fail-over Clustering: Architecture

Fail-over ClusteringPros

• Automatic fail-over• Generally fast fail over• Very much depends on what exactly has gone wrong and

how quickly it takes the SQL Server / Clustering technology to detect problem

• Very easy to maintain• No need to worry about logins, jobs, etc• Windows Server 2012 supports Cluster Aware Updating (CAU)

• Very easy to set up with SharePoint • Databases can use any RECOVERY model

Fail-over ClusteringCons

• Shared storage represents the “weakest link”• No redundancy at shared storage level

• Only a single instance of SQL Server running at a time• Not a scale-out technology

• Geo-clustering typically requires a hardware solution• SQL Server 2012 supports multi-subnet fail-over clusters

• “Fail-over not as quick as Availability Groups / Database Mirroring”

Availability Groups

• Architecture• Pros• Cons

Availability Groups: Architecture

Availability GroupsPros

• Availability Group represents a container / unit of failover• Can separate content databases from service databases

• Can have up to 4 replicas• One primary and 4 secondary replicas• SQL Server 2014 increases this limit to 8

• Can off-load certain activities to secondary replica(s)• Database backups (COPY_ONLY), transaction log backups,

database consistency checks• Need to license replicas that are performing these activities

Availability GroupsPros

• Automatic fail-over• Generally fast fail over• No shared disk• “Fail over quicker than fail-over clustering”• Asynchronous versus Synchronous “Commit”• Automatic failover requires synchronous• Asynchronous better for remote sites

• Support Readable Secondaries

Availability GroupsCons

• SharePoint 2010 SP1 / 2013 does support the full gamut Availability Groups’ features• Read-only access not natively supported (READ_INTENT)• Can have separate SharePoint farm accessing read-only

replica

• All databases have to use FULL recovery model• More complicated to set up with SharePoint• Requires Enterprise Edition• Can only have one DR replica for free

Database Mirroring

• Architecture• Pros• Cons

Database Mirroring: Architecture

Database MirroringPros

• Automatic fail-over• Generally fast fail over• “Fail over quicker than fail-over clustering”• No shared disk• Available in Standard Edition

Database MirroringCons

• DEPRECATED FEATURE• Automatic fail-over requires separate SQL Server

instance• Implemented at database level• Can have scenario where one of multiple databases fails over

• More complicated to set up with SharePoint• Within SharePoint• Logins, jobs, etc

Database MirroringCons

• Databases need to be in FULL recovery model• Can only have one mirrored database• Cannot access mirrored database• Exception: Database snapshots

• Need to be careful with SQL Server’s resource consumption• The more databases that are mirrored the more threads are

consumed

Log Shipping

• Architecture• Pros• Cons

Log Shipping: Architecture

Log-ShippingPros

• Great technology for off-site DR• Does not require low latency networks• Scheduled:• Whatever is required: Hourly, daily, (every minute)

• Great for recovering from user error, such as accidental deletion

Log-ShippingCons

• No automatic fail-over• Manual fail over a bit complicated• Fail-back is even worse!• Databases cannot use SIMPLE recovery model• Need to take into account your backup strategy

General Recommendations

• Make sure you design appropriately and test the redundancy of every component of your high-availability solution

• Try to use the latest version of Windows Server• Window Server 2012 (R2) Standard Edition

• Make sure you install all the latest cluster hotfixes for Fail-over Clustering and Availability Groups

• Understand what complexity SharePoint adds

Developer Network

Resources for Developers

http://msdn.microsoft.com/en-au/

Learning

Virtual Academy

http://www.microsoftvirtualacademy.com/

TechNet

Resources

Sessions on Demand

http://channel9.msdn.com/Events/TechEd/Australia/2013

Resources for IT Professionals

http://technet.microsoft.com/en-au/

© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.