The Storage Spaces Direct Explorer is an interactive modeling platform for planning and reasoning about Azure Local and Windows Server S2D clusters. It unifies two complementary disciplines on a shared configuration model: Capacity Planning quantifies how raw media translates into usable workload capacity after metadata, repair reserves, resiliency overhead, and system volumes, while the Resiliency Simulator demonstrates how cluster quorum, pool quorum, slab placement, and CSV ownership determine whether workloads remain available through node and drive failures. Every module draws from the same Scenario Builder, so cluster assumptions stay consistent across capacity, resiliency, and volume planning. It is intended as a design-time education and pre-sales tool, not a substitute for validated product sizing.
Scenario Builder
Single source of truth for cluster configuration and capacity assumptions. Failure injection and recovery controls live in the Resiliency Simulator.
Mirror-accelerated parity and dual parity require 4+ nodes. Dual-parity efficiency follows the Microsoft fault-domain summary tiers.
ARB / MOC / AKS appliance volume.
Time-series health database.
Capacity Planning. Size storage, analyze efficiency, and drive Azure Local sizing, presales, and ROI conversations. Raw capacity is reduced by metadata, the S2D repair reserve, resiliency overhead, the Azure Local Infrastructure Volume, and Cluster Performance History to reach workload capacity.
Total drives
32
Across the cluster
Raw capacity
61.44 TB / 55.88 TiB
Before resiliency overhead
Usable workload capacity
26.58 TB / 24.17 TiB
After reserves + resiliency
Fault domains
4
One domain per node
Live topology view
Cluster topology
Healthy layout
Sizing view
Capacity impact
43% workload-ready
Raw capacity61.44 TB
Total media across all drives.
Storage Spaces metadata0.61 TB
Estimated pool and filesystem metadata.
S2D repair reserve7.68 TB
One drive per node held for repair.
Resiliency overhead26.88 TB
Used by mirror copies or parity.
Azure Local Infrastructure Volume0.27 TB
ARB / MOC / AKS appliance reserve.
Cluster Performance History0.02 TB
Time-series health database.
Workload capacity26.58 TB
After every reserve and resiliency.
Planned user volumes21.26 TB
Targeted user-volume occupancy of usable workload capacity.
Unallocated headroom5.32 TB
Remaining usable capacity below the planning target.
Raw capacityTotal media across all drives.61.44 TB
MetadataPool and filesystem metadata.0.61 TB
S2D repair reserveOne drive per node.7.68 TB
Resiliency overheadMirror copies or parity.26.88 TB
Azure Local reservesInfrastructure + performance history.0.30 TB
Workload capacityAfter reserves and resiliency.26.58 TB
Copies / encoding2×
Raw / node15.36 TB
Storage efficiency43%
!
Planning note: Directional model. Validate usable capacity against the selected release and hardware.
User volume planning
Align volumes to ownership and usable capacity
Aligned to nodes
A common planning pattern is one user volume per node so the volume count aligns with the cluster’s owner distribution. The target controls how much of usable workload capacity is assigned to user volumes, preserving the remaining percentage as headroom.
116
Recommended: 4 volumes for 4 node owners.
70%100%
The balance remains as unallocated planning headroom.
Planned user capacity21.26 TB
Per-volume capacity5.32 TB
Remaining headroom5.32 TB
Equal-sized planning model. Volume 01 maps to Node 01, Volume 02 to Node 02, and so on.
Resiliency Simulator. An educational view of why data stays available. Cluster quorum, pool quorum, volume resiliency, slab copies, CSV ownership, VM availability, rebuild, and rebalance are kept deliberately distinct — the answer to the core question is derived from all of them.
Resiliency scenario
Inject a failure and choose recovery
Simulator controls
These controls are intentionally separate from the shared cluster configuration. They change the failure path, quorum outcomes, slab survival, and VM-accessibility decision without changing the capacity model. Use Node + drive failure to model one failed node plus a drive fault on a different surviving node.
Combined-fault example: one node fails, then one drive on a surviving node fails. In a 3-node cluster, 3-way mirror can retain a replica while 2-way mirror can lose data.
?
Can the VM still run?
YES — VM remains accessible
No failure injected. All modeled paths available.
Dependency chain
How availability is derived
All healthy
State propagates downward. A break at any layer changes everything below it.
VM accessibility
Decision engine
Output
VM Accessible
Reason
Failure impact trace
Follow the failure, step by step
No failure
Slab placement explorer
What data exists where, and which copies survive
Protected
Every volume uses the same fixed Node 01…Node N columns, so you can see the distribution rather than only a list of surviving replicas. A VM remains accessible only when every slab has a readable copy and cluster/pool quorum remain online; one lost slab is enough to stop the VHDX.
surviving copy lost copy parity fragment
CSV ownership simulator
CSV ownership ≠ data placement
Stable
The CSV owner (coordinator) is a logical role for metadata coordination. It can move on failover without moving a single byte of data. Ownership is independent of where slab replicas physically live.
Key point: Coordinator redirection reroutes metadata I/O only. Data remains on its existing slab replicas regardless of which node owns the volume.
Rebuild simulator
Rebuild = restore protection
Idle
Rebuild recreates the missing copies on surviving (or replacement) nodes so every slab is fully protected again.
Before failureAfter failureAfter rebuild
Data to rebuild0.00 TB
Estimated slabs0
Protection statusProtected
Rebalance simulator
Rebalance = redistribute placement
Idle
Rebalance evens out slab distribution across nodes (e.g., after adding capacity). It does not restore lost protection — that is rebuild's job.
Current distributionAfter rebalance
Rebuild vs rebalance: rebuild restores redundancy after a fault; rebalance optimizes placement for even utilization. They are separate operations with separate triggers.
Future modules. The platform is built on a shared configuration model and a module registry, so new simulators plug into the same Scenario Builder without redesigning the application.
Planned
AVD Workload Simulator
Model Azure Virtual Desktop session hosts, profile storage, and IOPS against the shared cluster.
Planned
SQL Workload Simulator
Size SQL Server data/log placement, latency sensitivity, and resiliency for database workloads.
Planned
AKS Storage Simulator
Persistent volume sizing and resiliency for AKS on Azure Local.
Planned
Storage Performance Simulator
Model cache tiers, IOPS, and throughput ceilings across the topology.
Planned
Dell AX Sizer Extensions
Map the scenario to validated Dell AX node models and supported drive counts.
Future-ready architecture: each module registers with Explorer.registerModule(id, api) and subscribes to state via Explorer.subscribe(fn). Adding a module means adding a tab, a panel, and a subscriber — the Scenario Builder stays the single source of truth.
Important: This platform is a discussion and learning model. Quorum, placement, ownership, rebuild, rebalance, capacity, and performance behavior must be validated against the intended product release, topology, workload, and tested configuration.
Directional model only — not a product quote, validated bill of materials, or deployment design.