13.2 Hybrid and Azure-Specific HA/DR Solutions and Testing

Hybrid HA/DR Considerations

A hybrid deployment spans on-premises SQL Server and Azure SQL targets. The DP-300 exam treats hybrid as a first-class scenario because most enterprise workloads migrate incrementally, with a primary on-premises and a secondary in Azure (or vice versa) during the transition. Three considerations dominate.

Network connectivity. Replication and failover traffic crosses an ExpressRoute circuit or a site-to-site VPN. ExpressRoute gives predictable, low-latency private bandwidth; VPN is cheaper but variable. The key planning point is that synchronous-commit replication (Always On AG) over a hybrid link is sensitive to round-trip latency - typically you want single-digit milliseconds for sync commit to avoid throttling transaction throughput. If the link exceeds that, the design drops to asynchronous commit, which changes the RPO from near-zero to seconds-to-minutes.

DNS and client redirection. After a hybrid failover, clients must resolve the new primary. On-premises, a SQL Server listener or a DNS update handles this; in Azure, the failover group listener endpoint or a Traffic Manager profile does. The exam tests the case where the application keeps pointing at the on-premises name after failover - the recovery stalls until DNS is updated or the application connection string is repointed. A failover group listener (read-write endpoint) abstracts this for Azure-side secondaries.

Asymmetric capacity. The Azure secondary often runs at a lower service tier than the primary to save cost; after failover it must still carry the production load, so the runbook includes a scale-up step, or the secondary is sized for peak from the start. Failing to plan capacity on the secondary is a common DR gap.

Azure-Specific HA/DR Options

Azure provides layered redundancy that the exam expects you to distinguish by scope of failure:

Locally redundant storage (LRS) keeps three synchronous copies within a single datacenter. Zone-redundant storage (ZRS) adds asynchronous copies across availability zones in the same region. Geo-redundant storage (GRS) replicates asynchronously to the paired region. Azure SQL Database and SQL MI abstract these choices behind service-tier options: zone redundancy is a configuration flag (available in most regions on supported tiers) that spreads replicas or storage across zones, and geo-backup replication to the paired region is on by default.

Azure region pairs are the foundation of cross-region DR. Each Azure region is paired with one other region in the same geography (for example, East US 2 with Central US). Region pairs run at least 300 miles apart, update and patch one region at a time, and replicate some platform-level metadata across the pair. Failover groups default to the paired region for the secondary, and geo-restore recovers from the geo-replicated backups stored there. Asynchronous replication across the pair means the secondary lags by seconds to minutes - this is the RPO for geo-restore and failover groups.

Availability zones are physically separate datacenters within a region with independent power, cooling, and network. For SQL on VMs, you deploy across zones for the strongest single-region resilience. For Azure SQL Database and SQL MI, enabling zone redundancy places replicas in different zones, raising the availability SLA. Availability sets, by contrast, protect only against rack failure within a datacenter and are the older fault-domain construct - still valid for SQL on VMs when zones are not available, but inferior to zones.

SQL Server on Azure VMs: HA Options

On SQL Server VMs you build HA from IaaS primitives. Two patterns dominate.

Always On availability groups on a Windows Server Failover Cluster (WSFC) across two or more VMs, optionally across zones, with a listener backed by an Azure Load Balancer (internal) or, with newer SQL Server 2022 + Windows Server 2016+, a Distributed Network Name (DNN) listener that does not need the load balancer. Synchronous commit to a zone-local replica gives RPO 0-5s; asynchronous commit to a remote-region replica adds DR. The AG listener abstracts failover behind a single DNS name.

Failover Cluster Instances (FCI) with shared storage. On Azure VMs, shared storage is provided by Storage Spaces Direct (S2D) across cluster nodes, by Azure Shared Disk (a premium or ultra disk attached to multiple VMs via SCSI Persistent Reservations), or historically by a file share witness with storage on each node. An FCI fails over the instance (all databases) to another node with no data loss because storage is shared; RPO is 0 and RTO is the service restart time. The Azure Load Balancer (or DNN) front-ends the FCI virtual network name.

The exam contrast: an AG fails over per-database (or per-AG) and supports readable secondaries, but each replica needs its own storage copy; an FCI fails over the whole instance and shares storage, but the standby node is not readable and a storage failure can affect the cluster unless S2D or zonal shared disk is used.

Planning the HA/DR Test

A strategy is only credible if tested. The exam expects you to plan a testing procedure with four levels of rigor:

• Tabletop exercise: operators walk through the runbook in a meeting, identifying gaps without touching systems. Validates documentation and decision flow.
• Failover drill: the team triggers failover in a controlled window against a non-production environment (or production with traffic diverted) and verifies the application reconnects.
• Full failover test: a planned production failover with traffic flowing, measuring realized RPO and RTO against targets. The most rigorous test.
• Unannounced test (game day): a surprise failover to test detection and human response under realistic conditions.

Each test must measure realized RPO (the data gap between the last committed transaction on the old primary and the moment the secondary became primary) and realized RTO (the elapsed time from failure to service restored). These are compared to the documented targets; if realized exceeds target, the strategy or runbook is updated.

Testing Cadence and Success Criteria

Define success criteria before the test: e.g., RPO <= 5 minutes, RTO <= 15 minutes, all critical databases readable, all applications reconnected within 10 minutes. Run tests on a regular cadence - quarterly is common for full failover tests, monthly for drills, semiannually for unannounced game days. After each test, capture the realized RPO/RTO, any failures, runbook gaps, and update the runbook and the strategy. A common exam scenario: a failover test reveals the secondary cannot carry the production load - the fix is to size the secondary correctly or add an automatic scale-up step to the runbook.