+ All Categories
Home > Technology > SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Date post: 06-Jul-2015
Category:
Upload: michael-noel
View: 831 times
Download: 3 times
Share this document with a friend
Popular Tags:
29
Silver Sponsors Gold Sponsors Bronze Sponsors SQL 2014 AlwaysOn Availability Groups for SharePoint Farms Michael Noel CCO
Transcript
Page 1: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Silver SponsorsGold Sponsors Bronze Sponsors

SQL 2014 AlwaysOn Availability Groups for SharePoint Farms

Michael NoelCCO

Page 2: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Michael Noel

Great to be back in Beautiful Australia!

Page 3: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

What we will coverSQL 2014 AlwaysOn

• What is SQL 2014 AlwaysOn?

AlwaysOn Failover Clustering

AlwaysOn Availability Groups

• Why AlwaysOn Availability Groups for SharePoint?

• Requirements and Prerequisites

• Step by Step guide to implementing AlwaysOn Availability Groups

• Demonstration

Page 4: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

SQL 2014 AlwaysOnHype or Reality?

• Introduced in SQL 2012, Improved in SQL 2014

• Two distinct technologies that share the same name

• AlwaysOn Failover Clustering is a different thing! A Failover Cluster Instance (FCI) uses traditional Shared

Storage Clustering (one copy of data shared by multiple nodes)

Same marketing name, but completely different technology

• AlwaysOn Availability Groups correspond to the new version of SQL Database Mirroring – High Availability and Disaster Recovery at the Data Tier

Page 5: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

History of AlwaysOn Availability GroupsBackground and Predecessor Technologies

• Original concept was log shipping in SQL 2000 – making a duplicate copy of your databases on another server

• Mirroring itself introduced in SQL 2005 SP1, improved in SQL 2008 and SQL 2008 R2

• Works by keeping a mirror copy of a database or databases on up to four additional SQL instances.

• AlwaysOn Availability Groups introduced with SQL 2012, added up to four additional copies, and more

• SQL 2014 improves AOAGs, allowing for Azure Replicas

• This is a huge change to data tier design for SharePoint

Page 6: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Disaster Recovery

SQL 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 NA Seconds

-to-minutes

Yes NA

Database Mirroring - High-safety (sync + witness) Zero Seconds Yes NA

Database Mirroring - High-performance (async) Seconds Minutes No NA

Log Shipping Minutes Minutes

-to-hours

No Not during

a restore

Backup, Copy, Restore Hours Hours

-to-days

No Not during

a restore

Comparison of AlwaysOn with other SQL HAGreatly Improved HA and DR

Page 7: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

AlwaysOn Availability GroupsDesign Options

• Create up to four additional copies of each database on a different SQL node

• Copies can be a mix of synchronous (exact copy) or asynchronous (works across low latency link, but only supports content DBs and Secure Store DB)

• Create a synchronous copy when connectivity is 1Gb or greater and latency is no more than 1ms

• Create asynchronous copies across WAN links, for Disaster Recovery or when architecting a read-only farm

• NEW! In SQL 2014, create an Azure Replica of your SQL Database

Page 8: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

AlwaysOn Availability GroupsRead-only Farms

• Unlike SQL Mirroring, AlwaysOn Availability Groups allow for read-only access to the content on a remote SQL instance

• Allows for the DR copy of the data to be used as part of a view-only SharePoint farm in a remote location

• Requires a separate SharePoint farm from the production read/write farm

• Remote replica cannot be directly accessed in SharePoint, however, a copy-only replica (or snapshot) must be used

Page 9: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Sample AOAG Design for SharePoint

• Two AGs

• Content AG with four replicas –Synch and Asynch

• User Profile Sync DBs on separate AG, 2 Synch copies only

• DR farm in remote DC on standby to connect to content DB copy

• DR copy in Azure

Page 10: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

AlwaysOn Availability GroupsSynchronous vs. Asynchronous Database Support

• All SharePoint 2013 (and nearly all SharePoint 2010) databases now support Synchronous Replication (either via Mirroring or AOAGs)

• All SharePoint databases support both asynchronous and synchronous replication…with the exception of the User Profile Sync databases

• This is why it is considered best practice to create at least two AOAGs for SharePoint…one for synchronous-only DBs like the UPA databases and another for flexible database types which can be replicated to remote locations, etc.

• This is a key point, remember, you CANNOT replicate databases synchronously unless you have 1Gb+ bandwidth and less than 1ms* of latency!

Page 11: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

AlwaysOn Availability Groups for SharePointImproving Data Tier High Availability and Disaster Recovery

• Completely changes the design options for the data tier

• Allows for ‘Exchange Server’ like multi-copy database server failover on multiple replicas at the same time

