1.
James Serra
Microsoft
Data Platform Solution Architect
HA/DR options with SQL Server
in Azure and hybrid

2.
About Me
 Microsoft, Big Data Evangelist
 In IT for 30 years, worked on many BI and DW projects
 Worked as desktop/web/database developer, DBA, BI and DW architect and developer, MDM
architect, PDW/APS developer
 Been perm employee, contractor, consultant, business owner
 Presenter at PASS Business Analytics Conference, PASS Summit, Enterprise Data World conference
 Certifications: MCSE: Data Platform, Business Intelligence; MS: Architecting Microsoft Azure
Solutions, Design and Implement Big Data Analytics Solutions, Design and Implement Cloud Data
Platform Solutions
 Blog at JamesSerra.com
 Former SQL Server MVP
 Author of book “Reporting with Microsoft SQL Server 2012”

3.
Agenda
 VM storage
 Always On AG
 Always On FCI
 Basic Availability Groups
 Database Mirroring
 Log Shipping
 Backup to Azure
 SQL Server data files in Azure
 Azure Site Recovery
 Azure VM Availability Set
 Azure SQL Data Sync

4.
Virtual Machine storage architecture
C:
OS disk (127 GB)
Usually 115 GB free
E:, F:, etc.
Data disks (1 TB)
Attach SSD/HDD up to 1TB. These
are .vhd files
D:
Temporary disk
(Contents can be lost)
SSD/HDD and size depends on VM
chosenDisk Cache

5.
Azure Default Blob Storage
 Azure Storage Page Blobs, 3 copies
 Storage high durability built-in (like have RAID)
 VHD disks, up to 1 TB per disk (64 TB total)

6.
Geo-storage replication
 3 copies locally, another 3 copies in different region
 Disable for SQL Server VM disk (consistent write
order across multiple disks is not guaranteed).
Instead use DR techniques in this deck
Defend against regional disasters
Geo replication

7.
HA/DR deployment architectures
Azure Only
Availability replicas
running across
multiple Azure
regions in Azure VMs
for disaster recovery.
Cross-region solution
protects against
complete site outage.
Replicas running in
same Azure Region
for HA.
Hybrid
Some availability
replicas running in
Azure VMs and other
replicas running on-
premises for cross-
site disaster recovery.
HA only, not DR
FCI on a two-node
WSFC running in
Azure VMs with
storage supported by
storage spaces direct.
Azure Only
Principal and mirror
and servers running
in different
datacenters for
disaster recovery.
Principal, Mirror, and
Witness run within
same Azure data
center, deployed
using a DC or server
certificates for HA.
Hybrid
One partner running
in an Azure VM and
the other running on-
premises for cross-
site disaster recovery
using server
certificates.
For DR only /
Hybrid only
One server running in
an Azure VM and the
other running on-
premises for cross-
site disaster recovery.
Log shipping
depends on Windows
file sharing, so a VPN
connection between
the Azure virtual
network and the on-
premises network is
required.
Requires AD
deployment on DR
site.
On-prem or Azure
production databases
backed up directly to
Azure blob storage
for disaster recovery.
SQL 2016: Backup to
Azure with file
snapshots
Simpler BCDR story
Site Recovery makes
it easy to handle
replication, failover
and recovery for your
on-premises
workloads and
applications (not
data!).
Flexible replication
You can replicate on-
premises servers,
Hyper-V virtual
machines, and
VMware virtual
machines.
Eliminate the need
for secondary
Native support for
SQL Server data files
stored as Azure blobs

8.
HA/DR Defined
• High Availability (HA) – Keeping your database up 100% of the time with no data loss
during common problems. Redundancy at system level, focus on failover, addresses
single predictable failure, focus is on technology
• Always On FCI
• Always On AG (in same Azure region)
• SQL Server data files in Azure
• Disaster Recovery (DR) – Protection if major disaster or unusual failure wipes out your
database. Use of alternate site, focus on re-establishing services, addresses multiple
failures, includes people and processes to execute recovery. Usually includes HA also
• Log Shipping
• Database Mirroring
• Always On AG (different Azure regions)
• Backup to Azure

