Anda di halaman 1dari 40

AlwaysOn Availability Groups for

SharePoint On-Premises and Azure SQL


Replicas : HA/DR

Lars Platzdasch
MCT,MCSE SQL, MCSE SharePoint
Sprecher:

Lars Platzdasch
Twitter platzdasch netConsult GmbH & Co. KG | ISV
@LarsPlatzdasch 24/7 Support fr SQL / SharePoint

Xing 3 Perspektiven GmbH | MBS


/Lars_Platzdasch
21 IT, 19 Jahre SQL Server, 14 Jahre SharePoint
LinkedIn MCT: SQL, SharePoint, .net
LarsPlatzdasch MCSE: SQL Server Data Platform
MCSE: SharePoint
Web MCITP: SharePoint 2010, Administrator
www.platzdasch.de MCITP: SharePoint 2010, Developer
www.3perspektiven.de Microsoft Certified Application Developer: .NET
Certified Ethical Hacker (CEH) - EC-Council
AGENDA SQL SERVER ALWAYSON FOR SHAREPOINT

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
SQL SERVER ALWAYSON
SQL SERVER ALWAYSON

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 8 total replicas of a database

Marketing Name: AlwaysOn -> FCI != AOAGS


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 4 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
COMPARISON OF ALWAYSON WITH OTHER SQL SERVER HA/DR
Potential Potential
Automatic Readable
Disaster Recovery SQL Server Solution Data Loss Recovery
Failover Secondaries
(RPO) Time (RTO)
AlwaysOn Availability Group - synchronous-commit Zero Seconds Yes 0 2(3)

AlwaysOn Availability Group - asynchronous-commit Seconds Minutes No 0 4(8)

AlwaysOn Failover Cluster Instance NA Seconds Yes NA


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

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

Log Shipping Minutes Minutes No Not during


-to-hours a restore
Backup, Copy, Restore Hours Hours No Not during
-to-days a restore
ALWAYSON AVAILABILITY GROUPS

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
SHAREPOINT AND
SQL SERVER BASICS ALWAYSON
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
ALWAYSON AVAILABILITY GROUPS
SYNCHRONOUS VS. ASYNCHRONOUS DATABASE SUPPORT
This is why it is considered best practice to create at
least two AOAGs for SharePointone 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!
SHAREPOINT
Recommended
Database Synchronous Asynchronous
AOAG

DATABASE Content Databases Yes Yes AOAG1 Content

COMPATIBILITY App Management Yes Yes AOAG2 SA-ASync

WITH AOAG
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
All Databases supported for
Project Server Yes Yes AOAG2 SA-ASync
synchronous failover
Secure Store Yes Yes AOAG2 SA-ASync
Recently, Microsoft added Subscription Settings Yes Yes AOAG2 SA-ASync
asynchronous failover support for Machine Translation Services Yes Yes AOAG2 SA-ASync
certain non-content DB types Word Automation Yes Yes AOAG2 SA-ASync
Other Service Application types UPA Profile Yes Yes AOAG2 SA-ASync
are still unsupported for UPA Social Yes Yes AOAG2 SA-ASync
asynchronous failover, though they UPA Sync Yes No AOAG3 SA-Sync
are either not needed in a DR Config Yes No AOAG3 SA-Sync
scenario or can be easily recreated Central Admin Yes No AOAG3 SA-Sync
Highly consider the creation of Search Analytic Reporting Yes No AOAG3 SA-Sync
multiple AOAGs, two at a minimum, Search Admin Yes No AOAG3 SA-Sync
three ideal, and even four or five Search Crawl Yes No AOAG3 SA-Sync
may be common allows for Search Links Yes No AOAG3 SA-Sync
greatest flexibility of failover State Service Yes No AOAG3 SA-Sync
Usage Yes No AOAG3 SA-Sync
SAMPLE AOAG DESIGN FOR SHAREPOINT

-min two Ags ( better 3 )


-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
ALWAYS ON AVAILABILITY & SHAREPOINT

High FARM 1

Availabilty Synchron (no data loss)

SQL 1 SQL 2
ALWAYS ON AVAILABILITY & SHAREPOINT

High
Availabilty FARM 1

Synchronous

SQL 1 SQL 2
HA SYNC COMMIT

Sync

Config Config
AWOAG3-SA-SYNC
Central admin Central admin

State State

SP FARM Usage Usage