• The equivalent of running a constant backup of your databases

• Can be used to create HA/DR copies of your SharePoint databases

• SharePoint no longer needs to be ‘aware’ of the mirrored copy (in fact, it won’t failover if you configure it manually in SPCA.) SharePoint connects to the listener (Client Access Point) which is clustered

• SharePoint 2010 Service Pack 1 supports SQL 2012 fully, as does SharePoint 2013

• SharePoint 2013 Service Pack 1 supports SQL 2014

CAVEAT: Be sure to understand that synchronous AOAG copies need to be in close proximity and have very good bandwidth, as data needs to be written into all replicas before the transaction is committed. SharePoint will lock up if there are any interruptions at the data tier.

Page 12: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

AlwaysOn Availability GroupsVersion Requirements

• Windows Server 2008 R2 (w SP1 ideally, as patches are required) – Enterprise Edition or Windows Server 2012/2012 R2 Standard/Datacenter

One per node

Can use Virtualization licensing options

Windows Server 2012/2012 R2 also possible (and recommended.)

• SQL Server 2014/2012 Enterprise Edition

MS has moved away from per-socket licenses. Licenses are now 1/4th the cost, but are now per each core.

Legacy licenses of SQL 2008/2008 R2 Enterprise are ‘grandfathered in’ if you have upgrade assurance

Page 13: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

AlwaysOn Availability GroupsPrerequisites and Requirements – Windows Server 2008 R2 Only

• Cannot be installed on a Domain Controller

• Must be Windows Server 2008 or later versions (2014 or 2008 R2 highly preferred)

• Must be a node in a Windows Server Failover Clustering (WSFC) cluster.

• Ensure that all applicable Window hotfixes have been installed on every node in the WSFC cluster, including SP1 for Windows 2008 R2 ideally. Additional patches required for SQL 2014 AlwaysOn Availability Groups include the following: http://support.microsoft.com/kb/976097 (Asymmetric Storage)

http://support.microsoft.com/kb/2494036 (Node Weight Fix)

http://support.microsoft.com/kb/2531907 (SCSI Device Test Failure)

http://support.microsoft.com/kb/2616514 (Unneeded Reg Key Change Notifications)

http://support.microsoft.com/kb/2654347 (Net 35 Always On Features)

http://support.microsoft.com/kb/980915 (IPSecConnection Delay) - Not needed if not using IPSec

http://support.microsoft.com/kb/2578113 (IPv6 Long Failover) - Not needed if you aren’t using IPv6

http://support.microsoft.com/kb/2582281 (Slow Failover with No Router) – Not needed in most scenarios, review to determine if it applies to you

• NOTE: Some of these patches have been superseded depending on your OS and SQL versions

Page 14: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

AlwaysOn Availability GroupsPrerequisites and Requirements – SQL Server

• If you plan to use a SQL Server failover cluster instance (FCI) to host an availability replica, ensure that you understand the FCI restrictions and that the FCI requirements are met (Manual config required)

• All the server instances that host availability replicas for an availability group must use the same SQL Server collation.

• If any databases that use FILESTREAM will be added to an availability group, ensure that FILESTREAM is enabled on every server instance that will host an availability replica for the availability group.

Page 15: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

AlwaysOn Availability GroupsCluster Witness and Voting Fundamentals

• Automatic failover clustering requires servers to have the proper number of votes to ‘turn on’ a database copy.

• There must always be a majority of votes to enable the node.

• If a majority cannot be reached (for example, if there are only an even number of votes) the DBs will remain offline.

• File Servers can act as File Share Witness (FSW) servers (additional votes.)

• This avoids split-brain scenarios where multiple copies of a DB are online.

• Be sure to give the Cluster Computer Account Full control to the FSW Share

Page 16: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Flush Logs in an AOAG Environment

• Any DB in FULL recovery mode (required for AOAGs) will continue to grow logs indefinitely

• Be sure to run a full backup, then a transaction log backup from SQL. This will clear out logs but not shrink them

• To shrink, you need to also run DBCC SHRINKFILE after the backups

