Balancing Mirroring and Parity in Windows Server Tiered Storage

Storage admins are under constant pressure to strike the best possible balance among performance, data resiliency and cost. The Windows Server operating system includes a number of features that can help administrators to maximize their storage investment. One such feature is mirror accelerated parity, which was introduced in Windows Server 2016 but is also available in Windows Server 2019.

Mirror accelerated parity is based on the idea that mirroring and parity are commonly used to provide storage fault tolerance, but both technologies have their advantages and disadvantages. Mirror accelerated parity gives administrators the best of both worlds.

Mirroring is arguably the simplest mechanism for providing fault tolerance, but this simplicity comes at a steep cost. Because write operations are directed to two drives simultaneously, 50% of the total raw storage capacity is lost to redundancy related overhead.

Parity makes more efficient use of the available storage space but sacrifices performance. Parity can exist in a variety of forms, but RAID 5 is one of the simplest examples. In this architecture, write operations are striped across multiple drives. Parity information is also written to each drive, so that if any one single drive in the set were to fail, then a sufficient amount of parity data exists on the other drives to keep the array functional.

The total amount of raw capacity that is lost to overhead in a RAID 5 configuration is equivalent to one drive. If, for example, a RAID 5 set consists of five drives, then the equivalent of one drive (20% of the set’s total capacity) is lost to overhead. Other parity RAID types have different amounts of overhead.

The important takeaway is that mirroring is relatively efficient from a performance standpoint, but half of a mirror set’s capacity is lost to overhead. Parity sets have far less capacity overhead, but write performance tends to be comparatively slow because of the need to calculate and then write the parity data.

Windows Server’s mirror accelerated parity feature, which is part of Storage Spaces Direct, spans an ReFS formatted volume across both mirrored storage and parity storage. Windows treats the mirrored storage as a high-speed (write caching) tier, and treats the parity storage as a high-capacity tier since it has less capacity overhead than mirroring.

Because the mirrored tier is intended to be used as a write cache, Windows attempts to write data to the mirrored tier whenever possible. There are four general rules governing write operations.

The reason why I mention these rules is to illustrate the point that the mirrored tier can be effective only if it has enough free space to accommodate the write operation. That being the case, Windows uses data rotation to move cold data off of the mirrored tier and onto the parity tier.

Although the default rotation scheme works well for some organizations, many storage admins find it beneficial to adjust the data rotation threshold. Setting a higher rotation threshold allows hot data to remain in the mirrored tier for a longer period of time but reduces the tier’s available capacity. Similarly, setting a lower rotation threshold risks placing more hot data into the parity tier but makes more space available within the mirrored tier.

Before I show you how to adjust this threshold, I need to clarify something: Assuming you are using the same media type for both tiers, the mirrored tier will improve write speeds but has almost no impact on read performance.

So, having said that, you can use PowerShell to set the data rotation threshold. Here is the command:

Set-ItemProperty -Path HKLM:SYSTEMCurrentControlSetPolicies -Name DataDestageSsdFillRatioThreshold -Value 70

The value (70, in this example) is the percentage of free space remaining in the mirror tier. In other words, data rotation will occur when 70% of the tier’s capacity is in use. The default rotation threshold is 85%, and Microsoft recommends that the threshold remain above 50%. It is also worth noting that making this change requires that the server be rebooted. If you are using a clustered Storage Spaces Direct deployment, then you will have to modify each one of the nodes. Microsoft provides this example of how you can modify the nodes in a storage spaces direct cluster:

$Nodes = 'S2D-01', 'S2D-02', 'S2D-03', 'S2D-04'Invoke-Command $Nodes {Set-ItemProperty -Path HKLM:SYSTEMCurrentControlSetPolicies -Name DataDestageSsdFillRatioThreshold -Value 75}