SQL Server 2016

Always On
Concepts Windows Server Failover Cluster
Asynchronous Commit

Availability Group Availability Databases

Automatic Failover

Hybrid Cloud
Virtual Computer Object
Windows Server 2016
Listener
Secondary Backups
Availability Replicas
Readable Secondaries
SQL Server High Availability and Disaster Recovery

AlwaysOn Failover Cluster Instances

AlwaysOn Availability Groups
Transaction Log Shipping
AlwaysOn Failover Cluster
Instances (FCI)
SQL Server Failover Cluster Configuration
Built on top of Windows Failover Clustering

Single set of database files

Multiple instances can be configured in a cluster

Only a Single instance can host the databases at once

Failover Cluster Instances (Single Instance)
Cluster Virtual Name\InstanceName

SQL
Instance

Node A Node B

Shared Storage (SAN or SMB 3.0 Share)

Windows Failover Cluster

Multi-instance Failover
Cluster

SQL SQL SQL

Instance 1 Instance 2 Instance 3

Node A Node B Node C Node D

Shared Storage (SAN or SMB 3.0 File Share)

Windows Server Failover Cluster

Failover Cluster Instance Requirements
Each Instance is installed and managed separately

Each instance is installed on each node in a cluster

Requires a separate network name and IP address and AD

Computer Object
Requires at least one clustered disk
Instances Redefined
Instances are
Multiple
installed on
instances are
multiple
configured
machines

Separate
Each single
clustered
clustered
instances
instance has
have
the same
different
name
names
 Cluster Resource
Service name is
Dependencies SQL Server
Service
dependent on Instance
Name and Disk

InstanceName Cluster Disk

1

Instance Name is
dependent on IP
10.1.0.6
Address
 Recent SQL Failover Clustering Enhancements

Multi-Subnet Network Windows Core TempDB on

Failover Storage Mode Installs local disk
Support Support • Limit patch • Allows for use of
• Easier support for • Simplifies use of footprint PCI-E cards for
Geo-Clusters commodity TempDB
storage
Multi-Subnet Failover
Two different IP Addresses configured for SQL

Only one comes online at a time using OR

statements within Windows Failover Clustering

Uses network subnet configuration to determine IP

to bring online
Failover Clustering in Azure
Fully supported in Azure as of
April 1st, 2015

Requires third party storage

replication software

Single instance per cluster

Single instance per “Cloud

Service”

Requires using Internal Load

Balancer
Always On Availability Groups
AlwaysOn Availability Groups
Instance Synchronous Instance Instance
1 Transfer
2 3
Asynchronous Transfer

Node A Node B Node C

Availability Group

Washington Chicago
Listener Name (AD VCO)

Windows Cluster
Availability Group Listener
Virtual IP Address that Directs connections to
Virtual Computer Object
automates connection to primary replica
in Active Directory
Availability Group automatically

Full multi-subnet support

• Use of
Work in Azure or Hybrid multisubnetfailover=true
models connection parameter
supported
Are AG’s Just Mirroring?
Transaction Log Stream

Uses encrypted endpoint

Secondary Replicas can be readable

Automatic Failover for Synchronous

Replicas
SQL Server • Synchronous replication should
supports up only be used when distance
between nodes is less than 100
to 8 km/60 miles
secondary • Synchronous replication is required
replicas for automatic failover
Availability Group Support With Other Features
FILESTREAM Policy Based Management
FileTable
Maintenance Plans
Columnstore Indexes (2016)
Auditing
Full Text Indexes
User Defined Server Roles
Replication
• Publication Transparent Data Encryption
• Subscription

Contained Databases SQL Service Broker

Hybrid Availability Group

SQL Instance
1 SQL
Instance 2

On-premises

Windows Server Failover Cluster (Same AD Domain)

20
20
Hybrid Secondaries
Deploy one or more
secondary replicas for on- • Replicas continuously synchronize
premise SQL Server

At best region: West US, East • Political considerations