• For databases that don’t need to be restored, you can backup to ‘NULL’ (effectively fooling SharePoint that it has been backed up. NOTE: This does not backup any data, simply allows the logs to be flushed out.

Page 17: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Script to Backup to NULL and Flush logs

USE SPF1_ConfigDB;

BACKUP DATABASE SPF1_ConfigDB TO DISK='NUL:';

GO

BACKUP LOG SPF1_ConfigDB TO DISK='NUL:';

GO

DBCC SHRINKFILE(SPF1_ConfigDB_log,1000)

GO

• NOTE: This sample backs up to NULL, which effectively means it’s only flushing the logs. Replace ‘NUL’ with the backup location for your environment for any databases that you need recovery from

Page 18: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Creating AlwaysOn Availability GroupsStep 1: Create Windows Server Failover Cluster (WSFC)

• Install Windows Server on multiple nodes

• Patch with Critical, Security, and the specific OS patches listed in previous slide

• Enable the Failover Cluster Feature on each node

• Use the Failover Cluster Manager Wizard to create a cluster.

• Name the cluster a unique name that will be separate from the instance name that will be used for SharePoint

Page 19: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Creating AlwaysOn Availability GroupsStep 2: Prepare Nodes

• Install .NET Services 3.5 Feature on each SQL node

• Install SQL 2014 Enterprise Edition Database Services (Also recommend adding SQL Management Tools – Complete)

• Ensure proper Windows Firewall ports are open

• Service Account for SQL

Use the same service account for all nodes

Don’t use Network Service

If using Kerberos, make sure all SQL names have SPNs associated with the service account

• Make sure databases are set to FULL recovery mode

• Ensure that the file paths and drive letters are consistent throughout all instances (ideally, or config will have to be manual)

• Copy or Create SharePoint databases on Primary node only (use SQL Alias to change name later)

• Perform a full backup of your SharePoint databases

• Create a file share location that is accessible by all nodes that will be used for the shared backups (i.e. \\SQL1\Backups)

Page 20: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Creating AlwaysOn Availability GroupsStep 2: Enable AlwaysOn on each SQL Node

• Enable AlwaysOn High Availability in SQL Server Configuration Manager

• Repeat on Each Node

• Restart SQL Services

Page 21: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Creating AlwaysOn Availability GroupsStep 3: Create the Availability Group

• Ideally use the New Availability Group Wizard, it automates the process

Page 22: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Creating AlwaysOn Availability GroupsStep 3: Create the Availability Group – Continued…

• Be sure to have a shared network location for the backup files (Created in earlier step)

• Depending on size of databases, this could take a while

• Backups can also be pre-staged (Join Only)

Page 23: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Creating AlwaysOn Availability GroupsStep 3: Create the Availability Group – Continued…

• Validation should show all green (some exceptions)

• The listener (‘SQL’ in this example) will be created later, and is required for SharePoint to connect to

Page 24: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Creating AlwaysOn Availability GroupsStep 4: Create the Availability Group Listener

• After the wizard completes, manually create the Availability Group Listener

• This is the shared name that SharePoint will connect to and will provide failover (Also called the ‘Client Access Point’)

• Modify the DNS record for this listener to have a low TTL (60 seconds or less) for cross-subnet failover scenarios

Page 25: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

• Required in specific situations, such as when a DB is encrypted

• First, add the DB to the primary server (where the DB is attached to with the following syntax: ALTER AVAILABILITY GROUP SPDBCONTENT

ADD DATABASE SPF1_Content_TDE

GO

• Then restore the DB onto the secondary server, ensuring that you choose ‘RESTORE WITH NORECOVERY’ from the Options tab

• Finally, add the DB to the AG on the Secondary server ALTER DATABASE SPF1_Content_TDE SET HADR AVAILABILITY GROUP =

SPDBCONTENT;

GO

Creating AlwaysOn Availability GroupsManual Process: Adding a DB to an Availability Group

Page 26: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014
Page 27: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

• Throw away all previous data tier designs for SharePoint!

• SQL 2014 AlwaysOn Availability Groups are the preferred design option for High Availability and Disaster Recovery at the data tier

• SQL 2014 is fully supported by SharePoint 2013 Service Pack 1 databases (And SQL 2012 is supported by SharePoint 2010 Service Pack 1) – but remember that the User Profile Sync databases don’t support asynchronous databases!

• Best Practice is to create at least two AGs for SharePoint – One for Synchronous and the other for asynchronous databases

• Follow closely the guidelines, ensure data paths are the same, double-check security requirements

• Plan to shrink your log files on a daily basis for non-content DBs as they will grow quickly, particularly the search databases

Session SummarySQL 2014 AlwaysOn Availability Groups for SharePoint

Page 28: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Silver SponsorsGold Sponsors Bronze Sponsors

Thanks for listeningRemember to submit your feedback so you go in the draw to win prizes at the end of the day

Page 29: SQL 2014 AlwaysOn Availability Groups for SharePoint Farms - SPS Sydney 2014

Michael NoelTwitter: @MichaelTNoel

www.cco.comSlides: slideshare.net/michaeltnoelTravel blog: sharingtheglobe.com

SharePoint 2013 Unleashed:tinyurl.com/sp2013unleashed


Recommended