8.2 Hyper-V Replica & Azure Site Recovery (ASR)

Hyper-V Replica & Azure Site Recovery (ASR)

Disaster recovery planning ensures an organization can maintain operational continuity when a catastrophic event—such as a flood, extended power blackout, cyber incident, or localized datacenter failure—destroys or isolates primary compute infrastructure. In Microsoft hybrid environments, organizations achieve comprehensive disaster recovery through two primary technologies:

1. Hyper-V Replica: A built-in, host-level asynchronous replication feature that replicates virtual machines between on-premises Hyper-V hosts without requiring expensive storage arrays or SAN replication licenses.
2. Azure Site Recovery (ASR): A cloud-native disaster recovery orchestration service that replicates on-premises Hyper-V virtual machines directly into Microsoft Azure storage, providing low-cost, cloud-burst failover capabilities.

---

1. Hyper-V Replica Architecture & Core Concepts

Hyper-V Replica operates at the hypervisor layer, tracking changes to a virtual machine's virtual hard disks (.vhdx) using a log-based tracking mechanism. Periodically, these delta change logs are compressed and transmitted across the network to a secondary (Replica) Hyper-V host, where they are applied to the replica virtual disks.

+-----------------------------------------------------------------------------------------+
|                              HYPER-V REPLICA ARCHITECTURE                               |
|                                                                                         |
|   PRIMARY SITE (Production)                       REPLICA SITE (Disaster Recovery)      |
|   +------------------------------------+          +------------------------------------+|
|   | Primary Hyper-V Host               |          | Secondary Replica Hyper-V Host     ||
|   |  [VM-PROD-01 (Running)]            |          |  [VM-PROD-01 (Off / Standby)]      ||
|   |   - VHDX Active Writes             |          |   - Replica VHDX Disk Base         ||
|   |   - Replication Delta Log (HRL)    |          |   - Recovery Point Snapshots (HRL) ||
|   +-----------------+------------------+          +-----------------+------------------+|
|                     |                                               ^                   |
|                     |======== Asynchronous Replication Delta =======|                   |
|                               HTTP Port 80 (Kerberos) /                                 |
|                               HTTPS Port 443 (Certificates)                             |
|                                                                                         |
|   CASCADE (OPTIONAL):                                                                   |
|   Secondary Replica Host ======= Extended Replication ======> Tertiary DR Site Host    |
|                                (30s / 5m / 15m)                                         |
+-----------------------------------------------------------------------------------------+

Key Architectural Characteristics:

• Storage-Agnostic: Primary and replica hosts can use completely different storage subsystems (e.g., primary on NVMe SAN, replica on local DAS SATA drives).
• Workload-Agnostic: Replicates any guest operating system supported by Hyper-V (Windows Server, Windows client, Linux).
• Cluster Integration (Hyper-V Replica Broker): When primary or secondary Hyper-V hosts are clustered, the Hyper-V Replica Broker cluster role must be provisioned. The Broker provides a single virtual NetBIOS/FQDN name and IP address, managing VM placement and tracking replica states even if the VM Live Migrates between cluster nodes.

---

2. Replication Authentication & Transport Security

Hyper-V Replica supports two distinct authentication and encryption protocols for data transmission:

+-----------------------------------------------------------------------------------------+
|                    HYPER-V REPLICA AUTHENTICATION MODES COMPARISON                      |
|                                                                                         |
|   AUTHENTICATION MODE    PORT / PROTOCOL   SECURITY ATTRIBUTES      BEST DEPLOYMENT     |
|   --------------------+-----------------+------------------------+----------------------|
|   Kerberos (HTTP)     | TCP Port 80     | - Mutual AD auth       | Single Active        |
|                       | (Unencrypted)   | - Unencrypted payload  | Directory Forest     |
|                       |                 | - Requires domain join | Dedicated secure WAN |
|   --------------------+-----------------+------------------------+----------------------|
|   Certificates (HTTPS)| TCP Port 443    | - Mutual X.509 certs   | Untrusted domains,   |
|                       | (Encrypted TLS) | - Full SSL/TLS payload | Cross-forest,        |
|                       |                 | - Subject Name/SAN chk | DMZ, Public Internet |
+-----------------------------------------------------------------------------------------+