US, East Asia, Southeast Asia,
North Europe, West Europe • Latency

Low TCO • VM and storage

Example of Availability Group spanning
On-premises and Azure

Node 1 Node 2
Node 3
ILB Listener

VPN Azure
Appliance Gateway

On-Premises
The Benefits of Hybrid Disaster Recovery

An event can cause

on-premises SQL A disaster recovery site
Server to become is expensive
unavailable

Temporarily (e.g. Site rent + Permanently (e.g.

Hardware Ops
gateway failure) maintenance flooding)
Why?
Provide • Integrated HA/DR
• Offload Read workloads to Azure

additional
• Connect reporting/BI apps
• Migrate apps and run against local secondaries

benefits:
• Offload Backups to Azure
• A solution for policy compliance

Remember it • Same Windows Domain

requires:
• Needs an Active Directory Domain Controller
SQL Server 2016
What’s New in Availability
Groups
SQL 2016 Availability Group New Features
Database Level Failover Trigger
DTC Support
Better Automatic Failover Support
Log Transport Performance
Load Balanced Readable Secondaries
gMSA Support
Standard Edition Support
Encryption Support
Database-Level Failover Trigger
AG Health (2012, 2014) • Database can go corrupt
monitored at instance
level and AG will not failover

Optional setting in
2016 to allow a • Offline database will
database failure to
trigger AG failover
change AG health
Distributed Transaction Coordinator (DTC) Support
Distributed Transactions involving an AG database are not
supported in SQL Server 2014
• Many enterprise apps require cross database transactions

Limited DTC support in 2016

• Requires OS patch to work

• Does not support intra-AG DTC
Log Transport Performance and Automatic Failover Targets

2012, 2014 supported only one automatic failover target

2016 supports any synchronous secondary (up to three total)

Log Transport Performance

• Hardware enchancements (notably SSDs) have driven throughput higher

• Entire pipeline rewritten, lower CPU, better performance
• Performance aim is to match that of standalone server
Log Transport Workflow
Log Transport Performance

Target Max
Parallel Transaction
Throughput is 400-500
Log Apply
MB/s
Load Balancing in Readable Secondaries
In 2014, reads went to first Client Client Client Client Client

available secondary 1 2 3 4 5

Availability Group Listener

Now you can configure

routing to use round-robin
amongst secondaries AG1 AG2 AG3 AG4
Group Managed Service Accounts

Supported in
Introduced in Now in 2016
SQL 2014
Windows 2012 for AGs
(Standalone)
Group Managed Service Accounts
Distributed Availability Groups
Two Windows Server Failover
Clusters

Efficient for geographically

distributed sites

Primary and secondary AGs

must have have same database
configuration
Availability Group Seeding
Eliminates needs for manual
backup and sync process

Add
SEEDING_MODE=AUTOMATIC
keyword
Basic Availability Groups
Two Nodes Only

One Database per AG

No Readable Secondaries

No Backup on Secondaries

DB Snapshots Available

Effectively Database Mirroring—with enhancements

Support for Encrypted Databases

Requires
Password
and Master
Key

Support for TDE

Windows Server 2016
High Availability Enhancements
Windows Server 2016
Cloud Witness

Rolling OS Cluster Upgrades

Site-aware failover clusters

Workgroup and multi-domain clusters

Cloud Witness
 Azure Blob
 Site 1 Storage  Site 2
provides
disk
witness
 Node 1  Node 2
Workgroup and Multi-Domain Clusters
Windows Cluster

Node1.Contoso.com Node2.Fabrikam.com
Rolling Cluster OS Upgrades
Only Microsoft delivers
On-premises & cloud
Consistent experience is everything

Common tools for

SQL Server SQL Server in Azure VM Azure SQL Database
development and
management
Analytics Platform System Azure SQL Data Warehouse Common T-SQL
surface area
Common tools Simple cloud migration
Dev ops tools Management tools Identity Virtualization

Single-vendor support