14.4 Storage Replica & Storage Quality of Service

Storage Replica & Storage Quality of Service

Maintaining business continuity and guaranteeing predictable storage performance are two sides of the same Windows Server storage discipline. Storage Replica protects a volume by mirroring its blocks to another server or cluster for disaster recovery, and Storage Quality of Service (Storage QoS) protects the workloads already running by keeping any single virtual machine from consuming the whole storage subsystem.

Mastering the operational mechanics of synchronous versus asynchronous replication, the volume and log requirements of a partnership, and the difference between Dedicated and Shared Storage QoS policies are core competencies tested on the AZ-800 exam.

---

1. Storage Replica Architecture & Mechanics

Storage Replica is a volume-level, block-based disaster recovery feature of Windows Server. It is unrestricted in Datacenter edition; Standard edition also supports it from Windows Server 2019 onward, but is limited to a single replicated volume of up to 2 TB in one partnership. Unlike application-level replication (such as Hyper-V Replica, SQL Server Always On, or DFS Replication), Storage Replica operates underneath the file system at the raw partition block layer.

+-----------------------------------------------------------------------------------+
|                         STORAGE REPLICA ARCHITECTURE                              |
|                                                                                   |
|   [SOURCE SERVER / NODE]                               [DESTINATION SERVER / NODE]|
|   +-----------------------+                            +------------------------+ |
|   | Application (SQL/VM)  |                            | Destination Filesystem | |
|   +-----------------------+                            | (Dismounted / Offline) | |
|               |                                        +------------------------+ |
|               v                                                    ^              |
|   +-----------------------+                            +------------------------+ |
|   | File System (NTFS/ReFS|                            | File System Driver     | |
|   +-----------------------+                            +------------------------+ |
|               |                                                    ^              |
|               v                                                    |              |
|   +-----------------------+                            +------------------------+ |
|   | SR Filter Driver      | =====(SMB3 / RDMA)=======> | SR Filter Driver       | |
|   +-----------------------+   Block-Level Replication  +------------------------+ |
|         |           |                                       |           |         |
|         v           v                                       v           v         |
|     [Src Log]   [Src Data]                              [Dst Log]   [Dst Data]    |
|     (Volume L:) (Volume D:)                             (Volume L:) (Volume D:)   |
+-----------------------------------------------------------------------------------+

Key Architectural Characteristics

1. Block-Level Operation: Replicates raw storage blocks rather than individual files. It seamlessly replicates in-use files, open SQL Server .mdf/.ldf databases, running Hyper-V .vhdx disks, and locked system files without file system locking conflicts.
2. Storage-Agnostic: Operates across completely heterogeneous storage hardware. Source and destination volumes can reside on Storage Spaces Direct (S2D), SAN LUNs, iSCSI arrays, hardware RAID, or direct-attached NVMe/SATA drives.
3. Volume Pairing & Log Architecture:
   • Each replication partnership requires two volumes on the source and two matching volumes on the destination: one Data Volume (e.g., D:) and one dedicated Log Volume (e.g., L:).
   • Log volumes act as write-ahead transaction journals and must be formatted with NTFS or ReFS. To minimize write latency, log volumes should always reside on high-speed solid-state media (NVMe or SSD).
   • While replication is active, the destination Data Volume is placed in a dismounted / offline state to prevent accidental writes or split-brain corruption.

---

2. Replication Modes: Synchronous vs. Asynchronous

Storage Replica supports two fundamental replication modes based on Recovery Point Objective (RPO) requirements and network latency.

+-----------------------------------------------------------------------------------+
|                 SYNCHRONOUS VS ASYNCHRONOUS REPLICATION MODES                     |
|                                                                                   |
|   FEATURE / METRIC      SYNCHRONOUS REPLICATION         ASYNCHRONOUS REPLICATION  |
|   --------------------+-------------------------------+---------------------------|
|   Recovery Point Obj. | **Zero Data Loss (RPO = 0)**  | **Low RPO (RPO > 0)**     |
|   Acknowledgment Flow | App write acknowledged ONLY   | App write acknowledged    |
|                       | after destination log commit  | immediately on source log |
|   Latency Limit       | **<= 5 ms Round-Trip (RTT)**  | No strict latency limit   |
|                       | (<= 2 ms recommended)         | (Permits high WAN latency)|
|   Bandwidth Req.      | **>= 1 Gbps** (10GbE rec.)    | Scaled to write rate      |
|   Network Distance    | Metro-distance (< 30-50 km)   | Global / Intercontinental |
|   Primary Use Case    | Campus HA / Stretched Cluster | Cross-region Disaster Rec.|
+-----------------------------------------------------------------------------------+

Synchronous Replication Write Sequence

1. The application issues a write I/O to the source file system.
2. The Storage Replica filter driver intercepts the write and writes the block to the Source Log Volume.
3. Simultaneously, the driver transmits the block across the network (over SMB3/RDMA on TCP port 445 / port 5445) to the destination server.
4. The destination filter driver writes the block into the Destination Log Volume.
5. The destination server sends a write acknowledgment back to the source server.
6. The source server sends an I/O completion confirmation to the application.
7. In the background, both source and destination asynchronously flush data blocks from their respective Log Volumes to their Data Volumes.

---

3. Storage Replica Topologies & PowerShell Management

Storage Replica can be deployed across four architectural topologies:

+-----------------------------------------------------------------------------------+
|                         STORAGE REPLICA TOPOLOGIES                                |
|                                                                                   |
|   1. SERVER-TO-SERVER (Standalone to Standalone)                                  |
|      [Server01 (D: & L:)] ============================> [Server02 (D: & L:)]      |
|                                                                                   |
|   2. CLUSTER-TO-CLUSTER (Cluster to Cluster)                                      |
|      [Cluster 1 (CSV D: & L:)] =======================> [Cluster 2 (CSV D: & L:)] |
|                                                                                   |
|   3. STRETCHED CLUSTER (Single Cluster Spanning Two Sites)                        |
|      [Site A Nodes (CSV D:)] <--(Auto Failover / SR)--> [Site B Nodes (CSV D:)]   |
|                                                                                   |
|   4. SERVER-TO-SELF (Test / Volume-to-Volume on Same Machine)                     |
|      [Server01 Volume D:] ============================> [Server01 Volume F:]      |
+-----------------------------------------------------------------------------------+

Topology Details

• Server-to-Server: Replicates volumes between two standalone Windows Server instances. Manual failover involves reversing replication direction.
• Cluster-to-Cluster: Replicates storage between two independent Failover Clusters (e.g., Primary Datacenter S2D Cluster to DR Datacenter S2D Cluster).
• Stretched Cluster (Stretch Cluster): A single Failover Cluster spanning two geographic sites with site awareness. Storage Replica handles the underlying storage replication while Failover Clustering orchestrates automated virtual machine live migration and failover.

Deploying Storage Replica via PowerShell

# Step 1: Install Storage Replica Feature on both servers
Install-WindowsFeature -Name Storage-Replica, FS-FileServer -IncludeManagementTools -Restart

# Step 2: Validate replication topology, network latency, and disk write performance
Test-SRTopology `
    -SourceComputerName 'SRV-NYC-01' `
    -SourceVolumeName 'D:' `
    -SourceLogVolumeName 'L:' `
    -DestinationComputerName 'SRV-MIA-01' `
    -DestinationVolumeName 'D:' `
    -DestinationLogVolumeName 'L:' `
    -DurationInMinutes 10 `
    -ResultPath 'C:\SRReports'

# Step 3: Establish a Synchronous Server-to-Server Replication Partnership
New-SRPartnership `
    -SourceComputerName 'SRV-NYC-01' `
    -SourceRGName 'RG-NYC-Data' `
    -SourceVolumeName 'D:' `
    -SourceLogVolumeName 'L:' `
    -DestinationComputerName 'SRV-MIA-01' `
    -DestinationRGName 'RG-MIA-Data' `
    -DestinationVolumeName 'D:' `
    -DestinationLogVolumeName 'L:' `
    -ReplicationMode Synchronous

# Step 4: Query replication status and synchronization progress
Get-SRPartnership
Get-SRGroup

# Step 5: Execute Disaster Recovery Failover (Reverse Replication Direction)
Set-SRPartnership `
    -NewSourceComputerName 'SRV-MIA-01' `
    -SourceRGName 'RG-MIA-Data' `
    -DestinationComputerName 'SRV-NYC-01' `
    -DestinationRGName 'RG-NYC-Data'

---

4. Editions, Prerequisites and Network Requirements

Before a partnership can be created, the environment must satisfy a short but unforgiving prerequisite list:

Because the transport is SMB 3, Storage Replica inherits SMB multichannel, RDMA support over iWARP, InfiniBand and RoCE v2, packet signing, AES-128-GCM encryption and Kerberos AES-256 authentication between nodes without any separate configuration.

Two behaviours are worth committing to memory because they invert common assumptions:

• The destination volume is inaccessible while replicating. Its drive letter may still be visible in File Explorer, but no application can read or write it. Test-Failover temporarily mounts a read-write snapshot of the destination for backup or validation without breaking the partnership.
• Storage Replica is not a backup. It replicates every block change, including deletions, immediately. A user who empties a volume empties both copies. Point-in-time recovery still requires a backup product, although Storage Replica does replicate VSS snapshots because it operates at the partition layer.

Network compression for Storage Replica data transfer is supported only on Windows Server Datacenter: Azure Edition from OS build 20348.1070 onward — it is not a general Windows Server capability.

5. Storage Quality of Service (Storage QoS)

In multi-tenant virtualization and shared storage environments, a single runaway virtual machine ("noisy neighbor") executing massive random I/O can saturate physical disk spindles or RDMA queues, starving adjacent mission-critical workloads. Storage Quality of Service (Storage QoS) in Windows Server Failover Clustering provides centralized policy management to regulate and guarantee IOPS throughput.

+-----------------------------------------------------------------------------------+
|                         STORAGE QUALITY OF SERVICE (QoS)                          |
|                                                                                   |
|   STORAGE QoS POLICY TYPES:                                                       |
|                                                                                   |
|   1. DEDICATED (SINGLE-INSTANCE) POLICY                                           |
|      Policy: Min 500 IOPS, Max 2,000 IOPS                                         |
|      - VM 1: Guaranteed 500 IOPS, Throttled at 2,000 IOPS                         |
|      - VM 2: Guaranteed 500 IOPS, Throttled at 2,000 IOPS                         |
|      (Limits apply INDIVIDUALLY to each VM)                                       |
|                                                                                   |
|   2. SHARED (AGGREGATED) POLICY                                                   |
|      Policy: Min 1,000 IOPS, Max 5,000 IOPS                                       |
|      - [VM 1 + VM 2 + VM 3] Collectively share the 5,000 IOPS limit               |
|      (Limits apply CUMULATIVELY across the group)                                 |
+-----------------------------------------------------------------------------------+

Policy Parameters & Types

1. Minimum IOPS (Reservation): A soft reservation threshold (calculated using normalized 8 KB I/O units). If a workload receives fewer IOPS than the minimum, the cluster generates performance alerts for remediation.
2. Maximum IOPS (Limit): A hard ceiling enforced using a token-bucket algorithm. The storage subsystem throttles virtual machine I/O to prevent the workload from exceeding the defined limit.
3. Dedicated Policies: The minimum/maximum IOPS rules are applied independently and discretely to each assigned virtual hard disk or VM.
4. Shared Policies: The minimum/maximum IOPS thresholds are pooled and shared collectively across all assigned virtual disks or VMs.

# Create a Dedicated Storage QoS Policy for High-Priority Database VMs
New-StorageQoSPolicy `
    -Name 'Gold-Tier-Policy' `
    -PolicyType Dedicated `
    -MinimumIops 1000 `
    -MaximumIops 5000

# Create a Shared Storage QoS Policy for Dev/Test VMs
New-StorageQoSPolicy `
    -Name 'DevTest-Shared-Policy' `
    -PolicyType Shared `
    -MinimumIops 500 `
    -MaximumIops 2500

# Assign the Policy to a Hyper-V Virtual Hard Disk Drive
Get-VM -Name 'VM-SQL-PROD' | Get-VMHardDiskDrive | Set-VMHardDiskDrive -StorageQoSPolicy 'Gold-Tier-Policy'

# Monitor Storage QoS Performance and Policy Compliance
Get-StorageQoSVolume
Get-StorageQoSFlow | Format-Table InitiatorName, StorageNodeName, NormalizedIops, Limit, Status