Author: Parsan Saffaie

Locality‑Aware Read Optimization for Modern Multi‑Rack and Campus Deployments

With Windows Server 2025, Storage Spaces Direct (S2D) expanded its resiliency capabilities with support for Campus Clusters, allowing Failover Cluster deployments to span racks, chassis, and even sites using explicit fault‑tolerance domains. If you haven’t seen it yet, check out Rob’s announcement here:

Announcing Support for S2D Campus Cluster on Windows Server 2025.

Building on that foundation, Windows Server 2025 introduces Rack‑Local Reads, a new optimization that allows S2D to use the cluster topology during read selection, ensuring mirrored reads are served from the closest healthy copy whenever possible.

Before Rack‑Local Reads

Before this feature, when a mirrored space was deployed in an S2D cluster, data copies were placed across fault‑tolerant domains (nodes, racks, or sites) to ensure resiliency.

During read operations, all healthy copies were treated as equal. When a read I/O arrived, S2D could satisfy it from any available copy containing the requested data offset — regardless of where that copy was located in the cluster.

This behavior was correct and safe, but it was topology‑agnostic.

Example: topology-agnostic read selection

This diagram shows a conceptual view of read behavior in a multi‑rack cluster, where a workload may read from a remote rack even though a local copy is available.

Read selection flow:

1. A read request arrives on Node 1 in Rack 1, where the workload is running.
2. Storage Spaces Direct identifies all healthy copies of the requested data offset.
3. The local copy on Node 1 (Copy A on Drive 1) is unavailable.
4. Remaining healthy copies exist on Node 2, Node 3, and Node 4.
5. Because read selection is topology‑agnostic, rack locality is not considered.
6. A healthy copy on Node 3 (Rack 2) is selected.
7. The read is serviced across racks, traversing the inter‑rack fabric.

Why the Old Design Was Suboptimal

In larger S2D deployments, this topology‑agnostic read selection can result in unnecessary cross‑rack or cross‑site traffic during steady‑state operations. While resiliency placement is correct, read performance becomes dependent on fabric conditions rather than locality, increasing latency variability and making the network part of the critical read path.

After Rack‑Local Reads

With the new Rack‑Local Reads, write behavior is unchanged. What changes is read selection. Instead of treating all healthy copies as equal, S2D now prefers the closest healthy copy based on topology. Reads are served from the nearest available copy in the fault domain—node, chassis, rack, or site—with remote locations used only when no closer copy exists.

As a result, read traffic remains local during steady‑state operations, even in multi‑rack and campus deployments.

Example: topology-aware read selection

This diagram shows the same cluster topology as the previous example, but with Rack‑Local Reads enabled. Read selection now accounts for rack locality when choosing among healthy copies.

Read selection flow:

1. A read request arrives on Node 1 in Rack 1, where the workload is running.
2. Storage Spaces Direct identifies all healthy copies of the requested data offset.
3. The local copy on Node 1 (Copy A on Drive 1) is unavailable.
4. Remaining healthy copies exist on Node 2, Node 3, and Node 4.
5. Rack‑Local Reads evaluates the proximity of each healthy copy based on the fault domain.
6. A healthy copy on Node 2 (Rack 1) is selected as the closest available copy.
7. The read is serviced within the local rack, avoiding cross‑rack traffic.

Why the New Design Is Better

By incorporating topology awareness into the read path, Rack‑Local Reads keep steady‑state read traffic local whenever a healthy copy is available. This preserves existing resiliency guarantees while reducing cross‑rack traffic, lowering latency, and making read performance less dependent on fabric conditions.

Summary:

Rack‑Local Reads separate resiliency from performance: rack‑aware mirroring determines where data is placed for protection, while Rack‑Local Reads determine which copy is used for performance.

Nothing changes for writes or resiliency. Data placement remains exactly the same. What changes is read selection—S2D now prefers the closest healthy copy in the fault domain, keeping steady‑state reads local when possible.

The result is lower and more predictable read latency, reduced east‑west storage traffic, and better scalability in multi‑rack and campus deployments—without sacrificing fault tolerance.

Microsoft runs on trust. We’d like to thank our customers and MVPs for that trust, and for the feedback that directly shaped Rack‑Local Reads. Your real‑world deployments continue to push Storage Spaces Direct to scale to larger and more complex environments.

Note: Posted by Rob for Parsan Saffaie.