How to Use PowerShell to Manage Windows Server S2D Fault Domains

Introduction to Storage Spaces Direct (S2D) Fault Domains

Storage Spaces Direct (S2D) is a feature in Windows Server that enables the creation of highly available, scalable software-defined storage using industry-standard servers with local-attached drives. A critical concept in S2D is the Fault Domain, which represents a logical grouping of hardware components (like nodes, chassis, or racks) that could fail together due to a shared dependency, such as a power source or network switch.

By properly defining fault domains, Windows Server can intelligently distribute data copies across different domains. This ensures that a single point of failure—even the loss of an entire server rack—does not result in data loss or cluster downtime.

Understanding Fault Domain Hierarchy

Windows Server supports a strict fault domain hierarchy:

  • Site: The highest level, representing physical geographic locations.
  • Rack: Represents a server rack within a datacenter.
  • Chassis: Represents a blade enclosure or multi-node chassis.
  • Node: Represents a single physical server (the default fault domain).

When you enable S2D on a cluster, it automatically uses “Node” as the default fault domain. However, in larger deployments spanning multiple racks, you must manually configure the Rack fault domain using PowerShell.

Step 1: Identifying Existing Nodes

To begin configuring fault domains, open PowerShell as an Administrator on one of your cluster nodes and retrieve the existing cluster nodes and their current fault domain assignments:

Get-ClusterNode | Format-Table Name, FaultDomain, Description

By default, the FaultDomain property will likely be empty or assigned to the default site if no racks have been configured yet.

Step 2: Creating the Rack Fault Domains

To create a new fault domain representing a physical server rack, use the New-ClusterFaultDomain cmdlet. In this example, we will create two racks, Rack A and Rack B.

New-ClusterFaultDomain -Name "RackA" -Type Rack
New-ClusterFaultDomain -Name "RackB" -Type Rack

The -Type parameter must be one of the predefined hierarchical levels (Site, Rack, Chassis, Node).

Step 3: Assigning Nodes to Racks

Once the rack fault domains exist, you must move the existing cluster nodes into their respective racks using the Set-ClusterFaultDomain cmdlet.

# Move Node1 and Node2 to RackA
Set-ClusterFaultDomain -Name "Node1" -Parent "RackA"
Set-ClusterFaultDomain -Name "Node2" -Parent "RackA"

# Move Node3 and Node4 to RackB
Set-ClusterFaultDomain -Name "Node3" -Parent "RackB"
Set-ClusterFaultDomain -Name "Node4" -Parent "RackB"

This explicitly tells the S2D engine that Node1 and Node2 share a physical rack, meaning they share the same top-of-rack switch and power distribution units. If Rack A loses power, S2D knows that Node3 and Node4 in Rack B still contain the necessary data copies to keep the virtual disks online.

Step 4: Verifying the Configuration

To verify that the fault domains have been configured correctly and that the nodes are properly nested, you can use the Get-ClusterFaultDomain cmdlet to view the cluster topology.

Get-ClusterFaultDomain | Format-Table Name, Type, ParentName, ChildrenNames -AutoSize

You can also use the XML representation to visualize the exact tree structure of your cluster’s fault domains:

Get-ClusterFaultDomainXML

Conclusion

Configuring fault domains in Storage Spaces Direct is an essential step for enterprise deployments that span multiple racks or chassis. By accurately mapping your physical hardware topology into the logical cluster configuration using PowerShell, you allow the S2D storage engine to intelligently place data blocks, guaranteeing maximum resiliency against catastrophic hardware failures.

Get the best tech tips delivered straight to your inbox.

Join thousands of readers mastering Apple, Google, Microsoft, and Linux.