9.
RPO/RTO
RTO – Recover Time Objective. How much time after a failure until we have to be up
and running again?
RPO – Recover Point Objective. How much data can we lose?
• HA – High Availability
• RTO: seconds to minutes
• RPO: Zero to seconds
• Automatic failover
• Well tested (maybe with each patch or release)
• DR – Disaster Recovery
• RTO: minutes to hours
• RPO: seconds to minutes
• Manual failover into prepared environment
• Tested from time to time
How long does it take to fail over:
• Backup-Restore: Hours
• Log Shipping: Minutes
• Always On FCI: Seconds to minutes
• Always On AG/Mirroring: Seconds

10.
Always On Availability Groups
Azure Only
Availability replicas
running across
multiple Azure
regions in Azure VMs
for disaster recovery.
Cross-region solution
protects against
complete site outage.
Replicas running in
same Azure Region
for HA.
Hybrid
Some availability
replicas running in
Azure VMs and other
replicas running on-
premises for cross-
site disaster recovery.
Availability replicas running across multiple datacenters in Azure
VMs for disaster recovery. This cross-region solution protects
against complete site outage.
Within a region, all replicas should be within the same cloud
service and the same VNet. Because each region will have a
separate VNet, these solutions require VNet to VNet connectivity.
For more information, see Configure a Site-to-Site VPN in the
Azure classic portal.
NOTE: US East should show a FSW.
All availability replicas running in Azure VMs for high
availability within the same region. You need to configure a
domain controller VM, because Windows Server Failover
Clustering (WSFC) requires an Active Directory domain.
For more information, see Configure Always On Availability
Groups in Azure (GUI).
With Windows Server 2016 replicas, you can use a Cloud
Witness instead of a File Share Witness (FSW). A WSFC
always requires a FSW to handle quorum (and Always On
Availability Groups require WSFC).

11.
Always On Availability Groups (Hybrid)
Azure Only
Availability replicas
running across
multiple Azure
regions in Azure VMs
for disaster recovery.
Cross-region solution
protects against
complete site outage.
Replicas running in
same Azure Region
for HA.
Hybrid
Some availability
replicas running in
Azure VMs and other
replicas running on-
premises for cross-
site disaster recovery.
Some availability replicas running in Azure VMs and other
replicas running on-premises for cross-site disaster recovery.
The production site can be either on-premises or in an Azure
datacenter.
Because all availability replicas must be in the same WSFC
cluster, the WSFC cluster must span both networks (a multi-
subnet WSFC cluster). This configuration requires a VPN
connection between Azure and the on-premises network.
For successful disaster recovery of your databases, you should
also install a replica domain controller at the disaster recovery
site.
It is possible to use the Add Replica Wizard in SSMS to add an
Azure replica to an existing Always On Availability Group. For
more information, see Tutorial: Extend your Always On
Availability Group to Azure.

12.
Distributed Always On Availability Groups
Azure Only
Availability replicas
running across
multiple Azure
regions in Azure VMs
for disaster recovery.
Cross-region solution
protects against
complete site outage.
Replicas running in
same Azure Region
for HA.
Hybrid
Some availability
replicas running in
Azure VMs and other
replicas running on-
premises for cross-
site disaster recovery.
Distributed Availability Groups differ from an availability group on a single Windows Server Failover Cluster in the following ways:
Pros
• Each WSFC maintains its own quorum mode and node voting configuration. This means that the health of the secondary WSFC does not
affect the primary WSFC
• The data is sent one time over the network to the secondary WSFC and then replicated within that cluster. In a single WSFC, the data is sent
individually to each replica. For a geographically dispersed secondary site, distributed availability groups are more efficient
• The operating system version used on the primary and secondary clusters can differ. In a single WSFC, all servers must be on the same
version of the OS. This has the potential to use Distributed Availability Groups with rolling updates/upgrades of the operating system
Cons
• The primary and secondary availability groups must have the same configuration of databases
• Automatic failover to the secondary availability group is not supported
• The secondary availability group is read-only

