SQL Server 2016 provides for unprecedented high availability and disaster recovery options for SharePoint farms in the form of AlwaysOn Availability Groups. Using this new technology, SharePoint architects can provide for near-instant failover at the data tier, without the risk of any data loss. In addition, the latest version of this technology, available with SQL Server 2016, allows for replicas of SharePoint databases to be stored in the cloud in Microsoft’s Azure cloud offering. This technology, which will be demonstrated live, completely changes the data tier design options for SharePoint and revolutionises high availability options for a farm. This session covers in step-by-step detail the exact configuration required to enable this functionality for a SharePoint 2013 farm, based on the best practices, tips and tricks, and real-world experience of the presenter in deploying this technology in production.
Understand the differences between SQL AlwaysOn options, and determine the requirements to deploy the technologies
Examine how SQL Server 2016 AlwaysOn Availability Groups can provide aggressive Service Level Agreements (SLAs) with a Recovery Point Objective (RPO) of zero and a Recovery Time Objective (RTO) of a few seconds.
See the exact steps required to enable SQL Server 2016 AlwaysOn Availability Groups for a SharePoint 2013 On-Premises environment, including options for storing replicas in Microsoft’s Azure cloud service.
3. What we will cover
SQL Server AlwaysOn
What is SQL Server 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. Two distinct AlwaysOn technologies available
‒ AlwaysOn Failover Cluster Instance (FCI)
A ‘traditional’ cluster – uses shared storage and network
One copy of data shared by multiple nodes
‒ AlwaysOn Availability Groups (AOAGs)
Equivalent to a combination of traditional SQL Mirroring concepts together
with clustering
Multiple replicas of databases split across different cluster nodes
Uses ‘Shared Nothing’ cluster concepts
Allows for up to nine total replicas of a database
Same marketing name, but completely
different technologies
SQL Server AlwaysOn
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, improved in
SQL 2014, and later in SQL 2016
This is a huge change to data tier design for SharePoint
6. Comparison of AlwaysOn with other SQL
Server HA/DR
High Availability and 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 - 8
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
7. Create up to eight additional copies of each database on
different SQL nodes (Nine total replicas)
Copies can be a mix of synchronous (exact copy, limited
to two additional replicas) or asynchronous
Create a synchronous copy when connectivity is 1Gb or
greater and latency is no more than 1ms on average
Create asynchronous copies across WAN links, for
Disaster Recovery or when architecting a read-only farm
AlwaysOn Availability Groups
8. AlwaysOn Availability Groups
Synchronous vs. Asynchronous Database Support
Virtually all SharePoint 2013/2016 (and many SharePoint 2010) databases
now support Synchronous Replication (either via Mirroring or AOAGs)
Up until recently, only Content Databases and the Secure Store Database
supported Asynchronous Replication
Now, Microsoft supports Asynchronous replication for all but the User
Profile Sync databases
This is why it is considered best practice to create at least two AOAGs
for SharePoint…one for the asynchronous-only Databases, which can be
replicated to remote locations, etc., and one for the synchronous
databases
This is a key point, remember, you CANNOT replicate databases
synchronously unless you have 1Gb+ bandwidth and less than 1ms of
latency!
9. SharePoint Database
Compatibility with
AOAG
Database Synchronous Asynchronous
Recommended
AOAG
Content Databases Yes Yes AOAG1 – Content
App Management Yes Yes AOAG2 – SA-ASync
BCS Yes Yes AOAG2 – SA-ASync
Managed Metadata Yes Yes AOAG2 – SA-ASync
PerformancePoint Yes Yes AOAG2 – SA-ASync
PowerPivot Yes Yes AOAG2 – SA-ASync
Project Server Yes Yes AOAG2 – SA-ASync
Secure Store Yes Yes AOAG2 – SA-ASync
Subscription Settings Yes Yes AOAG2 – SA-ASync
Machine Translation Services Yes Yes AOAG2 – SA-ASync
Word Automation Yes Yes AOAG2 – SA-ASync
UPA Profile Yes Yes AOAG2 – SA-ASync
UPA Social Yes Yes AOAG2 – SA-ASync
UPA Sync Yes No AOAG3 – SA-Sync
Config Yes No AOAG3 – SA-Sync
Central Admin Yes No AOAG3 – SA-Sync
Search Analytic Reporting Yes No AOAG3 – SA-Sync
Search Admin Yes No AOAG3 – SA-Sync
Search Crawl Yes No AOAG3 – SA-Sync
Search Links Yes No AOAG3 – SA-Sync
State Service Yes No AOAG3 – SA-Sync
Usage Yes No AOAG3 – SA-Sync
All Databases supported for
synchronous failover
Recently, Microsoft added
asynchronous failover support for
certain non-content DB types
Other Service Application types are
still unsupported for asynchronous
failover, though they are either not
needed in a DR scenario or can be
easily recreated
Highly consider the creation of
multiple AOAGs, two at a minimum,
three ideal, and even four or five may
be common – allows for greatest
flexibility of failover
11. AlwaysOn Availability Groups
Version Requirements
Windows Server
‒ Windows Server 2008 R2 (w SP1 or greater) – Enterprise Edition
‒ (PREFERRED) Windows Server 2012/2012 R2/2016 Standard/Datacenter
‒ One per node
‒ Can use Virtualization licensing options
SQL Server 2012/2014/2016 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
12. 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.
13. 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.)
• NEW – Add an Azure File Share Witness!
• 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
14. SharePoint must be 2010 SP1+/2013/2016. For full Asynch support, 2013 SP1 April
2014 CU+ or greater.
New databases in your farm are not added by default, they must be manually added
All databases must have a full backup run before adding to an AOAG
All databases must be running in FULL transaction mode (which is not the default
for certain SP databases)
Be sure to copy SQL security accounts to all nodes in the cluster or SharePoint will
fail to reconnect
Use the same SQL service accounts on all nodes
Highly recommend to use the same drive paths on all nodes
Don’t forget to flush the logs with a backup script on a regular basis! Search and
Config DBs will grow large quickly.
Don’t forget about SPNs for Kerberos and use Aliases for Listeners
Additional SQL 2014/2016 AOAG Considerations
and Prerequisites
15. 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.
16. Script to Backup to NULL and Flush logs
USE SPF1_ConfigDB;
BACKUP DATABASE SPF1_ConfigDB TO DISK='NUL:';
BACKUP LOG SPF1_ConfigDB TO DISK='NUL:';
DBCC SHRINKFILE(SPF1_ConfigDB_log,1000)
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
17. 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
18. 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)
19. 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
20. Creating AlwaysOn Availability Groups
Step 3: Create the Availability Group
Ideally use the New Availability Group
Wizard, it automates the process
21. 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)
22. 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
23. 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
24. 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 Groups
Manual Process: Adding a DB to an Availability Group
25. Working with SQL Server AlwaysOn Availability Groups for SharePoint On-
Premises Farms
26. Throw away all previous data tier designs for SharePoint On-
Premises!
SQL Server AlwaysOn Availability Groups are the preferred
design option for High Availability and Disaster Recovery at the
data tier
Best Practice is to create at least two AGs for SharePoint – One
for Synchronous DBs and the other for asynchronous DBs
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 Summary
SQL 2014/2016 AlwaysOn Availability Groups for SharePoint On-Premises