Disaster Recovery and High

Availability solutions with

SQL Server Azure

Montreal SQL Saturday

Prepared by Michelle Gutzait

WHOAMI?

gutzait@Pythian.com

SQL Server Consultant@ www.pythian.com

24/7 Remote DBA services

© 2013 Pythian2

The environment

• OLTP/ DW?

• Availability? 24x7?

• Data loss and SLA?

• Local/hosted?

• SQL Server version and edition?

• Storage?

• Number of databases?

• Sizes of databases?

• Volume of transactions?

• Volume of reports?

• Backup strategy?

• Etc…

Problems?• Performance issues

• Locks/blocks/deadlocks

• Application timeouts

• Backups failing

• Data updates VS reports

• Fragmented indexes

• Previous Database corruption

• Restore took too long

• Application bugs causing logical

corruption

• Long downtime on maintenance

What are YOUR problems?

HA and DR solutions

Primary and secondary environments can be:

• Only on-premises

• Only in Azure

• Hybrid (both on-premises and in Azure)

© 2013 Pythian6

Countless solutions!!!

Before Azure…

© 2013 Pythian8

Backups• Full backup

• Differential backup

• T-Log backup

• Filegroup backup

• Filegroup Differential

Backups strategy for DR

• How long is the restore?

• Where are the backup files?

• What’s the affordable downtime?

• How much data loss is acceptable?

Log Shipping

• Replica of the entire database

• Synchronized to X minutes ago

• Backup and restore the t-logs

• Secondary can be:

– Read-only

– In recovery mode

Log Shipping - Pros

• Verification of production backups

• Lag to protect from accidental changes

(ex: protection during monthly/weekly

releases)

• Any change in DB is replicated

automatically, including DDL

• Multiple secondaries are allowed

• Read-Only replica

– Good for reporting

– Data can be read at standby server when DB is not

restoring

– CHECKDB, Fragmentation checks on secondary

Log Shipping - Cons• X minutes data loss

• No automatic failover (can be automated)

• No easy failback (Log Shipping needs to be

recreated)

• DB Corruption may be replicated

• Database level replication, not instance

• T-log backup files can be large if there is a high

volume of transactions

• Database needs to be in FULL recovery model

• Same SQL Server version for read-only replica

• Users will be disconnected on DB restore– Automatically

– Not automatically

• No particular indexes can be created for the

reports

Database Mirroring

• Replica of the entire database

• Synchronization

– Synchronized (High Safety)

• With or without a witness

– A-synchronized (High Performance)

Database Mirroring - Pros

• Real-time or close-to-real-time replica

• Any change in DB is replicated

automatically, including DDL

• Can implement Database Snapshots on

replica for reporting

• Corruption not being replicated

– SQL 2008+ page corresponding to a corruption is

retrieved from the replica/mirror and repaired,

transparently

• Easy failover and failback

• Automatic failover with a witness

– Faster failover than Clustering

• Reference to secondary instance in

connection strings

Database Mirroring - Cons

• Secondary cannot be used for reporting

– Can use Database Snapshot

• Sensitive to network bandwidth

– And volume of transactions

• A-synchronous mode - only in ENT Edition

• Witness - only in ENT Edition

• Deprecated in future releases

• Replication on the database level, not

instance

• Only one mirror allowed per database

• A bit more complicated if instances not in the

same network or Domain

Database Snapshot

• Static read-only copy of the

database

• Snapshot file grows when pages

modified

• On same instance as the original

database

Database Snapshot - Pros

• Great for reporting

– Non real-time data

• Great for DR

– Non real-time data

• Can be created on a mirrored replica

• Corruption will be kept if at page-level

• Created in less than a second

• Read –only operations such as DBCC or

index fragmentation

• Can be backed up

Database Snapshot - Cons

• Non real-time data

• Requires maintenance

– Multiple snapshots

– Add and remove

• Databases cannot be dropped if there is a

snapshot

• Snapshot cannot be dropped if there are

users