13.
Always On Availability Groups failover modes
• Primary role and secondary role of availability replicas are interchangeable
• A secondary replica will be the failover target
• Database level issues (i.e. database deletion, corrupted transaction log) do not cause an availability group to failover
• During the failover, the failover target takes over the primary role, recovers its databases, and brings them online as the new primary
databases. The former primary replica, when available, switches to the secondary role, and its databases become secondary databases.
Three forms of failover:
• Automatic failover: No data loss
• Planned manual failover: No data loss
• Forced manual failover: Also called forced failover. With possible data loss
*If you issue a forced failover command
on a synchronized secondary replica, the
secondary replica behaves the same as
for a manual failover

14.
Always On Failover Cluster Instances (FCI)
HA only, not DR
FCI on a two-node
WSFC running in
Azure VMs with
storage supported by
storage spaces direct.
You can use FCI to
host an availability
replica for an
availability group
Windows Server 2016 Storage Spaces Direct (S2D) provides virtual shared storage on top of the disks attached to the VMs hosting the
FCI replicas by replicating the disk contents.
We plan to support FCI natively on top of Premium Azure Files (physical SMB shared storage) this year.

15.
Always On FCI vs Always On AG

16.
Basic Availability Groups
Basic Availability Groups replaces the deprecated Database Mirroring feature, providing a similar level of features
and is used for SQL Server 2016 Standard Edition (normal Availability Groups requires Enterprise Edition).
Limitations:
• Limit of two replicas (primary and secondary)
• No read access on secondary replica
• No backups on secondary replica
• No support for replicas hosted on servers running a version of SQL Server prior to SQL Server 2016
Community Technology Preview 3 (CTP3)
• No support for adding or removing a replica to an existing basic availability group
• Support for one availability database
• Basic availability groups cannot be upgraded to advanced availability groups. The group must be dropped
and re-added to a group that contains servers running only SQL Server 2016 Enterprise Edition
• Basic availability groups are only supported for Standard Edition servers

17.
Database Mirroring
Azure Only
Principal and mirror
and servers running
in different
datacenters for
disaster recovery.
Principal, Mirror, and
Witness run within
same Azure data
center, deployed
using a DC or server
certificates for HA.
Hybrid
One partner running
in an Azure VM and
the other running
on-premises for
cross-site disaster
recovery using server
certificates.
Principal and mirror and servers running in
different datacenters for disaster recovery. You
must deploy using server certificates because an
Active Directory domain cannot span multiple
datacenters.
Principal, mirror, and witness servers all running in the
same Azure datacenter for high availability. You can
deploy using a domain controller.
You can also deploy the same database mirroring configuration
without a domain controller by using server certificates instead.

18.
Database Mirroring vs Always On AG

19.
Database Mirroring (Hybrid)
Azure Only
Principal and mirror
and servers running
in different
datacenters for
disaster recovery.
Principal, Mirror, and
Witness run within
same Azure data
center, deployed
using a DC or server
certificates for HA.
Hybrid
One partner running
in an Azure VM and
the other running
on-premises for
cross-site disaster
recovery using server
certificates.
One partner running in an Azure VM and the other running on-premises for
cross-site disaster recovery using server certificates. Partners do not need to be
in the same Active Directory domain, and no VPN connection is required.
Another database mirroring scenario involves one partner running in an Azure
VM and the other running on-premises in the same Active Directory domain for
cross-site disaster recovery. A VPN connection between the Azure virtual
network and the on-premises network is required.
For successful disaster recovery of your databases, you should also install a
replica domain controller at the disaster recovery site.

20.
Log Shipping (Hybrid)
For DR only /
Hybrid only
One server running in
an Azure VM and the
other running on-
premises for cross-
site disaster recovery.
Log shipping
depends on Windows
file sharing, so a VPN
connection between
the Azure virtual
network and the on-
premises network is
required.
Requires AD
deployment on DR
site.

21.
Block blobs
Reduced storage costs
Significantly improved
restore performance
More granular control
over Azure Storage
Azure Storage snapshot
backup
Fastest method for creating
backups and running restores
Support of SQL Server database
files on Azure Blob Storage
Backup to Azure
Managed backup
On-prem to Azure
Granular control of the backup
schedule
Local staging for faster recovery and
greater network resiliency
System database support
Simple recovery mode support
On-prem or Azure
production databases
backed up directly to
Azure blob storage
for disaster recovery.
SQL 2016: Backup to
Azure with file
snapshots
Azure production databases backed up directly to Azure blob
storage in a different datacenter for disaster recovery
On-premises production databases backed up directly
to Azure blob storage for disaster recovery.

