Architecting

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

1
 Derik Hammer
@sqlhammer
derik@sqlhammer.com
www.sqlhammer.com
 Database Administrator (Traditional/Operational/Production)
 Spent a year pretending to be a .NET developer then back to being a DBA
 Specialize in High-Availability, Disaster Recovery, and Maintenance Automation
 Rebuilt the Hampton Roads SQL Server User Group in Virginia Beach, VA before moving.
 Chapter leader of FairfieldPASS in Stamford, CT.

 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)
2
Goals
 Skill level: 200-300, assuming some familiarity
 Not a “how to”, but there are demos
Architecture

Not a SQL
 Stand-alone instances
 Stand-alones with multiple subnets
Server 2016
 AG with Failover Cluster Instances Preview Talk
 Hybrid approach (DR on the cheap)
 AG Specific features, i.e.
 Back-up off-loading
 Read-only routing
3
Materials
Slide deck and demo material available at:

This deck
http://www.sqlhammer.com/presentation-architecting-availability-
groups/

All presentations
http://www.sqlhammer.com/community/

This material has already been posted.

When I update the material, the most recent updates will be available.

This slide will be shown again at the end of the session.

4
5
Benefits of Availability Groups
 When should you use them?
 Automatic failover between local replicas.
 BasicHA (DB Mirroring) and FCIs have the same
capability.
 Manual failover between DR sites.
 Replication,log shipping, and Basic HA (DB Mirroring)
have the same capability.
 Group databases together and failover separately from
other groups.
 Off-load backups
 Off-load read loads.
6
Stand-alone instances

Server Server

Availability Availability
Replica A Replica B

Local Disk(s) Local Disk(s)

7
Stand-alone instances (cont.)

 Database level automatic

Server Server fail-over available with
synchronous commit.

Availability Availability
 Data duplication - a complete
Replica A Replica B set of drives and data per
replica.
 Must synchronize server
objects between nodes
manually.

Local Disk(s) Local Disk(s)

The beauty of this architecture is everything that it is not.

8
9
Stand-alone instances – multi-subnet

Server Server

Availability Subnet 2
Availability
Replica C Replica D

Local Disk(s) Local Disk(s)

Server Server
Subnet 1
Availability Availability
Replica A Replica B

Local Disk(s) Local Disk(s)

10
Stand-alone instances – multi-subnet
(cont.)
• Nodes synchronize from the primary, remote nodes don’t speak to
each other.

• Even more data duplication.

• One of the few reasons that I might consider favoring a hybrid
with FCIs.

• Availability Group Listener handles multiple IPs across multiple

subnets.

• Asynchronous Commit recommended for remote site, which only

supports manual failover.

11
12
AG with Failover Cluster Instances

Server Server
Subnet
1
Shared Disks
Availability
Replica B

Server Server

Availability
Subnet
Replica A
2

Shared Disks

13
AG with Failover Cluster Instances
(cont.)
 No need to synchronize server objects within subnet.
 Still need to across the subnets.
 Instance level failovers within subnets.
 Shared storage can’t cross subnets.
 Shared storage dependency.
 Can’t ever have one AG replica reside on the same node as another.
 Forces you to have more nodes to your cluster.
 Configurations where all nodes are active are no longer as possible.
 Can’t group DBs for failover, entire instance moves.

14
15
Hybrid Architecture AKA DR on the cheap

Subnet
Subnet 2
1

Shared Disks Server

Availability
Server Server Replica B

Availability
Replica A

Local Disks

16
17
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
18
Quorum Demo

Why you need to use Windows Server

2012 R2 and above

 Dynamic Quorum

 Dynamic Witness

 Tie breaker

19
Why use the Listener?

 Read-only routing.
 It is capable of faster failovers.
 Your applications do not have to wait for DNS time to live to
expire.
 One virtual network name (VNN), regardless of where the Availability
Group (AG) lives.
 Configuration files between DR sites can be identical.

 Different VNN for each AG on the cluster.

 Allows for groups of databases to failover to different servers.
 No instance names to worry about.
20
Limitations of the listener
bells & whistles
 ApplicationIntent and MultiSubnetFailover requires .NET 4.0.
 Or, 3.5 SP1 with hotfix KB2654347.
 https://support.microsoft.com/en-us/kb/2654347

 Or, JDBC 4.0

 Not available for OLEDB or ODBC connections (expect in SQL
Native Client 2012+ some restrictions apply).
 Connections must specify a database in the Availability Group
in order to perform read-only routing.
 Changing database context after connection has been
established won’t cut it.

21
Listener Demos
 SQL Server Management Studio
 Persist parameters – Supposedly fixed in vNext as per MS Connect.
http://bit.ly/1wKPucP
 Not fixed for SQL Server 2016 RC0
 Reference the workarounds -
http://www.sqlhammer.com/store-optional-connection-
parameters-in-sql-server-management-studio/
 SQLCMD.exe
 SQLPS module’s Invoke-SqlCmd (Not a demo, hard to show the non-
existence of something)
 Add MultiSubnetFailover and ApplicationIntent options – Vote up on
MS Connect! http://bit.ly/1BCbB82

22
23
Read-only routing

 Manually configured and optional.

 Must connect using an Availability Group database
context.
 Common stumbling point, thus the 2-slide
emphasis.
 No SSMS wizard for configuration.
 Incurs a round-robin connection performance hit.

24
 Read-only routing connection flow

Step 1: Client connects using

ApplicationIntent=ReadOnly

Primary Replica
Step 2: Primary replica replies (Includes Listener)
with IP for redirection
Client

Step 3: Connection is made with

read-only instance
Secondary Replica
(Read-Only)
25
Read-only Routing Demos

 Configure - T-SQL
 (Non-demo reference) AlwaysOn Tools -
Denny Cherry and Associates -
http://dcac.co/applications/hosted-by-
you/alwayson-tools

 Verify - Dynamic Management Views

26
Back-up Off-loading

 Transaction log backups

 COPY_ONLY full backups
 Differentials cannot be taken
 Various preferred replica configurations available
 sys.fn_hadr_backup_is_preferred_replica

27
Monitoring Demo

Availability Group Dashboard

28
References of interest
 Syncing server objects between sites
 http://www.sqlhammer.com/synchronizing-server-objects-for-availability-groups/
 PowerShell driven desired state Availability Group failover test
 http://www.sqlhammer.com/failing-over-alwayson-availability-groups/
 SSMS AG Listener connection work around
 http://www.sqlhammer.com/store-optional-connection-parameters-in-sql-server-
management-studio/
 Lazy log truncation and filestream
 http://www.sqlhammer.com/filestream-garbage-collection-with-alwayson-
availability-groups/
 Step-by-step work through of the AG + FCI architecture
 http://www.sqlhammer.com/how-to-configure-sql-server-2012-alwayson-part-1-of-7/

29
Materials
Slide deck and demo material available at:

This deck
http://www.sqlhammer.com/presentation-architecting-
availability-groups/

All presentations
http://www.sqlhammer.com/community/
My Contact Information:
This material has already been posted.
When I update the material, the most recent updates will be available. @SQLHammer
30 derik@sqlhammer.com
www.sqlhammer.com