Windows Server Failover Cluster 上的 Storage Spaces（共享 SAS JBOD）在 Azure Local 解耦架构中的重新定位。
版本 ：v2.0（2026-07-07，术语统一修订版） 适用 ：Windows Server 2025 / Azure Local 23H2 / 2512 / 2606 来源 ：Microsoft Learn 官方文档（Storage Spaces 概述、Failover Cluster 存储架构、Azure Local 解耦部署、Compare Azure Local to Windows Server azloc-2606）+ 多轮技术校准 核心结论 ：Windows Server 2025 仍完整支持 Storage Spaces（共享 SAS JBOD 部署模式）------即 Storage Pool / Virtual Disk 运行在 Windows Server Failover Cluster 中、通过共享 SAS JBOD enclosure 提供物理磁盘；从 Windows Server 存储体系结构分析，可作为 SOFS 后端的一种实现方式。截至本文写作时，微软公开文档尚未将该组合列为 Azure Local Disaggregated Deployment 的官方参考架构。
0. 写在前面
本文聚焦一个在 Azure Local 解耦（Disaggregated）讨论里被反复忽略的方案：双节点 Windows Server Failover Cluster + Shared SAS JBOD enclosure + Storage Spaces + CSV + SOFS。
准确地说，这里的 Storage Spaces 部署模式是微软从 Windows Server 2012 R2 起主推的"中低端 SAN 软件替代方案"------把 Storage Pool 和 Virtual Disk 放在 Failover Cluster 中跑、底层介质来自多节点共享的 SAS JBOD enclosure。HCL 上曾认证大量该类盘柜（HPE D3000、Dell MD1200、Lenovo D1212 等）。该架构在 2016 / 2019 时代就已经稳定，之后随着 S2D 和 Azure Local 的崛起，微软宣传重心转移，但产品本身从未被弃用（Deprecated）或移除（Removed）。
本文要做三件事：
- 校准 Storage Spaces 与 S2D 的边界------很多人把它们当成一个东西的不同模式，但它们在集群假设、JBOD 形态、网络要求上有本质差异。
- 校准 Windows Server 2025 对 Storage Spaces（共享 SAS JBOD 部署模式）的支持现状------功能、改进、推荐场景。
- 校准这套架构在 Azure Local 解耦体系中的位置------从 Windows Server 存储体系结构分析，该链路能够完整建立；微软公开文档尚未将其列为 Azure Local Disaggregated Deployment 的官方参考架构，生产环境应结合最新支持声明确认。
0.1 术语统一约定（v2.0 修订）
为贴合微软当前 Learn 文档体系，本文统一以下术语：
| 本文用词 | 含义 / 备注 |
|---|---|
| Storage Spaces | 产品名称（不区分单机或集群形态）。第一次出现时用全称"Storage Spaces（共享 SAS JBOD 部署模式）"，后续简称 Storage Spaces。 |
| Storage Spaces（共享 SAS JBOD 部署模式） | Storage Pool / Virtual Disk 运行在 Windows Server Failover Cluster 中、物理磁盘来自多节点共享的 SAS JBOD enclosure 的部署形态。不再使用"经典 Storage Spaces"或"Clustered Storage Spaces"这种社区旧叫法。 |
| Storage Pool | 资源池对象（PowerShell: Get-StoragePool / New-StoragePool）。 |
| Virtual Disk | 逻辑盘对象（PowerShell: Get-VirtualDisk / New-VirtualDisk）。第一次出现用全称"Storage Spaces Virtual Disk（以下简称 Virtual Disk）"，后续简称 Virtual Disk。 |
| Shared SAS JBOD enclosure | 多节点共享的 SAS 盘柜机箱（无 RAID 卡）。首次出现用全称，后续简称 Shared SAS JBOD。 |
| Failover Cluster | Windows Server Failover Cluster（WSFC），即集群组件。 |
| CSV | Cluster Shared Volume（集群共享卷）。 |
| SOFS | Scale-Out File Server（横向扩展文件服务器）。 |
| 软件定义存储（Software-defined Storage） | Storage Spaces 的本质定位。不使用"软件 RAID"------Storage Spaces 采用 Pool / Column / Slab / Resiliency 模型，不是传统 RAID 控制器实现。 |
层级关系（贯穿全文）：
Windows Storage Spaces
├── Storage Pool
├── Virtual Disk
└── Physical Disk1. 核心概念校准
1.1 Storage Spaces 与 S2D：不是替代关系
很多人会把 Storage Spaces （共享 SAS JBOD 部署模式）和 Storage Spaces Direct （存储空间直通）当成"旧 vs 新"。更准确的说法是：两者面向不同的部署形态，关系上是并列，不是替代。
| 维度 | Storage Spaces（共享 SAS JBOD 部署模式） | Storage Spaces Direct (S2D) |
|---|---|---|
| 单机使用 | ✅ 支持 | ❌ 不支持 |
| Shared SAS JBOD | ✅ 支持（典型场景） | ❌ 不支持 |
| 节点本地盘 | ✅ 支持 | ✅ 主要场景 |
| Failover Cluster | 必需（共享 SAS JBOD 场景） | 必需 |
| 典型形态 | 双/多节点 Failover Cluster + SAS JBOD enclosure | HCI / Azure Local |
| 网络要求 | 普通以太 / SAS 即可 | RDMA 几乎必需 |
| CSV | 必需 | 必需 |
| 管理复杂度 | 较低 | 较高（Repair / Rebalance） |
| 微软当前重心 | Sustained Engineering | 持续扩展（Azure Local） |
关键校准 ：微软官方文档明确把这两者分开讲，没有"Storage Spaces 被 S2D 取代"的表述。S2D 是 HCI 时代的产物，Storage Spaces（共享 SAS JBOD 部署模式）是 SAS JBOD 时代的产物，两者并行到 Windows Server 2025。
1.2 "在 Failover Cluster 中使用 Storage Spaces"是什么
在 Windows Server 2012 R2 起，微软提供的能力是：
在 Windows Server Failover Cluster 中，让多节点共享一个 SAS JBOD enclosure（无 RAID 卡），用 Storage Spaces 在 OS 层把物理盘聚合成 Storage Pool，再创建带 Resiliency（Mirror / Parity）的 Virtual Disk，最后用 CSV 把 Virtual Disk 暴露给集群角色（Hyper-V / SOFS / File Server）。
它和单机 Storage Spaces 的差别只有一处：多节点通过 SCSI-3 Persistent Reservations 对 Shared SAS JBOD enclosure 的物理磁盘做仲裁，本质上是个分布式锁。
1.3 Windows Server 2025 的官方支持状态
结论先说：仍然受支持，文档在持续更新（最近一次更新 2025 年）。
依据：
- Storage Spaces 官方文档（azloc-2606 / WS2025） ：明确写出 "Storage Spaces can be used in clusters connected to external JBOD enclosures via SAS"。
- Failover Cluster Storage Architecture 文档：仍保留 SAN / Shared SAS Storage 这一架构分类，未标记为 Legacy 或 Unsupported。
- Storage Pool / Virtual Disk / Mirror / Parity / Storage Tier / Storage Bus Cache / ReFS / 完整 PowerShell cmdlet 在 WS2025 都仍可用。
需要注意的变化：
- 2012 R2～2019：微软大量宣传 Storage Spaces（共享 SAS JBOD 部署模式），HCL 有大量认证 Shared SAS JBOD enclosure。
- 2022～2025：微软几乎不再新增该部署模式的新特性，文档重点转向 Azure Local / S2D / SAN。
- 因此它是 **"Sustained Engineering"（持续支持）**而非 "Active Development"（积极发展）。
2. Windows Server 2025 中 Storage Spaces 的能力
2.1 完整保留的功能
| 功能 | WS2025 状态 | 备注 |
|---|---|---|
| Storage Pool | ✅ | 共享 SAS JBOD / 本地盘 |
| Virtual Disk | ✅ | Simple / Mirror / Parity Resiliency |
| 精简配置（Thin Provisioning） | ✅ | WS2025 持续可用 |
| 固定配置（Fixed Provisioning） | ✅ | |
| 双向 / 三向镜像 | ✅ | 共享 SAS JBOD 场景多见双向 |
| Parity（奇偶校验） | ✅ | |
| Simple（无冗余） | ✅ | 不推荐生产 |
| Storage Tier（SSD + HDD 分层） | ✅ | 配合 Storage Bus Cache |
| Storage Bus Cache | ✅ | |
| ReFS | ✅ | |
| 完整 PowerShell cmdlet | ✅ |
2.2 Windows Server 2025 引入的改进
虽然Storage Spaces（共享 SAS JBOD 部署模式）的架构本身没有大变动，但 WS2025 在底层存储栈上做了一些增强：
- ReFS 去重（Deduplication） --- 此前主要在 NTFS，WS2025 扩展到 ReFS（生产环境需评估对性能的影响）
- ReFS 压缩（Compression） --- 同上
- Storage Replica 压缩 --- 扩展到所有版本（之前部分版本受限）
- NVMe I/O 性能优化 --- 底层 IO 栈更适配 NVMe 设备
- 整体存储栈性能提升 --- 这是版本级红利，不专属 Storage Spaces
- Storage Spaces 支持 Thin Provisioned Virtual Disk（持续可用）
重要校准 ：上述改进大多属于底层存储栈（ReFS、NVMe、Storage Replica），并不意味着 Storage Spaces（共享 SAS JBOD 部署模式）的控制面（Storage Pool / Virtual Disk / Mirror / Parity）发生了什么架构性变化。WS2025 的 Storage Spaces 引擎和 2019 / 2022 时代的形态基本一致。
2.3 Windows Server、S2D、Azure Local三者关系
Azure Local
3. 经典架构：双节点 Failover Cluster + Shared SAS JBOD + Storage Spaces
3.1 架构总览
3.2 关键组件
| 组件 | 角色 | 关键约束 |
|---|---|---|
| Shared SAS JBOD enclosure | 提供物理磁盘 | 不能有 RAID 卡（RAID 卡设计上是单服务器独占） |
| SAS HBA（每节点 1~2 块） | 多路径连接 Shared SAS JBOD | 必须支持 SBB v2.0 或同等规范 |
| Storage Pool | 把物理盘池化 | 一个 cluster 一个 pool（共享 SAS JBOD 场景） |
| Virtual Disk | 跨节点冗余抽象 | 双向镜像（2 节点）/ 三向镜像（3+ 节点） |
| CSV | 把 Virtual Disk 暴露给集群 | NTFS / ReFS 都可 |
| SOFS / Hyper-V / File Server | 集群角色 | 通过 CSV 访问 Virtual Disk |
3.3 仲裁机制（容易踩坑）
Shared SAS JBOD enclosure 上的物理磁盘被多台服务器同时访问，必须用 SCSI-3 Persistent Reservations 做多节点仲裁，否则会出现脑裂式的数据损坏。
- 每次 I/O 写操作前，节点要"先预留再写入"（PR Out / Preempt）。
- Storage Spaces 驱动层负责这件事，应用层无感。
- 因此 SAS HBA 固件、Shared SAS JBOD enclosure 控制器、Storage Spaces 驱动三者必须配合------这也是为什么微软早期要做 HCL 认证。
关键校准 ：不要试图用两台服务器的 RAID 卡共享一个盘柜。RAID 卡设计上是单主机独占，多主机共享需要 HBA + 纯 JBOD enclosure（"Just a Bunch Of Disks"）+ Storage Spaces 在 OS 层做软件定义存储。
3.4 Resiliency 形态选择
注：本文使用微软官方术语 Resiliency （容错策略）而非 "RAID 类型"。Storage Spaces 采用 Pool / Column / Slab / Resiliency 模型，不是传统 RAID 控制器实现。
| 场景 | 推荐 Resiliency | 备注 |
|---|---|---|
| 2 节点 + 共享 SAS JBOD | 双向镜像（Mirror, 2-way） | 默认选项 |
| 3 节点 + 共享 SAS JBOD | 三向镜像 / 双向奇偶 | 容量利用率更高 |
| 容量型归档 | Parity | 性能较低，不推荐用于 VM 存储 |
| 高 IOPS VM | 双向镜像 + SSD 分层 + Storage Bus Cache | Storage Bus Cache 加速读 |
关键校准 ：Parity（奇偶校验）在共享 SAS JBOD 场景下能省容量但写性能损失明显，对 VM 存储不推荐；Mirror 是工业默认 Resiliency。
4. 这套架构现在还有哪些典型场景
4.1 微软目前的推荐定位
按微软公开文档的措辞，Storage Spaces 仍然适合：
- 单台 Hyper-V 主机
- 单台文件服务器
- 小型虚拟化平台
- Shared SAS JBOD enclosure（双/多节点 Failover Cluster）
- SOFS 后端存储
- 作为硬件 RAID 的软件定义存储替代方案
而 S2D 仍然聚焦：
- Azure Local
- HCI（超融合）
- Hyper-V Cluster
- Azure Stack HCI
- 大规模虚拟化
4.2 在私有云 / VDI / 中小企业场景的契合度
| 维度 | 双机 Shared SAS JBOD + Storage Spaces | S2D | FC SAN |
|---|---|---|---|
| 采购成本 | 较低 | 中等 | 高 |
| 运维复杂度 | 较低 | 中等（Repair / Rebalance） | 中等 |
| 网络要求 | 普通以太 / SAS 即可 | RDMA 几乎必需 | FC 专用网络 |
| 扩容方式 | 加盘柜 / 加盘 | 加节点 | 加盘柜 / 加 LUN |
| 故障域 | 盘柜 + 节点 | 节点 | 控制器 / 链路 |
| 与 SOFS 配合 | 经典（2012 R2 起主推） | 可（内部 SOFS） | 经典 |
典型适配场景：
- 2 节点 Hyper-V Cluster
- SOFS 文件服务器
- SMB3 多通道存储
- VDI（FSLogix Profile 存储后端）
- 中小企业私有云
- 不希望采购 FC SAN 的场景
4.3 与 S2D 的本质差异
- S2D 的镜像靠节点间 SMB3 + RDMA 同步，本地盘；
- Storage Spaces（共享 SAS JBOD 部署模式）的镜像靠 SAS 多路径 + Storage Spaces 驱动层，Shared SAS JBOD enclosure 是介质池；
- 前者是"节点本地 + 网络同步"，后者是"共享介质 + 软件锁 + 软件定义存储"。
两者不互相替代 ：共享 SAS JBOD 场景没法 用 S2D（因为 S2D 不支持外部 Shared SAS JBOD）；节点本地盘场景也不必要用 Storage Spaces（直接 S2D 更优）。
5. 关键命题：在 Azure Local 解耦架构中，SOFS 后端能否用 Storage Spaces（共享 SAS JBOD 部署模式）
5.1 Azure Local 解耦架构的存储栈
Azure Local 的 Disaggregated（解耦）模式，本质上分层是：
5.2 Compute 层的视角
Azure Local Compute 节点通过 SMB3 访问 SOFS 提供的共享，而不是直接访问 SOFS 后端块存储。从 SMB 文件访问层面，Compute 节点通常无需感知 SOFS 后端采用的是 FC SAN、Storage Spaces 还是其他 Windows Server 支持的共享存储实现。
- 从 SMB 文件访问层面，Compute 节点通常无需感知 SOFS 后端的具体块存储实现。
- 整个 SOFS 集群 + CSV 层对 Compute 来说就是个"挂载点"。
- 因此从存储栈角度 ，SOFS 后端使用 Storage Spaces（共享 SAS JBOD 部署模式）与使用 FC SAN 没有本质区别------计算节点 I/O 路径完全一致。
5.3 Windows Server 层面的支持状态
逐项检查 WS2025 组件是否受支持：
| 组件 | WS2025 支持状态 | 备注 |
|---|---|---|
| Windows Server Failover Cluster | ✅ | 基础组件 |
| Storage Spaces（共享 SAS JBOD 部署模式） | ✅ | 见本文第 1.3 节 |
| Shared SAS JBOD enclosure | ✅ | HBA + SBB v2.0 认证盘柜 |
| CSV | ✅ | NTFS / ReFS |
| SOFS | ✅ | 经典（2012 R2 起） |
| SMB3 + Multichannel | ✅ | |
| SOFS 通过 SMB3 提供给 Azure Local | ✅ | 这是 SOFS 的标准用法 |
结论：所有组件在 Windows Server 2025 都是受支持功能。
5.4 Azure Local 官方文档为何很少讨论 Storage Spaces（共享 SAS JBOD 模式）
在 Azure Local 解耦（Disaggregated）部署相关文档中，微软通常将共享存储描述为 External Storage，例如：
Disaggregated deployment supports external storage such as FC SAN、iSCSI SAN、NVMe-oF。
官方文档主要关注的是 Azure Local Compute 节点如何访问外部共享存储，而不是共享存储内部采用何种实现方式。
从体系结构来看，需要区分两个不同层次：
第一层：Azure Local Compute 与共享存储之间的接口
Azure Local Compute 节点通过 SMB3 访问 SOFS 提供的共享存储。对于 Azure Local 而言，关注的是共享存储是否能够提供符合要求的 SMB 文件共享，而不是 SOFS 后端具体采用哪一种块存储实现。
第二层：SOFS 集群内部的共享块存储实现
SOFS 后端可以基于 Windows Server 官方支持的多种共享块存储方案，例如：
- FC SAN
- iSCSI SAN
- NVMe-oF
- Windows Server Failover Cluster + Storage Spaces（共享 SAS JBOD 部署模式）
这些属于 Windows Server 存储体系结构内部的实现方式，并不属于 Azure Local 控制平面重点讨论的内容。
因此，Azure Local 官方文档主要列举的是外部共享存储类型，而没有进一步展开 SOFS 后端采用何种块存储实现。
需要注意的是，微软目前公开发布的 Azure Local 文档及官方支持矩阵主要展示 FC SAN、iSCSI SAN、NVMe-oF 等方案，并未明确将 SOFS 后端采用 Storage Spaces（共享 SAS JBOD 部署模式）列为 Azure Local 解耦部署的官方参考架构。
因此，官方文档未展开介绍，并不能直接推导为支持或不支持；对于此类组合架构，应以 Azure Local 最新官方支持矩阵和 Microsoft Support 的正式声明作为最终依据。
5.5 关键技术链路校验
把链路完整画一遍：
每一层在 Windows Server 2025 都是受支持功能 。从 Windows 存储栈角度，这条链路是完全闭合的。
5.6 Azure Local 官方支持矩阵的现状
这是唯一一个需要谨慎的地方。
| 维度 | 状态 |
|---|---|
| Windows Server 2025 各组件单独支持 | ✅ 全部支持 |
| Windows Server Failover Cluster + Storage Spaces（共享 SAS JBOD） | ✅ 官方支持 |
| Azure Local解耦架构技术链路 | ✅ 从 Windows Server 存储体系结构分析，可以构建完整的数据访问链路。 |
| Azure Local（S2D）使用共享SAS JBOD | ❌ 官方明确不支持 |
| Azure Local 文档示例列出 | ⚠️ 主要展示FC SAN、ISCSI SAN、NVME-oF等外部共享存储 |
| Azure Local 官方支持矩阵 | ⚠️ 截至目前未明确将 SOFS 后端 + Storage Spaces + Shared SAS JBOD enclosure 列为解耦部署的受支持配置 |
精确表述：
从 Windows Server 存储架构分析，SOFS 后端采用 Shared SAS JBOD enclosure + Storage Spaces（共享 SAS JBOD 部署模式），其 Compute 层 I/O 路径与采用 FC SAN、iSCSI SAN 等共享存储方案一致，可以构建完整的数据访问链路。
需要注意的是，Azure Local（23H2 及以后版本）的 Storage Spaces Direct（S2D）部署明确要求存储设备本地连接，不支持多个节点共享同一 SAS JBOD enclosure。本文讨论的是 Azure Local Disaggregated（解耦）部署，其中 Shared SAS JBOD 与 Storage Spaces 部署于独立 Windows Server SOFS 集群，而非 Azure Local 集群自身，因此属于不同的架构场景。
截至本文写作时，微软公开发布的 Azure Local 文档及官方支持矩阵主要展示 FC SAN、iSCSI SAN、NVMe-oF 等外部共享存储方案，微软目前公开发布的 Azure Local 文档及 Azure Local Support Matrix 中，尚未将"SOFS 后端采用 Windows Server Storage Spaces（共享 SAS JBOD 部署模式）"列为 Azure Local Disaggregated Deployment 的官方参考架构或支持配置。因此，如计划用于生产环境，建议结合最新 Microsoft Learn、Azure Local Support Matrix 以及微软官方支持意见进行确认。
6. 工业部署视角
6.1 选 Storage Spaces（共享 SAS JBOD 部署模式）的真实理由
抛开"是否官方支持"的谨慎措辞，在合适的场景下，这套架构的工程价值是真实的：
- 成本远低于 FC SAN------双机 Shared SAS JBOD 的采购成本大约是 FC SAN 的 1/3 到 1/5（按容量比）。
- 运维复杂度低于 S2D------没有 Repair Job、Rebalance、SMB3 RDMA 这些复杂机制，Storage Spaces 本身的故障域是清晰的。
- Shared SAS JBOD enclosure 扩容简单------加盘柜、加盘都可以，Storage Pool 自动识别。
- 网络要求低------不需要 RDMA、不依赖 East-West 高速存储流量，普通的 10GbE 上行就够了。
- HA 形态简单------双节点 Failover Cluster + File Share Witness 即可，不需要复杂的 Storage 见证盘。
- 与 Azure Local 解耦的契合度 ------Sustained Engineering 状态的产品反而更稳定，少有破坏性变更。
6.2 不适合这套架构的场景
- 大规模 HCI（>4 节点）------S2D 更合适。
- 极致 IOPS 需求（百万级）------S2D + NVMe 极限性能更强，共享 SAS 通道有瓶颈。
- 多租户复杂隔离------SAN 的 LUN 隔离 + Zoning 更适合。
- 已经在用 FC SAN 的环境------没必要拆掉。
6.3 Azure Local 解耦的真实价值
需要清醒认识到：Azure Local 解耦的核心价值在控制平面（Arc / ARM / Policy / Monitor） ，而不在共享存储后端。
后端用 FC SAN、iSCSI SAN、还是 Shared SAS JBOD enclosure + Storage Spaces，对 Azure Local Compute 来说没有区别------重要的是：
- 控制平面统一在云
- 集群治理统一
- 更新策略统一
- 监控 / Policy 统一
从这个角度，"SOFS 后端用 Storage Spaces（共享 SAS JBOD 部署模式）" 不会让 Azure Local 解耦失去任何东西，也不会让它多得到什么 ------它就是一个可行但不显眼的后端选项。
7. 部署清单（参考）
⚠️ 本节是架构层面的实施清单 ，不替代官方详细部署步骤。微软已经不在 Windows Server 2025 时代维护 2012 R2 时代那篇 Deploy Clustered Storage Spaces 详细教程，部署时需结合 Windows Server 2025 官方文档自行梳理。
7.1 前置条件
- 2 节点服务器（生产建议硬件一致）
- 每节点至少 1 块 SAS HBA（生产建议双 HBA 做多路径）
- Shared SAS JBOD enclosure（SBB v2.0 认证或同等规范）
- JBOD 控制器固件 / HBA 固件 / Storage Spaces 驱动三者版本匹配
- SAS 多路径确认
- Windows Server Failover Cluster 仲裁配置（File Share Witness 或 Disk Witness）
7.2 集群与存储
- 安装 Windows Server 2025
- 安装 Failover Cluster 角色
- 验证 Cluster 验证报告
- 启用 MPIO（多路径）
- 在两节点都能看到 Shared SAS JBOD enclosure 的物理磁盘
- 创建 Storage Pool（
New-StoragePool） - 创建 Virtual Disk（
New-VirtualDisk，Mirror / Parity Resiliency） - 分区 + 格式化（ReFS 建议）
- 加入 CSV（
Add-ClusterSharedVolume）
7.3 SOFS / Hyper-V 角色
- 安装 Scale-Out File Server 角色 / Hyper-V 角色
- 在 SOFS 上创建 SMB Share
- （Azure Local 解耦场景）把 SOFS 加入 Azure Arc
- （Azure Local 解耦场景）在 Azure Local Compute 上
\\SOFS\Share挂载并验证
7.4 验证
- Failover 测试：手动 failover 一节点，验证 CSV 切换、SOFS 不中断
- 路径测试：拔掉一根 SAS 线，验证多路径切换
- 性能基线：DiskSpd / VMFleet 跑基线
- Azure Local 解耦场景：模拟一个 SOFS 节点 down，验证 SMB3 Multichannel 切换
8. 与其他方案的对比
8.1 决策矩阵
| 维度 | Storage Spaces + Shared SAS JBOD | S2D | FC SAN | iSCSI SAN |
|---|---|---|---|---|
| 采购成本 | 较低 | 中 | 高 | 中 |
| 性能上限 | 中 | 高 | 高 | 中 |
| 运维复杂度 | 较低 | 中 | 中 | 中 |
| 网络要求 | SAS / 普通以太 | RDMA | FC | 普通以太 |
| 与 Azure Local 解耦契合 | ⚠️ 官方未列示例 | ✅ 主流 | ✅ 官方示例 | ✅ 官方示例 |
| 微软宣传重点 | ❌ 2019 后少 | ✅ Azure Local | ✅ Azure Local Ready | ⚠️ 一般 |
| 工业稳定性 | ✅ Sustained | ✅ 持续演进 | ✅ 成熟 | ✅ 成熟 |
8.2 选型建议
- 成本敏感 + 中小规模 + 不希望用 FC → Storage Spaces（共享 SAS JBOD 部署模式）是合理选项
- 大规模 HCI / 极致性能 / 需要 RDMA → S2D / Azure Local 节点本地盘
- 已有 FC SAN 资产 / 强 LUN 隔离 / 多租户 → FC SAN
- 已经采购 iSCSI SAN / 统一存储 → iSCSI SAN
9. 总结
一句话总结：
Windows Server 2025 仍完整支持 Storage Spaces（共享 SAS JBOD 部署模式）------即 Storage Pool / Virtual Disk 运行在 Windows Server Failover Cluster 中、物理磁盘来自 Shared SAS JBOD enclosure；从 Windows 存储栈看，它完全可以作为 Azure Local 解耦架构中 SOFS 后端的共享块存储来源之一，但 Azure Local 官方文档目前未明确将其列入解耦部署的官方示例或支持矩阵项。
逐条结论：
- ✅ Windows Server 2025 仍然支持 Storage Spaces（共享 SAS JBOD 部署模式）------架构没变，文档在更新，PowerShell cmdlet 完整可用。
- ✅ 仍然支持在 Failover Cluster 中跑 Storage Spaces + Shared SAS JBOD enclosure------功能完整，未被弃用，未被移除。
- ✅ Windows Server 2025 引入的存储改进（ReFS dedup/compression、NVMe IO、Storage Replica 压缩）属于底层存储栈------不意味着 Storage Spaces 架构发生变化。
- ✅ 从 Windows Server 存储栈看，SOFS 后端使用 Storage Spaces（共享 SAS JBOD 部署模式）与使用 FC SAN 在 Compute 层没有区别------链路完全闭合。
- ⚠️ Azure Local 官方文档目前主要展示 SAN 方案------未明确将 Storage Spaces（共享 SAS JBOD 部署模式）列为解耦部署的官方示例或支持矩阵项。
- ⚠️ 生产环境部署前应结合最新的官方支持声明确认------技术可行 ≠ 官方认证支持。
研究建议：
- 如果你的目标是打造基于 Hyper-V 的私有云（类似 vSphere） ，双节点 Failover Cluster + Shared SAS JBOD enclosure + Storage Spaces + CSV + SOFS 这套经典架构是值得深入研究的方向。
- 它在成本、稳定性和运维复杂度之间取得了很好的平衡。
- 与 Azure Local 的解耦（Disaggregated）理念比较契合 ------只是微软近几年宣传重点已经转向 Azure Local 和 S2D，而不是停止支持这套架构。
- 写架构分析或技术文章时 ，建议按 5.6 节"精确表述"措辞来写结论，既符合当前公开文档，也避免把技术可行性直接等同于官方认证支持。
10. 为什么微软越来越少提 Storage Spaces（共享 SAS JBOD）
这是大家最关心的问题。
结论先说 ：不是因为 Deprecated，而是产品定位变化。
| 时期 | 微软主推方向 | Storage Spaces（共享 SAS JBOD）的位置 |
|---|---|---|
| 2012 R2 | 对标 Dell MD、HP MSA、IBM DS 等中低端硬件 SAN | 微软主推的"软件定义存储替代方案" |
| 2016 | 推出 Storage Spaces Direct (S2D) | 宣传重心从 Storage Spaces → S2D |
| 2019 | Azure Stack HCI | 集群场景主推 Azure Stack HCI（S2D 的产品化） |
| 2023～ | Azure Local（S2D 的云控平面重塑） | 集群场景主推 Azure Local |
关键校准：
- 不是因为：Deprecated（弃用）。
- 而是：产品定位变化------微软公开文档和产品定位的重点逐步转向 S2D 与 Azure Local。
因此 Storage Spaces（共享 SAS JBOD 部署模式）进入：
- Maintenance / Sustained Engineering（持续支持模式）
- 不再扩展新特性
- 文档更新频率下降
- HCL 新增认证的 Shared SAS JBOD enclosure 减少
但是：
- ✅ 产品没有删除------Windows Server 2025 文档仍然列出该部署模式。
- ✅ 功能完整可用------Storage Pool / Virtual Disk / Mirror / Parity / CSV / SOFS 全套链路正常。
- ✅ PowerShell cmdlet 仍然支持 ------
New-StoragePool/New-VirtualDisk/Add-ClusterSharedVolume都还在。 - ✅ Failover Cluster 文档没有标记为 Legacy。
对工程师的含义：
微软把 Storage Spaces（共享 SAS JBOD 部署模式）从"主推位"挪到"持续支持位"------这意味着它在工业场景里反而比新东西更稳定：
- 没有破坏性变更
- 没有频繁的架构调整
- 没有与新产品绑定的强制升级
- 适合"装好就跑十年"的中坚场景
这也是为什么中小企业私有云、VDI、SOFS 后端这些场景，Storage Spaces（共享 SAS JBOD 部署模式）在 2026 年仍然是合理选项------不是因为它"新"，而是因为它"稳"。
附录 A：关键文档参考
- Microsoft Learn --- Storage Spaces overview（WS2025 / azloc-2606）
- Microsoft Learn --- Failover Cluster storage architecture（WS2025 / azloc-2606）
- Microsoft Learn --- Azure Local disaggregated deployment（azloc-2606）
- Microsoft Learn --- Compare Azure Local to Windows Server（azloc-2606）
- Microsoft Learn --- Scale-Out File Server overview（WS2025）
- Microsoft Learn --- ReFS deduplication and compression（WS2025）
附录 B：术语表
| 术语 | 含义 |
|---|---|
| Storage Spaces | 产品名称（不区分单机或集群形态） |
| Storage Spaces（共享 SAS JBOD 部署模式） | Storage Pool / Virtual Disk 运行在 Failover Cluster 中、物理磁盘来自 Shared SAS JBOD enclosure 的部署形态 |
| Storage Pool | 资源池对象（Get-StoragePool / New-StoragePool） |
| Virtual Disk | 逻辑盘对象（Get-VirtualDisk / New-VirtualDisk） |
| Storage Spaces Direct (S2D) | 存储空间直通，HCI / Azure Local 场景，节点本地盘 |
| Shared SAS JBOD enclosure | 多节点共享的 SAS 盘柜机箱（无 RAID 卡）。本文简称 Shared SAS JBOD |
| CSV | Cluster Shared Volume，集群共享卷 |
| SOFS | Scale-Out File Server，横向扩展文件服务器 |
| SBB | Storage Bridge Bay，JBOD 行业规范 |
| SCSI-3 PR | SCSI-3 Persistent Reservations，多节点磁盘仲裁机制 |
| HCL | Hardware Compatibility List，硬件兼容列表 |
| Resiliency | Storage Spaces 容错策略术语（Mirror / Parity 等），不是传统 RAID |
| 软件定义存储（Software-defined Storage） | Storage Spaces 的本质定位 |
| Disaggregated (Azure Local) | 解耦部署，控制平面在云、计算 / 存储本地 |