22.
Backup to Azure with file snapshots (SQL Server 2016)
BACKUP DATABASE database TO
URL = N'https://<account>.blob.core.windows.net/<container>/<backupfileblob1>‘
WITH FILE_SNAPSHOT
Instance
Azure Storage
MDF
Database
MDF
LDF
LDF
BAK
Hybrid solutions

23.
SQL Server data files in Azure (Hybrid)
Native support for
SQL Server data files
stored as Azure blobs
- Easy and fast migration
benefits
- Cost and limitless storage
benefits
- High availability and
disaster recovery benefits
- Security benefits
- Snapshot backup

24.
Azure Site Recovery (Hybrid)
Simpler BCDR story
Site Recovery makes
it easy to handle
replication, failover
and recovery for your
on-premises
workloads and
applications (not
data!).
Flexible replication
You can replicate on-
premises servers,
Hyper-V virtual
machines, and
VMware virtual
machines.
Eliminate the need
for secondary
SQL Server on-prem DR example:
Standalone SQL Server instance
residing on-premises and replicating
to an Azure Storage account by using
Azure Site Recovery. The replication
targets are page blobs containing the
vhd files (C drive) of Azure IaaS virtual
machines hosting SQL Server
instances that are brought online
during failover. SQL Server data files
are not handled with ASR.

25.
Azure VM Availability Set
Create redundant
VMs that are spread
across multiple racks
in the Windows Azure
Data Centers. This
means redundant
power supply,
switches and servers
99.95% SLA
guaranteed (99.9%
SLA for single
instance)
Each virtual machine
in your Availability
Set is assigned an
Update Domain (UD)
and a Fault Domain
(FD)
In ARM it is not yet
possible to add an
existing VM to an
availability set.
VMs in an Availability Set can be
different sizes, but they need to be
within a range of sizes supported
by the hardware where the first VM
lands. Generally we recommend to
keep the VMs within the same
family for a reliable deployment.
This means only using VMs of the
following sizes in the same set:
 A0 – A7
 A8 – A11
 D1 – D14
 DS1 – DS14
 D1v2 – D14v2
 G1 – G5
 GS1 – GS5

26.
Azure SQL Data Sync (preview)
SQL Azure Data Sync is a Microsoft Windows Azure web service that provides data synchronization capabilities for SQL
databases. SQL Azure Data Sync allows data to be synchronized between on-premises SQL Server databases and Azure SQL
databases; in addition, it can also keep multiple Azure SQL databases in sync.
SQL Data Sync targets the reference data replication
scenario. Its key capabilities are:
 Sync between SQL Server (2005 SP2 and later)
and Azure SQL databases, or between Azure
SQL databases
 One-way and bi-directional sync
 One-to-one and hub-spoke
 Table filter and column filter
 Scheduled and on-demand
 Eventual consistency
Active Geo-Replication, in contrast, targets GeoDR
scenario for Azure SQL Database by replicating the
database to another region. It only supports one-
way replication (secondaries are read-only),
replication is at database granularity and no
database or column/row filter support, and it is only
available for Premium service tier.

27.
Stretch database architecture
How it works
Creates a secure linked server
definition in the on-premises SQL
Server
Linked server definition has the
remote endpoint as the target
Provisions remote resources and
begins to migrate eligible data, if
migration is enabled
Queries against tables run against
both the local database and the
remote endpoint
Remote
Endpoint
Remote
Data
Azure
InternetBoundary
Local
Database
Local
Data
Eligible
Data

28.
Resources
SQL Server in VM best practices: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-
server-performance-best-practices/
https://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-
limits/#virtual-machines-limits
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs/
https://azure.microsoft.com/en-us/pricing/details/virtual-machines/
Disaster Recovery and High Availability for Azure Applications: https://msdn.microsoft.com/en-
us/library/azure/dn251004.aspx

29.
Q & A ?
James Serra, Big Data Evangelist
Email me at: JamesSerra3@gmail.com
Follow me at: @JamesSerra
Link to me at: www.linkedin.com/in/JamesSerra
Visit my blog at: JamesSerra.com (where this slide deck is posted via the “Presentations” link on the top menu)