This document discusses SQL 2014 AlwaysOn Availability Groups for implementing high availability and disaster recovery for SharePoint farms. It provides an overview of AlwaysOn, requirements, design options, and a step-by-step guide for setting up an AlwaysOn Availability Group. Key points include that AlwaysOn allows multiple read-only copies of databases across servers, improves on previous mirroring technologies, and changes how the data tier should be designed for SharePoint.

1. SQL 2014 AlwaysOn Availability
Groups for SharePoint Farms
Michael Noel
CCO
Gold Sponsors Silver Sponsors Bronze Sponsors

2. Michael Noel
Great to be back in Beautiful Australia!

3. What we will cover
SQL 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

4. SQL 2014 AlwaysOn
Hype 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

5. History of AlwaysOn Availability Groups
Background 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

6. 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 HA
Greatly Improved HA and DR

7. AlwaysOn Availability Groups
Design 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

8. AlwaysOn Availability Groups
Read-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

9. 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

10. AlwaysOn Availability Groups
Synchronous 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!

11. AlwaysOn Availability Groups for SharePoint
Improving 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.

12. AlwaysOn Availability Groups
Version 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

13. AlwaysOn Availability Groups
Prerequisites 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

14. AlwaysOn Availability Groups
Prerequisites 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.

15. AlwaysOn Availability Groups
Cluster 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

16. 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.

17. 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

18. Creating AlwaysOn Availability Groups
Step 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

19. Creating AlwaysOn Availability Groups
Step 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. SQL1Backups)

20. Creating AlwaysOn Availability Groups
Step 2: Enable AlwaysOn on each SQL Node
• Enable AlwaysOn High
Availability in SQL
Server Configuration
Manager
• Repeat on Each Node
• Restart SQL Services

21. Creating AlwaysOn Availability Groups
Step 3: Create the Availability Group
• Ideally use the New Availability
Group Wizard, it automates the
process

22. Creating AlwaysOn Availability Groups
Step 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)

23. Creating AlwaysOn Availability Groups
Step 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

24. Creating AlwaysOn Availability Groups
Step 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

25. Creating AlwaysOn Availability Groups
Manual Process: Adding a DB to an Availability Group
• 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

27. Session Summary
SQL 2014 AlwaysOn Availability Groups for SharePoint
• 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

28. Thanks for listening
Remember to submit your feedback so you go in the
draw to win prizes at the end of the day
Gold Sponsors Silver Sponsors Bronze Sponsors

29. Michael Noel
Twitter: @MichaelTNoel
www.cco.com
Slides: slideshare.net/michaeltnoel
Travel blog: sharingtheglobe.com
SharePoint 2013 Unleashed:
tinyurl.com/sp2013unleashed