Certificate Authentication Requirements:

When using HTTPS (Port 443) mutual certificate authentication, X.509 certificates installed on both primary and replica servers must satisfy strict validation rules:

1. Enhanced Key Usage (EKU): Must support both Client Authentication (1.3.6.1.5.5.7.3.2) and Server Authentication (1.3.6.1.5.5.7.3.1).
2. Subject Alternative Name (SAN): Must match the FQDN of the Hyper-V host or the Hyper-V Replica Broker cluster name.
3. Trust Chain & Revocation: Must chain up to a trusted Root CA installed in the Trusted Root Certification Authorities certificate store on both hosts, with accessible CRL (Certificate Revocation List) distribution points.

# Configure the local Hyper-V host as a Replica Server accepting HTTPS traffic
Set-VMReplicationServer -ReplicationEnabled $true `
    -AllowedAuthenticationType Certificate `
    -CertificateThumbprint "3A5B7C9D0E1F2A3B4C5D6E7F8A9B0C1D2E3F4A5B" `
    -ReplicationAllowedLocationsPath "D:\Hyper-V\ReplicationStorage" `
    -DefaultStorageMappingType BySystemName `
    -Port 443

---

3. Replication Intervals & Recovery Point Types

Hyper-V Replica allows administrators to tailor the Recovery Point Objective (RPO) and snapshot retention policy per virtual machine.

1. Replication Frequency

Administrators select one of three preset replication intervals:

• 30 Seconds: Minimizes data loss for critical transactional workloads; requires high-throughput, low-latency network interconnects.
• 5 Minutes: The default balanced setting for standard enterprise workloads.
• 15 Minutes: Designed for low-bandwidth, high-latency WAN links or branch office links.

2. Recovery Point Retention & Application Consistency

• Standard (Crash-Consistent) Recovery Points: Captures the state of virtual hard disks at the exact moment of replication. Captures data on disk as if the server suffered a power outage.
• Additional Recovery Points: Allows storing hourly historical snapshots for up to 24 hours, enabling administrators to roll back ransomware infections or database corruption to an earlier point in time.
• Volume Shadow Copy Service (VSS) Application-Consistent Snapshots: Hyper-V invokes the in-guest VSS framework via Hyper-V Integration Services to flush open application memory buffers, commit database transactions (e.g., SQL Server or Exchange), and write clean recovery points at configured intervals (e.g., every 1 to 12 hours).

# Enable replication for a specific production VM with 30-second interval and VSS snapshots
Enable-VMReplication -VMName "VM-SQL-01" `
    -ReplicaServerName "hv-dr-host.corp.contoso.com" `
    -ReplicaServerPort 443 `
    -AuthenticationType Certificate `
    -CertificateThumbprint "3A5B7C9D0E1F2A3B4C5D6E7F8A9B0C1D2E3F4A5B" `
    -CompressionEnabled $true `
    -ReplicationFrequencySec 30 `
    -RecoveryHistory 24 `
    -VSSSnapshotFrequencyHour 4

# Initiate the baseline initial replication over the network
Start-VMInitialReplication -VMName "VM-SQL-01"

3. Extended Replica (Cascading DR)

Extended Replica (also known as 3-tier replication) allows the secondary replica server to forward incoming replication deltas to a tertiary disaster recovery site. For example: Primary (Chicago) --> Secondary Replica (Dallas) --> Extended Replica (Phoenix).

• Constraint: The extended replication interval must be equal to or greater than the primary replication frequency (e.g., if Primary-to-Secondary is 5 minutes, Secondary-to-Tertiary must be 5 minutes or 15 minutes).

4. Failover Operations: Test, Planned, and Unplanned

Hyper-V Replica supports three distinct operational failover workflows:

+-----------------------------------------------------------------------------------------+
|                        FAILOVER WORKFLOW CHARACTERISTICS                                |
|                                                                                         |
|   FEATURE               TEST FAILOVER          PLANNED FAILOVER       UNPLANNED FAILOVER|
|   --------------------+----------------------+----------------------+-------------------|
|   Primary VM State    | Continues running    | Must be turned off   | Destroyed/Offline |
|   Data Loss (RPO)     | None (Isolated test) | Zero data loss (RPO=0| Potential data    |
|                       |                      |                      | loss (RPO > 0)    |
|   Replication Impact  | Continues unhindered | Flushes final delta  | Severed / Stopped |
|   Target Network      | Isolated non-prod VMS| Production network   | Production network|
|   Execution Location  | Secondary Host       | Primary Host first   | Secondary Host    |
+-----------------------------------------------------------------------------------------+

1. Test Failover (Start-VMFailover -AsTest)

Allows testing disaster recovery runbooks without interrupting production workloads or pausing replication. Hyper-V creates a temporary test virtual machine (VM-SQL-01 - Test) instantiated from a chosen recovery point and attaches it to an isolated, non-routable virtual switch. After testing, Stop-VMFailover -AsTest deletes the temporary VM and discards its differencing disks.

2. Planned Failover (Start-VMFailover)

Used during scheduled maintenance, anticipated weather emergencies, or planned datacenter migrations. Guarantees zero data loss (RPO = 0):

1. The primary VM is cleanly powered off.
2. The administrator triggers planned failover from the primary host (Start-VMFailover -VMName "VM-SQL-01" -Prepare).
3. Hyper-V transmits all uncommitted pending write deltas to the replica server.
4. The replica server starts the VM.
5. Reverse replication is configured to protect the workload back to the primary site (Set-VMReplication -Reverse).

3. Unplanned Failover

Executed directly on the secondary Replica host when the primary datacenter suffers total unexpected destruction. The administrator selects the most recent or known-good recovery point and powers on the replica VM. Because unexpected outages prevent sending the final uncommitted delta, an unplanned failover carries some data loss bounded by the configured replication interval.

---

5. Azure Site Recovery (ASR) for Hyper-V

Azure Site Recovery (ASR) extends disaster recovery into the cloud by orchestrating replication of on-premises Hyper-V virtual machines directly to Microsoft Azure Storage.

+-----------------------------------------------------------------------------------------+
|                    AZURE SITE RECOVERY (ASR) ARCHITECTURAL FLOW                         |
|                                                                                         |
|   [ON-PREMISES HYPER-V HOST]                        [AZURE CLOUD INFRASTRUCTURE]        |
|   +-------------------------------+                 +---------------------------------+ |
|   | Windows Server 2022 Hyper-V   |                 | Recovery Services Vault         | |
|   | - ASR Provider                |                 | - Replication Policy            | |
|   | - MARS Agent                  |=== HTTPS 443 ==>| - Recovery Plans & Runbooks     | |
|   |                               |                 +---------------------------------+ |
|   | [VM-APP-01]                   |                                |                    |
|   |  - Real-time VHDX Delta Log   |                 +--------------v------------------+ |
|   +-------------------------------+                 | Azure Storage (Managed Disks)   | |
|                                                     | - Standard / Premium SSD Disks  | |
|                                                     +---------------------------------+ |
+-----------------------------------------------------------------------------------------+

ASR Deployment Components & Workflow:

1. Recovery Services Vault: The centralized Azure Resource Manager entity that holds replication policies, recovery plans, and orchestration mappings.
2. Azure Site Recovery Provider & MARS Agent: Installed on physical Hyper-V cluster nodes. Communicates outbound over HTTPS (Port 443) with Azure; no incoming firewall ports required.
3. Storage Replication: Virtual disk changes replicate to Azure Storage Accounts (or directly to Azure Managed Disks). In steady-state replication, no Azure virtual machine compute charges are incurred—organizations pay only for raw blob/disk storage consumption.
4. Recovery Plans & Orchestration: ASR Recovery Plans group multi-tier applications (e.g., Web tier, Application tier, Database tier) into sequenced failover groups, executing integrated Azure Automation Runbooks to update DNS records, adjust load balancers, and assign network security groups upon failover.