AlwaysOn: Availability Groups

dandyw@microsoft.com ILIKESQL.COM

@ilikesqlDandy Weyn

MODIFY THIS SLIDE FOR ACTUAL PRESENTER, DELETE THIS BAR AFTER MODIFICATION

SQL SERVER DELIVERS REQUIRED 9SMaximize uptime for mission critical applications

GREATER HARDWARE UTILIZATION

AlwaysOn High AvailabilityWindows Server Core Support Online Operations Enhancements

Active SecondariesScale Read-Only Applications Offload BackupsFast Application Failover

Integrated Configuration WizardWindows PowerShell Support AlwaysOn DashboardMicrosoft System Center Monitoring

IMPROVED PRODUCTIVITY

GREATER UPTIME

GREATER UPTIME WITH HIGH AVAILABILITYKey technologies to deliver required 9s

Availability Groups provide database level

protection

Multiple Secondaries

Failover Cluster Instances provide

instance level protection

Reduce OS patching by as much as 50-

60% with new support for Windows Server

Core1

Reduce planned downtime by

reducing OS patching

Maintain uptime during

maintenance operations using enhanced online

operations

Reindexing of large object data types

Adding non-null columns

1The percentage reduction in patching varies & can be less based on the server roles that are enabled & the type of patches that are applied.

SQL SERVER 2012 HA & DR SOLUTIONS

1Multi-site Failover Cluster Instance (FCI) for HA & DR

• Shared Storage solution• Instance Level HA • Instance Level DR• Doesn’t require database to be in FULL

recovery model

2 Availability Group for HA & DR

• Non-Shared Storage solution• (Group of) Database Level HA• (Group of) Database Level DR• DR replica can be Active Secondary• Requires database to be in FULL recovery

model

3Failover Cluster Instance for local HA & Availability Group for DR

• Combined Shared Storage and Non-Shared Storage

• Instance Level HA • (Group of) Database Level DR• DR replica can be Active Secondary• Requires database to be in FULL recovery

model

• Active Secondary––

–

• Monitoring and Troubleshooting enhanced

• Automation using PowerShell

ALWAYSON AVAILABILITY GROUPSAlwaysOn Availability Groups is a new feature that enhances

and combines database mirroring and log shipping capabilities

• Multi-database failover• Multiple secondaries

––

–

• Synchronous and asynchronous data movement

• Built in compression and encryption

• Auto-page repair• Automatic and manual

failover (new design)• Flexible failover policy

• Application failover using virtual name

• Configuration Wizard• Dashboard• System Center

Integration• Rich diagnostic

infrastructure• File-stream replication• Replication publisher

failover

Flexible Integrated Efficient

ALWAYSON AVAILABILITY GROUP LISTENER

TechAG1

2 DB

2 DB

Primary SecondaryTechListener

1

Parameter Sample: -server TechListener1;-catalog HRDB

Application retry during failover

Primary SecondarySecondary

2 DB

ServerA ServerB ServerC

Availability Groups Listener allow applications to failover seamlessly to any secondary; reconnecting through Virtual Network Name

Connect to new primary once failover is completeand the listener is online

ALWAYSON AVAILABILITY GROUP ARCHITECTURE

Inter-node health detection Failover coordination Primary health detectionDistributed data store for settings and stateDistributed change notifications

SQL Server AlwaysOn Failover Cluster InstancesSQL Server AlwaysOn Availability GroupMicrosoft Hyper-VMicrosoft ExchangeBuilt-in WSFC workloads (e.g. file share, NLB, etc.) and third party workloads

Availability Group uses WSFC for

DatabaseActive Log Synchronization

DatabaseActive Log Synchronization

Windows Server Failover Clustering(WSFC)

WSFC is a Common Microsoft Availability Platform

NEW TOPOLOGY BENEFITSBetter SLAs Easier Deployment &

ManagementMultiple no data loss secondaries

Better data loss protection for DR secondaries through continuous

replicationFaster failover to DR secondaries

through virtual name failover

Unified solutionSimple deploymentUnified dashboardRich diagnostics

Centralized management of client connection topologyMulti-DB failover

New Management Dashboard

ALWAYSON ACTIVE SECONDARIES

IT EFFICIENCY AND COST-EFFECTIVENESS ARE CRITICAL FOR BUSINESSESIdle hardware is no longer an option.

ACTIVE SECONDARY USESRead-only workloadsOffloading Backups

AlwaysOn Active Secondary enables efficient utilization of high availability hardware resources to improve overall IT efficiency

SQLservr.exe SQLservr.exe

ACTIVE SECONDARY – READABLE SECONDARY

Readable secondary allow offloading read queries to secondaryLow data latency

After failover, the read applications can be automatically redirected to the new Secondary (require explicit connection request)Not a replacement for replication scenarios

Primary SecondaryPrimarySecondary

Database Log Synchronization

DB2DB1