• No particular indexes can be created for

the reports

Replication

• Object-level replication

– Row level

– Column level

• Three types

– Snapshot

– Merge

– Transactional

• With updatable subscribers

• Peer-to-peer

• Transaction being replicated

Replication - Pros

• Partial replication

– Saving space and time

– Security

• Possibly different schema and different

indexes on secondary

• Great for reporting, users not disconnected

• Corruption not transferred

• Can configure a lag, protecting from

accidental data changes

• Secondary database can be backed up

Replication - Cons

• Management and troubleshooting

complexity

• All replicated tables require a Primary Key

• Database level replication, not instance

• More physical hardware required with

heavy IO throughput

• Some latency, possible data loss

Cluster

• Instance-level HA/DR

• High Availability with local cluster

• Plus Disaster Recovery with Geo-

Cluster

• 2 or N+1 nodes, M instances

• One instance can failover to different

nodes

• SQL Server has one virtual name

Cluster - Pros

• Failover transparent to applications

• Automatic failover on hardware or

OS failures

• Fast failover (only service restart)

• Easy upgrades and patches

• Can add nodes seamlessly

• Manual failover (ex: performance

reasons)

Cluster - Cons

• No protection from disk failure

• Only 2-node cluster for Standard

Edition

• More maintenance than a stand-

alone

• More expensive than a stand-alone

• There is no replica of the database

for reporting

Always

OnAvailability

Groups

• A mix of Failover clustering and

Database Mirroring

• Does not require shared storage

• Instances are not clustered

resources

• Database level replication

• Group of databases failing over

together

• Read-only or non-readable replicas

• Automatic failover

• Different sync modes

• Different failover rules

• Built-in Load balancing

Other solutions – not SQL Server,

not Azure

• VM replication

• SAN or storage replication

• 3-rd party tools

• Etc….

Architecture design – so farBe creative….

Node A Node B

Instance A

Node N

Instance BPassive

Instance C

Cluster

WOW!! More options with

Azure

© 2013 Pythian33

Other solutions – for Azure VMs• Service healing for cloud services and

Failure recovery detection for the Virtual

Machines– keep VM available even when there are problems

– VM proactively moved to new nodes

– VM may restart

– IP address of the VM does not change

• Azure Site Recovery– Hyper-V replication

• Geo Redundant Storage (GRS) for

Windows Azure– Locally or zone redundant

– Three copies of your data– http://blogs.msdn.com/b/windowsazurestorage/archive/2011/09/15/in

troducing-geo-replication-for-windows-azure-storage.aspx

Cloud (Azure) only HA/DR solutions - examples

• Built-in Always On Availability Groups

© 2013 Pythian35

Within same region

Different region

Cloud (Azure) only HA/DR solutions - examples

• Database mirroring

© 2013 Pythian36

Same region

With Domain Controller

Same region

Using certificates

Different region

Hybrid HA/DR solutions - examples

• Always On

Availability Groups

• Database

mirroring

• Log Shipping

© 2013 Pythian37

Quick demo…

manage.windowsazure.com

Easy to choose from a menu

© 2013 Pythian39

Connect an on-premises network to

a Microsoft Azure virtual network

© 2013 Pythian40

https://technet.microsoft.com/en-us/library/dn786406%28v=office.15%29.aspx

Or…. Point-to-Site VPN

© 2013 Pythian41

http://blogs.technet.com/b/francesco_diaz/archive/2013/05/14/implementare-uno-

scenario-ibrido-con-sql-server-e-windows-azure-point-to-site-vpn.aspx

Follow the steps

• On-premises Define and create an on-premises

network that requires a route to the Azure virtual network

and a VPN gateway device.

• Microsoft Azure Create an Azure virtual network with a

site-to-site VPN connection via the Azure Management

Portal.

• On premises Configure your on-premises hardware or

software VPN gateway to terminate the VPN tunnel,

which uses Internet Protocol security (IPsec).

© 2013 Pythian42

Thank you!

gutzait@Pythian.com