AUDWC 2016 - Using SQL Server 20146 AlwaysOn Availability Groups for SharePoint On-Premises and...
-
Upload
michael-noel -
Category
Technology
-
view
778 -
download
5
Transcript of AUDWC 2016 - Using SQL Server 20146 AlwaysOn Availability Groups for SharePoint On-Premises and...
Using SQL Server 2014 AlwaysOn Availability Groups for SharePoint
On-Premises and Azure SQL ReplicasMichael Noel
Michael Noel
Great to be back in Beautiful Australia!
What we will coverSQL Server AlwaysOn
What is SQL Server AlwaysOn?‒AlwaysOn Failover Clustering‒AlwaysOn Availability Groups
Why AlwaysOn Availability Groups for SharePoint?
Requirements and PrerequisitesStep by Step guide to implementing AlwaysOn Availability Groups
Demonstration
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
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, 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/DRHigh Availability and Disaster Recovery
SQL Server SolutionPotential 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 duringa restore
Backup, Copy, Restore Hours Hours-to-days
No Not duringa restore
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
AlwaysOn Availability GroupsSynchronous 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!
SharePoint Database Compatibility with AOAG
Database Synchronous Asynchronous Recommended AOAG
Content Databases Yes Yes AOAG1 – ContentApp Management Yes Yes AOAG2 – SA-ASyncBCS Yes Yes AOAG2 – SA-ASyncManaged Metadata Yes Yes AOAG2 – SA-ASyncPerformancePoint Yes Yes AOAG2 – SA-ASyncPowerPivot Yes Yes AOAG2 – SA-ASyncProject Server Yes Yes AOAG2 – SA-ASyncSecure Store Yes Yes AOAG2 – SA-ASyncSubscription Settings Yes Yes AOAG2 – SA-ASyncMachine Translation Services Yes Yes AOAG2 – SA-ASyncWord Automation Yes Yes AOAG2 – SA-ASyncUPA Profile Yes Yes AOAG2 – SA-ASyncUPA Social Yes Yes AOAG2 – SA-ASyncUPA Sync Yes No AOAG3 – SA-SyncConfig Yes No AOAG3 – SA-SyncCentral Admin Yes No AOAG3 – SA-SyncSearch Analytic Reporting Yes No AOAG3 – SA-SyncSearch Admin Yes No AOAG3 – SA-SyncSearch Crawl Yes No AOAG3 – SA-SyncSearch Links Yes No AOAG3 – SA-SyncState Service Yes No AOAG3 – SA-SyncUsage 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
Sample AOAG Design for SharePoint• Two AOAGs (More is ideal)• Content AG with four
replicas – Synch and Asynch
• Service App/Farm DBs on at least two separate AGs
• DR farm in remote DC on standby to connect to content DB copy
• Windows Azure replica
AlwaysOn Availability GroupsVersion 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 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.
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.)
• 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
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
Flush Logs in an AOAG EnvironmentAny 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.
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
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
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)
Creating AlwaysOn Availability GroupsStep 2: Enable AlwaysOn on each SQL Node
Enable AlwaysOn High Availability in SQL Server Configuration Manager
Repeat on Each NodeRestart SQL Services
Creating AlwaysOn Availability GroupsStep 3: Create the Availability Group
Ideally use the New Availability Group Wizard, it automates the process
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)
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
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
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
Working with SQL Server AlwaysOn Availability Groups for SharePoint On-Premises Farms
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 SummarySQL 2014/2016 AlwaysOn Availability Groups for SharePoint On-Premises
Thank you to our sponsors!
Questions?
Michael Noel
Twitter: @MichaelTNoelwww.cco.com
Slides: slideshare.net/michaeltnoel
Travel blog: sharingtheglobe.com