MUC
Content Content AWOAG1-Content
User Profile User Profile

BDC BDC

AWOAG2-SA-SYNC
Managed Meta Managed Meta

Search Search
SET UP: FARM IN MUC
(MAIN FARM)

Install the SharePoint farm in


MUC
$configDB = ...
SharePoint 2013 with SP1 and CU April 2014 or SP2016
3 aliases : 1 for content DB, 1 for Services DB, 1 for farm DB (CA, Config, State).
3 SQL
$alias1 aliases
= SQL1
$alias2 = SQL2
$alias1 = AVG1 listener
$alias3 = SQL3
$alias2 = AVG2 listener Everything can
Recovery mode to full for databases to be sync
$alias3
Configure = AVG3 listener
SharePoint DB
New-SPConfigurationDatabase easily be scripted !
SharePoint databases Full Backup
-databaseName $ConfigDB -DatabaseServer $alias1
!!! In Test take log backups
New-SPWebApplication -DatabaseServer $alias2
New-SPMetadataServiceApplication -DatabaseServer $alias3
New-SPEnterpriseSearchServiceApplication -DatabaseServer
Create Windows $alias1
Cluster and add every SQL Node
Configure SQL Server Cluster Create 3 Always On AG & Add SharePoint DB
Create the 3 listeners (1/AVG)
& Always On Copy SP logins & permissions and other server objects on every node
DR WITH ALWAYS ON AVAILABILITY GROUPS & SHAREPOINT
(ACTIVE/PASSIVE)

FARM 1 FARM 2

Synchronous (no data loss)


Asynchronous (potential data loss)

SQL 1 SQL 2 SQL 3

Disaster
Recovery
DR WITH ALWAYS ON AVAILABILITY GROUPS & SHAREPOINT
(ACTIVE/PASSIVE)

Sync SP FARM
SP FARM Config Config Config AZUR / ..
MUC
Central admin Central admin
(DR)
Central admin

State State State

Usage Usage Async Usage

Content Content Content

User Profile User Profile User Profile

BDC BDC BDC

Managed Meta Managed Meta Managed Meta

Search Search Search !!!

SQL01 SQL02 SQL03


SET UP: FARM IN AZURE / DR SITE

Install the SharePoint farm in SharePoint 2013 with SP1 and CU April 2014 or SP2016
AZURE / DR 3 aliases : 1 for content DB, 1 for Services DB, 1 for farm DB (CA, Config, State).
Aliases can point to listeners (not mandatory)
3 SQL aliases
Everything can
easily be scripted !
Test,Test,Test Test DR failover with SharePoint
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
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.
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
ADDITIONAL SQL 2014/2016 AOAG CONSIDERATIONS AND
PREREQUISITES
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 -> FULL transaction mode ( .. is not the default
for certain SP databases)
ADDITIONAL SQL 2014/2016 AOAG CONSIDERATIONS AND
PREREQUISITES
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
Dont forget to flush the logs with a backup script on a regular
basis! Search and Config DBs will grow large quickly.
Dont forget about SPNs for Kerberos and use Aliases for
Listeners
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 dont 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.
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 its only flushing the logs. Replace NUL with the
backup location for your environment for any databases that
you need recovery from
AOAG STEP BY STEP
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
CREATING ALWAYSON AVAILABILITY GROUPS
STEP 2: PREPARE NODES
Install .NET Services 3.5 Feature on each SQL node
Install SQL 2014/6 Enterprise Edition Database Services (Also recommend adding SQL
Management Tools Complete)
Ensure proper Windows Firewall ports are open ( 1433, 5022 )
Service Account for SQL
Use the same service account for all nodes
Dont 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)
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
CREATING ALWAYSON AVAILABILITY GROUPS
STEP 3: CREATE THE AVAILABILITY GROUP

Ideally use the New Availability Group


Wizard, it automates the process
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)
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
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
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
SESSION SUMMARY
SQL 2014/2016 ALWAYSON AVAILABILITY GROUPS 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(..3) 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
VIELEN DANK FR EURE ZEIT

Q&A

Lars Platzdasch | SharePoint and SQL Server


Links
Code
https://github.com/larspl/AlwaysOnAvailabilityGroupsforShareP
oint
Plan for high availability and disaster recovery for SharePoint
Server 2016
https://technet.microsoft.com/en-
us/library/cc263031(v=office.16).aspx