1. Architecting Availability Groups
An analysis of Microsoft SQL Server Always-On Availability Group architectures

2. Derik Hammer @sqlhammer derik@sqlhammer.com www.sqlhammer.com
Database Administrator (Traditional/Operational/Production)
Specialize in High-Availability, Disaster Recovery, and Maintenance Automation
User group leader of FairfieldPASS in Stamford, CT.
Friend of Redgate
SentryOne Product Advisory Counsel
BS in Computer Information Systems with a focus in Database Management
Querying Microsoft SQL Server 2012 Databases (70-461)
Administering Microsoft SQL Server 2012 Databases (70-462)

3. What will I give you? Architecture AG with Failover Cluster Instances
Stand-alone instances
Stand-alones with multiple subnets
AG with Failover Cluster Instances
Distributed AG
AG Specific features, i.e.
Read-only routing
Multi-Subnet Failovers
Focus on concepts, design, and lessons learned
Not a “how to”

4. Questions Interaction Feedback Session evaluations
What can you give me?
Questions
Interaction
I just might ask you to help me present
Feedback
Session evaluations

5. Stand-alone instances
Simplest architecture which equates to being the most stable, easiest to maintain, and has the least limitations.
Explain the physical structure ONLY on this slide.
-- Local storage, not required to be shared like FCIs.
-- Can be physically attached or attached with ISCSI.
-- -- Life event: Liberty Tax VB servers rebooted. SAN storage didn’t come back up. Required Windows reboot, extending outage.

6. Stand-alone instances – multi-subnet
Explain the cross-subnet information here and introduce the listener.
Mention how the listener has multiple IPs but don’t get too deep yet.
Mention the AND / OR dependency for cluster resources which was available in Windows Server 2008
but multi-subnet was not supported by SQL Server until 2012.

7. AG with Failover Cluster Instances
Subnet 1
Discuss physical architecture ONLY.
** Remember animated pieces **
Local failover arrows fly in.
Subnet labels fall in.
Subnet 2

8. Distributed Availability Group

9. Quorum Voting mechanism Prevents “split-brain”
Node majority is typical
Potential voters include
Servers (physical or virtual)
File shares
Remote shared disks
Weight your votes for a complete drop of your connection to your disaster recovery site
Connection drops between sites happen.
That F-18 crash is from Virginia Beach, VA in Jan, 2014.
6 miles from my primary production data center.

10. Server A Server B Initial setup Total votes 3 Online votes
File Share Witness
Odd number of votes to prevent split brain scenarios.

11. One server down Intermediate state
Total votes 3
Online votes 2
Server A
Server B
File Share Witness
Cluster is still online because we maintain node majority with 2 votes out of 3.

12. Server A Server B Dynamic witness Total votes 1 Online votes
File Share Witness
Total votes recalculates after a few seconds to become a total of 2 with 2 online.
Dynamic quorum engages and revokes a vote from the witness to make an odd number.
Total recalculates to 1 with 1 online.

13. Reset No witness Intermediate state
Total votes 2
Online votes
Server A
Server B
You create a 2 node cluster without a witness.

14. Server A Server B Dynamic quorum Total votes 1 Online votes
Dynamic quorum quickly removes a vote from server A to not be an even number.
Total is recalculated to 1 with 1 online.

15. LowerQuorumPriorityNodeId
Tie breaker
Total votes 1
Online votes
Server A
Server B
Server A was selected for dynamic quorum to revoke its vote because server A was designated the tie breaker. It was designated by the LowerQuorumPriorityNodeId equaling 2.
By default it equals 0 which indicates that the server with the lowest node id is the lower, meaning server B would be the loser by default. 7 2
LowerQuorumPriorityNodeId

16. What is the listener for?
Read-only routing.
Faster failovers.
** 55 min
Mention that the listener is optional. You don’t have to use it nor do you have to have one.

17. Read-only routing Manually configured.
Must connect using an Availability Group database context.

18. Read-only routing connection flow
Step 1: Client connects using
ApplicationIntent=ReadOnly
Step 2: Primary replica replies
with IP for redirection
If you have a servers in the routing list which take a long time to connect this might cause connection timeouts.
I recommend not allowing your routing configurations to cross data centers.
Step 3: Connection is made with
read-only instance

19. References of interest
Syncing server objects between sites
PowerShell driven desired state Availability Group failover test
SSMS AG Listener connection work around
management-studio/
Lazy log truncation and filestream
availability-groups/
Step-by-step work through of the AG + FCI architecture

20. Materials
Slide deck and demo material available at:
This deck
availability-groups/
All presentations
This material has already been posted.
When I update the material, the most recent updates will be available.
My Contact Information:
@SQLHammer