InstanceB

Reports

DB2DB1

InstanceA

Reports

CRASH

SecondaryPrimary

Log Cache

Log Cache

READABLE SECONDARY – DATA LATENCY

Secondary read is always behind primary during transaction activity

DB1

DB1 Log

DB1Log

Capture Log Receive

DB1 Data

Network

Redo Thread

Redo Pages

DB1 Log DB1 Data

Log HardenedLog Flush

Commit

Acknowledge Commit

Log Pool

Log Capture

READ WORKLOAD IMPACTCONCURRENCY AND BLOCKINGREDO can get blocked by reporting workloadREDO thread and read workload can deadlockSOLUTIONInternally map read workload to non blocking isolation levels (no application changes required)• Read Uncommitted Snapshot Isolation• Read Committed Snapshot Isolation• Repeatable Read Snapshot Isolation• Serializable Snapshot Isolation• Ignore all locking hints

Never choose REDO as deadlock victim

PRIMARY SECONDARIES

ReadRead/Write

RESULTBlocking and deadlock between Reporting workload (i.e. Query) and REDO thread is eliminatedNo issues with DML (INSERT/DELETE/UPDATE) as it is not allowedWill incur additional cost of row versioning.

CLIENT CONNECTIVITYREAD / WRITE WORKLOAD• Connecting using AG Listener• Connection using FAILOVER_PARTNER (if

connection string of existing applications can’t be changed)

READ ONLY WORKLOAD• Connection using VNN and

ApplicationIntent=ReadOnly• Connection to the secondary instance

directly• ReadOnly Routing

MULTI SUBNET FAILOVER SCENARIO:• New client libraries =>

MultiSubnetFailover=True• Old client libraries configure appropriate

client connection timeout

CLIENT

AG Listener

PRIMARY SECONDARIES

BACKUP CAPABILITIES

Backups from any replica

Synchronous or asynchronous secondaries

Primary backups still work

Adds capacity to primary server by off-loading backups to a

replica

Log backups done on all replicas

form a single log chain

Recovery Advisor makes restores simple

RECOVERY ADVISOR

CONSIDERATIONS FOR AVAILABILITY GROUPS

All SQL servers (including the secondary in the DR site) in the same Windows domain• One Windows Server Failover Cluster spreads

over the primary and DR sitesAll the databases must be in FULL recovery modelThe unit of failover (for local HA, as well as DR) is at the AG level, i.e., group of databases – not the instance• Consider using Contained Database for

containing logins for failover• For jobs and other objects outside the

database, simple customization neededNo delayed apply on the secondary like log shippingRemoving log shipping means the regular log backup job is removed• Need to re-establish periodic log backup

(essential for truncating the log)

New Tools for Monitoring &

AlertingAlwaysOn Dashboard

System Center Operations Manager

Failover Clustering Improvements

DEMO

ALWAYSON MULTI-SITE FAILOVER CLUSTER INSTANCEProvide High Availability at the Instance Level• Unit of failover = SQL server instance• Maintain same virtual network name after failover. Clients re-connect to same

name• Instance restart requires database to go through recovery

Provide Disaster Recovery at the Instance Level• Provide Disaster Recovery protection from site failure: be it network, power,

infrastructure or other site disasters.• Require storage based replication technology and networking considerations• Multi-subnet support:

HA & DR Solution

Version Native Support Implementation

SQL Server 2008 R2 NO • Create stretch Virtual-LAN (VLAN) to act as a

single subnet

SQL Server 2012 YES• IP address OR dependency support within

SQL Server setup• SQL Engine skips binding to IP’s not online on

start-up

MULTI-SUBNET CLUSTERINGCorpnet

Network Name: SqlClust

subnet 1 subnet 2

IP1: 10.168.0.10 IP2: 192.168.0.10

SAN ReplicationLocal Site Remote Site

ORNode1Node2

Node3Node4

TEMPDB ON LOCAL DISKWHY WE ENABLE THIS?• tempdb access occupies large %

of SAN I/O• Fast local HDD/SSD becomes

standard Server configuration

BENEFITS• Better overall performance• Cost saving

IMPORTANT NOTE! • Ensure that tempdb local paths

are available to SQL Service on all the nodes

LOCAL TEMP DB

(Fast disk, SSD)

Shared Disk (SAN)

LOCAL TEMP DB

(Fast disk, SSD)

SECONDARIESPRIMARY

ALWAYSON FAILOVER CLUSTER INSTANCEFailover Condition PolicyFlexible Failover Policy provides administrators control over the conditions when an automatic failover should be initiated.

Resource DLL

SQL Server

Select @@servername

SQL Server 2008 R2 SQL Server 2012

Resource DLL

SQL Server

sp_server_diagnostics

Diagnostics

Configurable options eliminate false failoverImproved logging for better diagnostics

SQL Server Hands-on-Labs

SQLSERVERLAUNCH.COM