Summary

  • 3 minutes

In this module, you explored how Azure Local provides storage through Storage Spaces Direct, qualified external arrays, and supported combinations of both. You traced the layers from physical capacity to workload placement and distinguished hyperconverged, disaggregated, and rack-aware configurations. You learned why local-drive protection, array protection, filesystems, and deployment limits must be evaluated within the selected architecture rather than combined across different support models.

You compared mirroring, parity, and nested resiliency, balancing fault protection against capacity efficiency and performance. You calculated a workload budget by separating physical footprint from logical capacity and accounting for overhead, infrastructure, growth, and repair reserve. You also identified why guest free space and expected deduplication savings can't substitute for usable physical headroom.

You examined how failure domains, redundant access paths, cluster quorum, pool quorum, and witnesses contribute to availability. A witness helps arbitrate cluster ownership, but it doesn't supply missing workload data. Even when storage remains accessible, VM placement, surviving compute capacity, and application recovery determine whether service can resume. Hyperconverged rack-aware requirements remain distinct from those of the disaggregated rack-aware SAN preview.

You distinguished hardware availability from data integrity, including the limits of ReFS file-data checksums and redundant copies. You used continuous monitoring and a failure-scenario matrix to identify reduced protection, missing evidence, and recovery milestones. You also separated storage repair, resynchronization, and rebalancing from restoring data to a known-good application state.

Finally, you reviewed volume lifecycle requirements and ReFS deduplication, recognizing that maintenance must preserve supported configurations and resources needed for recovery. For the manufacturing scenario, a successful design must retain authoritative ownership, accessible data, and sufficient resources after the specified rack failure, then demonstrate application recovery. Returning hardware to service isn't sufficient until the required storage protection is restored. Independent recovery points and a usable recovery location remain necessary for failures and unwanted changes that live storage replicas don't protect against.

More info