Azure Stack Hub 存储服务：从 S2D 物理栈到租户服务全景（上篇）

未经同意，请勿转载！

本篇定位 ：本文以 Azure Stack Hub 存储服务为主线 ------ 从底层物理存储栈（S2D / 三路镜像 / 冗余），到 Azure Stack Hub 存储抽象层，再到租户可用的 IaaS 存储与 PaaS 存储服务全景，完整呈现"管理员在基础设施侧看到的存储"和"租户在工作负载侧看到的存储"是如何叠合的。

版本基础 ：本文基于 azs-1901 至当前主流 azs 版本 （具体覆盖 azs-1901 / 2002 / 2005 / 2102 / 2206 / 2301 / 2405 / 2503 等版本）的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统以及不同 azs 版本之间可能存在差异 ，当版本与本文表述不一致时，以当期版本 Azure Stack Hub Operator 文档为准。

修订说明：

本篇为 Azure Stack Hub 存储服务介绍的新章首发，基于材料（内训课程 - "Azure Stack Hub 存储服务"）整理，按文档编写准则做工程化改写。

[存储服务全景：与 Azure 一致的 IaaS + PaaS 存储](#存储服务全景：与 Azure 一致的 IaaS + PaaS 存储)
[物理存储栈：S2D + Software Storage Bus + CSVFS + ReFS](#物理存储栈：S2D + Software Storage Bus + CSVFS + ReFS)
[内置缓存：Software Storage Bus 的性能加速层](#内置缓存：Software Storage Bus 的性能加速层)
[三路镜像：Azure Stack Hub 存储冗余策略](#三路镜像：Azure Stack Hub 存储冗余策略)
副本分布：跨节点三副本写入的物理视角
[缩放单元冗余：PDU / 交换机 / 服务器 / 磁盘四层叠加](#缩放单元冗余：PDU / 交换机 / 服务器 / 磁盘四层叠加)
[IaaS 存储：虚拟机磁盘与对象存储基础](#IaaS 存储：虚拟机磁盘与对象存储基础)
[PaaS 存储：Blob / Table / Queue 三件套](#PaaS 存储：Blob / Table / Queue 三件套)
租户视角：存储账户是工作负载侧的入口
管理员视角：存储卷是基础设施侧的资源单位
运维红线：哪些能改、哪些不能改
上篇小结

1. 存储服务全景：与 Azure 一致的 IaaS + PaaS 存储

Azure Stack Hub 的存储服务从设计目标上就是 "让私有云与 Azure 公有云在存储语义上对齐" ------租户在 Azure Stack Hub 上调用 Blob / Table / Queue API，与在 Azure 公有云上调用同一组 API，接口行为、错误码、SDK 调用方式高度一致 。这是 Azure Stack Hub 区别于"纯本地虚拟化平台"的根本特征：不是"能跑虚拟机"，而是"能跑 Azure 风格的存储服务"。

1.1 五大核心定位

存储服务五大价值主张，按"对租户的价值"和"对管理员的价值"两个维度拆解：

定位维度	含义	对谁重要
与 Azure 一致的 Blob / Table / 存储账户	同一套 REST API、同一套 SDK、同一套语义	租户（业务开发）
全面的私有云可管理性	通过 Azure 风格的门户 / API / PowerShell 完成所有管理动作	管理员
可部署在企业私有云或服务提供商托管的公共云中	部署模式灵活，运营商可选	决策者 / 架构师
同时提供 IaaS 存储和 PaaS 存储	不只是"给 VM 用的块存储"，还包含 Blob / Table / Queue	业务开发
基于标准硬件的高可靠 / 高弹性 / 高可扩展	标准化硬件 + OEM 集成系统认证	决策者 / 架构师

1.2 服务对象全景图

Azure Stack Hub 存储服务覆盖两大类用户：

复制代码

                  Azure Stack Hub 存储服务
                         │
        ┌────────────────┴────────────────┐
        │                                  │
    For Tenant                          For Administrator
        │                                  │
  ┌─────┴─────┐                       ┌─────┴─────┐
  │           │                       │           │
 IaaS 存储  PaaS 存储              物理存储    存储抽象
 (VM 磁盘)  (Blob/Table/Queue)        (S2D)       (Storage 账户)

关键设计取舍 ：Azure Stack Hub 存储服务不引入 Azure 公有云的 GRS / ZRS / LRS 区分 。这是一个常被误读的差异点 ------ Azure Stack Hub 是本地部署的集成系统，"区域"和"可用区"概念在这里不直接对应；存储数据默认就是 Scale Unit 内的三副本高可用，跨数据中心 / 跨地域的复制由运营商自行决定方案（典型做法是使用外部备份 / 异步复制工具）。

1.3 与 Azure 公有云的存储差异点（关键速查）

Azure Stack Hub 存储不是 Azure 公有云存储的 1:1 镜像。下面这些差异点在实际迁移和开发中需要特别注意：

差异点	Azure Stack Hub	Azure 公有云
复制策略	Scale Unit 内三路镜像（强制，不可关闭）	LRS / ZRS / GRS（按 SKU 选择）
存储账户类型	通用 v1 / v2（部分 SKU 不全）	通用 v1 / v2 / BlobStorage / BlockBlobStorage
托管磁盘加密	BitLocker 128-bit AES（自 1808 起托管磁盘的默认加密方式）	SSE / ADE（多套加密选项）
托管磁盘上限	M30（1023 GiB）	P80（32 TiB）/ E80（32 TiB）
Premium SSD 性能保证	上限值（2300 IOPs / 145 MB/s 单盘 cap）	按 SKU 分级保证
跨地域复制	不直接支持（运营商需自建）	GRS / RA-GRS 内建
冷 / 归档层	不支持	Cool / Archive 内建

避免迁移误判 ：从 Azure 公有云迁回 Azure Stack Hub 的工作负载，不能假设存储性能线性对应 。Azure Stack Hub 的 Premium SSD 是 cap 而不是 provisioned ------ 实际可达性能取决于硬件和工作负载，微软未给出固定保证数字。
L0 版本事实 ：上述差异点随 azs 版本演进可能变化。当前版本下表所列差异均成立 ，但版本升级后部分项可能补齐（如新的存储账户 SKU、新的磁盘类型）。本文表述以当期 azs 版本为准。

2. 物理存储栈：S2D + Software Storage Bus + CSVFS + ReFS

Azure Stack Hub 存储的底层是 Windows Server 2019 / 2022 + Storage Spaces Direct (S2D) 提供的超融合存储。在 Scale Unit 内的每个物理节点上，本地磁盘通过 S2D 聚合成共享存储池，再向上提供虚拟磁盘 / 文件系统。

2.1 存储栈五层结构

PPT 给出的存储栈是清晰的五层抽象，从下到上依次为：

复制代码

┌───────────────────────────────────────────┐
│  虚拟磁盘层（Storage Spaces Virtual Disks） │
├───────────────────────────────────────────┤
│  存储池层（Storage Spaces Storage Pool）    │
├───────────────────────────────────────────┤
│  软件存储总线（Software Storage Bus）       │ ← 内置缓存在这里
├───────────────────────────────────────────┤
│  CSVFS 集群文件系统                         │
├───────────────────────────────────────────┤
│  ReFS 磁盘文件系统                         │
├───────────────────────────────────────────┤
│  物理磁盘（SATA / SAS / NVMe 混合）         │
└───────────────────────────────────────────┘
         ↑
     虚拟机 / 存储账户后端

每一层的职责：

层	职责
物理磁盘	Scale Unit 内每个节点的本地磁盘，可选 SATA / SAS / NVMe 三类（OEM 集成系统从三类中最多选择两类，全闪或混合部署）
ReFS 磁盘文件系统	单磁盘上的文件系统，负责扇区到文件的映射
CSVFS 集群文件系统	把多节点的 ReFS 卷聚合成一个集群可见的文件系统命名空间
Software Storage Bus	软件定义的总线层，内嵌缓存机制（详见 §3）
Storage Pool + Virtual Disks	把多块物理盘聚合成共享存储池，再划分为多个虚拟磁盘

2.2 与 Windows Server S2D 的关系（关键澄清）

L1 微软硬要求

Azure Stack Hub 使用 Windows Server S2D 引擎，但配置策略与 Windows Server 自建 S2D 集群有显著差异。最容易踩的坑是把 Windows Server S2D 的运维经验直接套用到 Azure Stack Hub 上：

维度	Azure Stack Hub	Windows Server 自建 S2D
部署方式	OEM 集成系统出厂配置	手动部署
配置可见性	多数配置项对租户 / 管理员不暴露	完全可配置
三路镜像	强制三路镜像，不可改	可配置（双向 / 三向 / 奇偶校验）
存储池创建	OEM 部署时已固化	手动创建
缓存策略	OEM 根据硬件类型自动配置	完全可调

关键边界 ：Azure Stack Hub 存储池的创建、修改、扩展动作不由运营商执行 ------这些是 OEM 集成系统出厂验证的一部分。运营商能做的存储管理动作是容量监控 / 配额调整 / 告警处理 / 卷间迁移 / 保留期配置等运维层操作。

2.3 物理磁盘类型与部署模式

Azure Stack Hub 物理机支持的磁盘类型组合（最多两类）：

部署模式	磁盘组合	性能特征	典型场景
全 NVMe	NVMe（容量 + 缓存均 NVMe）	最高性能	高 IOPS 工作负载
全 SSD	SSD（容量 + 缓存均 SSD）	高性能	高 IOPS 中等容量
NVMe + SSD 混合	NVMe（缓存） + SSD（容量）	高性能高容量	平衡性能与容量
NVMe + HDD 混合	NVMe（缓存） + HDD（容量）	中等性能大容量	容量优先
SSD + HDD 混合	SSD（缓存） + HDD（容量）	中等性能大容量	容量优先

L2 OEM 实现 ：磁盘类型组合的具体规格（每节点盘数、单盘容量、缓存配置比例）由 OEM 集成系统 Support Matrix 决定。微软不强制每节点多少盘，运营商也不应自行增删磁盘。

3. 内置缓存：Software Storage Bus 的性能加速层

PPT 把"内置缓存"放在 Software Storage Bus 之上是有意为之 ------ 缓存不是独立组件，而是 Software Storage Bus 的一部分 。它的作用域是"本地计算机"（每节点自己的缓存），对存储池和虚拟磁盘完全透明 ，S2D 启用时自动配置。

3.1 缓存语义：读缓存与写缓存的差异

PPT 写"缓存行为取决于操作类型"------这是简略表述，实际规则按磁盘类型组合有两套：

磁盘组合	读缓存	写缓存	原因
NVMe / SSD 缓存 + SSD 容量	❌ 不缓存	✅ 缓存	SSD 读延迟本身很低，缓存读收益小；缓存写可减少对容量盘的写磨损
SSD / NVMe 缓存 + HDD 容量	✅ 缓存	✅ 缓存	HDD 读延迟高，缓存读可获得 ~10× 延迟改善；缓存写同样收益

关键语义 ：这是 S2D 引擎的默认行为，不可在 Azure Stack Hub 上调整。运营商不能像 Windows Server S2D 那样通过 PowerShell 修改 CacheDeviceScenarios 或类似参数 ------ 这是 OEM 集成系统验证范围内的固定配置。

3.2 缓存层与容量层

S2D 的"缓存"是物理意义上 的快盘（NVMe / SSD），"容量"是物理意义上的慢盘（SSD / HDD）。两者通过 Software Storage Bus 协同：

复制代码

写入请求
   ↓
[Software Storage Bus]
   ↓
[缓存层（NVMe / SSD）] ← 写入立即落盘缓存
   ↓
[异步回写到容量层（SSD / HDD）]

读请求的路径：

NVMe / SSD 容量 + 缓存：直接读容量盘（不经过缓存）
HDD 容量 + 缓存：先查缓存 → 命中直接返回 → 未命中读容量盘 + 回写缓存

3.3 缓存对租户的"透明性"

L3 最佳实践 ：租户不需要也不应该感知缓存层的存在。S2D 缓存对工作负载完全透明，租户通过 REST API 看到的延迟、IOPS、吞吐量是"软件存储总线"汇总后的结果，不是单盘性能。

实际运维中，租户如果要做性能调优，应该关注的是：

存储账户类型选择（通用 v2 / BlobStorage 等）
磁盘 SKU 选择（Standard HDD / Premium SSD）
Blob 访问模式（单次 PutBlob vs 分块 PutBlockList）
并发请求设计（前端 SDK 的并行度设置）

而不是去尝试"绕过缓存"或"显式关闭缓存" ------ 这些都不是 Azure Stack Hub 上的可配置项。

4. 三路镜像：Azure Stack Hub 存储冗余策略

Azure Stack Hub 强制使用**三路镜像（Three-way mirror）**作为唯一的数据冗余策略。这是 Azure 公有云没有的特殊策略，也是 Azure Stack Hub 与 Windows Server S2D 的最大差异点之一。

4.1 三路镜像核心特征

维度	三路镜像的特性
副本数	3 副本（同数据写入三份）
优化方式	性能（牺牲存储效率换可靠性）
使用场景	所有热数据（Azure Stack Hub 没有"冷数据降级到两副本"机制）
存储效率	最低 33%（即 3 TB 物理盘仅能提供 1 TB 有效容量）
文件系统	ReFS
可配置性	不可关闭 / 不可降级为两副本

L1 微软硬要求 ：三路镜像是 Azure Stack Hub 的平台级约束，运营商不能通过任何 PowerShell / 门户操作改变副本数 。这是与 Windows Server S2D 的根本差异 ------ 在 Windows Server 自建 S2D 中，可选双向镜像 / 三向镜像 / 奇偶校验 / 混合配置；在 Azure Stack Hub 中，只有三路镜像。

4.2 与"普通数据镜像"的对比

对比简明扼要：

普通数据镜像（两路镜像）：只允许单个物理磁盘故障
三路镜像 ：允许两块物理磁盘同时故障

实务含义 ：在 Azure Stack Hub 的 Scale Unit 内（典型 4~16 节点），任意一个节点上的任意一块磁盘故障，两块同时故障仍然能保证数据可用。这是 Azure Stack Hub 在 OEM 集成系统上能承诺"硬件故障期间不丢数据"的根本基础。

4.3 与 Azure 公有云 LRS 的本质差异

Azure 公有云的 LRS（Locally Redundant Storage）提供"同一区域内三副本"------这个描述在表面层与 Azure Stack Hub 的三路镜像类似，但底层实现完全不同：

维度	Azure Stack Hub 三路镜像	Azure LRS
冗余域	Scale Unit 内	数据中心内
物理拓扑	S2D + Software Storage Bus	抽象层（不暴露物理）
故障粒度	节点 + 磁盘双重	存储节点 / 机架
跨数据中心	不支持	跨 AZ 可选（GZRS）
运维可见性	管理员可见 S2D 卷	租户完全不可见

关键认知 ：Azure Stack Hub 三路镜像不是 Azure LRS 的"私有云版本"------前者是 OEM 集成系统上的明确硬件级冗余策略，后者是公有云上对租户完全透明的抽象。运维上不能简单把 Azure LRS 的概念套用到 Azure Stack Hub 上。

4.4 三路镜像的存储效率代价

33% 的存储效率意味着 购买 100 TB 物理磁盘，实际只能提供约 33 TB 的有效容量。这一代价是 Azure Stack Hub 的"硬成本"------它的价值在于：

任意两块磁盘同时故障不丢数据（在 Scale Unit 内的硬件故障场景下，这是非常强的承诺）
无需复杂的多副本协调机制（与奇偶校验相比，三路镜像的重构速度快得多）
故障恢复期间 I/O 性能不降级（不会因为进入"重建模式"而显著变慢）

容量规划含义 ：在做 Azure Stack Hub 容量规划时，实际物理容量需求 ≈ 业务容量需求 × 3（不考虑 Infrastructure / VM Temp 等其他卷占用）。这一比例是平台级的，不能通过配置降低。

5. 副本分布：跨节点三副本写入的物理视角

5.1 副本分布规则

Azure Stack Hub 的 Storage Spaces Direct 在三副本写入时遵循以下规则：

同一份数据的三副本分布在三个不同的物理节点上
每个副本对应一个 256 MB 的物理存储单元（S2D 的固定分块大小）
副本写入完成后，集群确保任意节点故障 + 任意一块其他节点磁盘故障仍可访问

5.2 故障场景分析

故障场景	数据可用性	说明
单节点宕机	✅ 三副本中失去一个节点的所有副本，其他两个节点保留	数据仍有两副本可用
单节点宕机 + 另一节点一块磁盘故障	✅ 三副本中部分块失去两个副本，部分块仍有两个副本	数据仍可访问
两节点同时宕机	✅ 两个节点同时丢失，三副本全部丢失	数据不可访问
三节点同时宕机	❌ 所有副本丢失	数据不可访问

关键约束 ：两节点同时故障是数据可用性的边界 。Azure Stack Hub 通过 OEM 集成系统的硬件冗余（PDU / ToR / 服务器电源）降低两节点同时故障的概率，但不能消除这一可能性------一旦两节点同时故障，整个 Scale Unit 进入降级状态。

5.3 补丁更新期间的数据保护

Azure Stack Hub强调"补丁和更新期间丢失整个服务器仍然具有 2 副本冗余性"------这一表述是 Azure Stack Hub 滚动升级（Rolling Update） 流程的数据保护基础：

升级过程中逐节点进行，每次只重启一个节点
重启期间该节点暂时不可用，但 S2D 的副本仍存在于其他两个节点
升级完成后该节点重新加入，S2D 自动补齐副本到三副本状态

运维含义 ：Azure Stack Hub 滚动升级期间不会出现"无副本"窗口。这是 OEM 集成系统在出厂时通过硬件 + 软件 + 流程的多重保障达成的，运营商不能修改升级节奏以追求"更快"。

6. 缩放单元冗余：PDU / 交换机 / 服务器 / 磁盘四层叠加

Azure Stack Hub Scale Unit 的冗余设计是四层叠加------任何单点故障在四层中的某一层被吸收，多层同时故障才会真正影响服务。

6.1 四层冗余矩阵

冗余层	冗余设计	允许的故障	备注
PDU 冗余	每个机柜至少两条独立 PDU，服务器双电源	单 PDU 故障	服务器双电源负载均衡到双 PDU
交换机冗余	双 ToR（Top of Rack）+ MLAG 互联	单 ToR 或汇聚交换机故障	L1 微软硬要求：ToR 配置由 OEM 验证，运营商不能改
服务器冗余	Scale Unit 多节点 + S2D 三副本	单节点故障；第三个节点故障或第三个节点中的磁盘故障将导致受影响的虚拟磁盘离线	这是 Scale Unit 冗余的边界
磁盘冗余	三路镜像（参见 §4）	单盘故障；只要多盘故障分布在两个节点内，数据仍可用	跨两节点同时故障磁盘将导致虚拟磁盘离线

6.2 双 ToR + 双 PDU + 服务器双电源：硬件冗余拓扑

复制代码

              ┌──────── AC #1 ────────────┐
              │                            │
        ┌─────┴──────┐               ┌─────┴──────┐
        │   ToR #1   │ ←── MLAG ──→ │   ToR #2   │
        └─────┬──────┘               └─────┬──────┘
              │                            │
        ┌─────┴──────┐               ┌─────┴──────┐
        │ Server #1  │ ── SET ─────→ │ Server #N  │
        │  PSU A/B   │               │  PSU A/B   │
        └──┬─────┬───┘               └──┬─────┬───┘
           │     │                      │     │
   AC #1   │     │  AC #2         AC #1 │     │  AC #2
           ↓     ↓                      ↓     ↓
        ┌─────┐ ┌─────┐              ┌─────┐ ┌─────┐
        │ PDU │ │ PDU │              │ PDU │ │ PDU │
        │  A  │ │  B  │              │  A  │ │  B  │
        └─────┘ └─────┘              └─────┘ └─────┘

关键解读：

**每台服务器两个电源（A + B）**分别接 AC #1 和 AC #2 ------ 失去任一 AC，服务器由另一电源维持

每台服务器双网卡走 SET ------ 双上联到 两台 ToR ------ 失去任一 ToR 或任一网卡，流量自动切换

两台 ToR 通过 MLAG 互联 ------ ToR 间链路也冗余，且避免 STP 阻塞

PDU 由不同 AC 馈电 ------ 失去任一 PDU 或任一 AC，机柜仍由另一回路供电

这是 OEM 集成系统在出厂时验证完成的硬件拓扑。运营商能做的硬件操作仅限于"更换故障硬件"------不能修改网络配置、不能修改供电设计、不能移动机柜位置。

6.3 故障穿透的边界（关键误判信号）

L3 最佳实践 ：四层冗余不是"任意两层同时故障都不会出问题"------存在穿透的可能。下表是常见穿透场景：

穿透场景	影响	缓解
两个节点同时故障	Scale Unit 进入降级，部分虚拟磁盘离线	触发 OEM Support 流程紧急更换硬件
单节点故障 + 另一节点单盘故障	该磁盘所在的虚拟磁盘部分块不可用	OEM Support 更换故障磁盘，触发 S2D 自动重建
单节点故障 + 另一节点两块磁盘故障（不同节点）	受影响的虚拟磁盘部分块不可用	紧急更换 + 触发重建；重建期间 I/O 性能可能下降
两节点同时故障 + 第三节点单盘故障	多个虚拟磁盘完全不可用	必须先恢复两节点，再处理磁盘
三节点同时故障	Scale Unit 整体不可用	OEM Support 紧急处理

运维红线 ："两节点同时故障"是 Scale Unit 服务能力的边界 。在 OEM 集成系统的硬件 + 软件 + 流程保障下，这一概率极低，但不是零。任何"为什么我的数据访问变慢"的工单，都应该先检查 Scale Unit 是否已经处于降级状态。

7. IaaS 存储：虚拟机磁盘与对象存储基础

Azure Stack Hub 提供的 IaaS 存储是租户最常用的存储类别------虚拟机磁盘、容器镜像、快照、备份数据等，都跑在 IaaS 存储之上。

7.1 IaaS 存储的两大类

类别	承载对象	租户使用方式
虚拟机磁盘	OS Disk / Data Disk（VHD 形式）	通过 Azure Stack Hub 门户 / API 创建 VM 时挂载
对象存储基础	Page Blob（用于 VHD）、Block Blob（用于通用对象）	通过存储账户 SDK / REST API 直接操作

7.2 虚拟机磁盘的存储路径

复制代码

        租户视角                 Azure Stack Hub 内部
                                  
        ┌─────────┐              ┌──────────────────┐
        │   VM    │ 挂载磁盘      │  VHD → Page Blob │
        └────┬────┘              │       ↓           │
             │                   │  Storage Account  │
        ┌────┴────┐              │       ↓           │
        │ Disk    │ ←───────     │  存储卷（S2D VDisk）│
        └─────────┘              │       ↓           │
                                 │  物理磁盘（S2D）   │
                                 └──────────────────┘

关键点 ：租户在 VM 内看到的"磁盘"在 Azure Stack Hub 内部是一个 Page Blob，挂载在某个存储卷上。这种抽象让租户可以用熟悉的"挂载磁盘"概念，而管理员可以用"存储卷 + S2D 虚拟磁盘"视角管理。

7.3 磁盘类型与选择

Azure Stack Hub 上租户可用的磁盘类型（自 azs-1808 引入托管磁盘后，主流用法是托管磁盘）：

磁盘类型	用途	性能特征	计费
Standard HDD	标准数据盘 / OS 盘	机械盘性能特征	按容量计费
Premium SSD	高 IOPS 工作负载	上限值（2300 IOPs / 145 MB/s 单盘 cap）	按容量计费
托管磁盘 vs 非托管磁盘	1808 后默认托管	托管 = Azure 自动管理底层存储账户	按容量计费

L0 版本事实 ：托管磁盘自 azs-1808 起被引入 Azure Stack Hub（详细内容见下篇 §2）。 关键差异 ：Premium SSD 在 Azure Stack Hub 上不提供与 Azure 公有云同等的性能保证 ------单盘 cap 是 2300 IOPs / 145 MB/s，但实际可达性能受硬件和工作负载影响，微软未给出"必然达到"的保证。这一差异需要在 SLA 文档中显式说明。

8. PaaS 存储：Blob / Table / Queue 三件套

Azure Stack Hub 在 IaaS 存储之上还提供完整的 Azure 风格 PaaS 存储三件套 ------Blob、Table、Queue。这些服务与 Azure 公有云 API 兼容，租户开发的应用代码可以直接复用 Azure SDK。

8.1 三件套语义速查

服务	数据模型	主要用途	关键特性
Blob	二进制对象（Block / Append / Page）	非结构化数据（图片、视频、文档、备份）	大对象支持（最大 5 TB / 单 blob）
Table	NoSQL 键值对（PK + RK）	半结构化数据（设备元数据、配置、状态）	强一致性、灵活 schema
Queue	FIFO 消息队列	异步消息传递、削峰填谷	简单、可靠、低成本

8.2 Blob 三种类型

Blob 类型	数据组织	适用场景
Block Blob	块（最大 100 MB / 块）	通用对象：图片、视频、文档、备份
Append Blob	仅追加块	日志、审计流、顺序写入
Page Blob	512 字节页	VHD 虚拟机磁盘（IaaS 存储基础）

关键澄清 ：Page Blob 在 Azure Stack Hub 上几乎只用于 VHD。这是因为 Page Blob 的随机写特性（按 512 字节页写入）是为磁盘 I/O 模式设计的，通用对象场景使用 Block Blob 更合适。

8.3 Table 存储特点

Table 存储的 NoSQL 模型简单但有明确边界：

PK（Partition Key）+ RK（Row Key） 联合唯一确定一行
Schema 灵活 ------ 不同行可以有不同的属性列
强一致性 ------ 写入立即可读（区别于最终一致性 NoSQL）

典型应用场景：

设备信息（IoT 设备元数据）
用户状态（在线 / 离线 / 状态文本）
购物车 / 临时订单
配置项 / 事件与指标

L0 版本事实 ：Table 存储的 Partition Key + Row Key 大小限制为 400 个字符（即 800 字节）。这一限制与 Azure 公有云保持一致------单分区的设计需要把 PK 控制在合理大小，过大的 PK 会影响分区内扩展能力。

8.4 Queue 消息队列

Queue 提供简单、经济、持久的消息队列能力：

消息大小上限 64 KB
可包含数百万条消息
通过 HTTP / HTTPS 访问（经过身份验证）

典型应用场景：

解耦应用程序组件的异步消息传递
应对组件故障的弹性设计
异步处理请求、削峰填谷

L3 最佳实践 ：Azure Stack Hub 的 Queue 主要用于租户应用内部 的异步消息传递，不替代 Azure Service Bus / Event Hubs 等企业级消息中间件。如果租户需要更复杂的消息路由 / 主题订阅 / 事务消息，应该用外部消息中间件或迁移到 Azure 公有云的对应服务。

8.5 三件套的存储后端

租户视角和管理员视角的关键差异点：

租户视角 ：看到的是存储账户（Storage Account）------一个抽象入口，背后装满 Blob / Table / Queue 资源
管理员视角 ：看到的是存储卷（Storage Volume）------底层 S2D 卷划分

两者的映射关系是：

复制代码

       ┌─────────────────────────┐
       │    Storage Account      │  ← 租户看到
       │  ┌──────┐ ┌──────┐ ┌──────┐
       │  │Blob  │ │Table │ │Queue │
       │  └──┬───┘ └──┬───┘ └──┬───┘
       └─────┼────────┼────────┼─────┘
             │        │        │
       ┌─────┼────────┼────────┼─────┐
       │     ↓        ↓        ↓     │
       │   Storage Volume 1 / 2 / 3 │  ← 管理员看到
       │                              │
       └──────────────────────────────┘
              S2D 虚拟磁盘
              物理磁盘

关键认知 ：租户通过 Storage Account 写入的对象，最终落到管理员管理的 Storage Volume 上。两边看到的不是同一回事------这种分离是 Azure Resource Manager 抽象层的核心价值。

9. 租户视角：存储账户是工作负载侧的入口

租户在 Azure Stack Hub 上创建存储账户，是与存储服务交互的第一入口。所有 Blob / Table / Queue 操作都通过存储账户完成。

9.1 存储账户的核心职责

职责	含义
命名空间	全局唯一的账户名，所有对象路径以账户名为前缀
终结点（Endpoint）	提供 REST API 访问的统一 URL（`.blob.core.windows.net` / `.table.core.windows.net` / `*.queue.core.windows.net`）
访问控制	通过共享密钥（Shared Key）或 SAS（Shared Access Signature）控制访问权限
计费单元	容量 / 事务计费的最小单位
复制策略	本地三副本（Azure Stack Hub 强制，无 GRS / ZRS 选项）

9.2 租户的"存储账户 = 业务系统"对应

一个典型的业务系统在 Azure Stack Hub 上的存储账户布局：

复制代码

业务系统
├── 应用配置数据      → Table（结构化、灵活 schema）
├── 用户上传文件      → Blob（图片 / 文档 / 视频）
├── 异步任务消息      → Queue（削峰填谷）
├── 虚拟机磁盘        → Page Blob（VM OS / Data Disk）
├── 数据库备份        → Blob（冷数据 / 归档）
└── 审计日志          → Append Blob（顺序写入）

关键约束 ：租户不应假设存储账户是"无限扩展" 。Azure Stack Hub 上存储账户的最大容量受 Scale Unit 物理容量限制，且 Storage Account 数量本身也有上限（具体上限随 azs 版本演进变化）。大规模场景下需要做账户拆分设计。

9.3 租户视角下的存储抽象优势

对租户来说，存储账户抽象带来三个关键好处：

API 一致性：与 Azure 公有云使用同一套 SDK / REST API，代码可移植
自助服务：租户可以独立创建 / 配置 / 删除存储账户，无需管理员介入（除配额审批外）
RBAC 粒度：通过 Azure RBAC 控制到账户级 / 容器级 / 对象的访问权限

L3 最佳实践 ：租户设计存储账户时，应该按业务域 / 生命周期 / 性能等级拆分账户，而不是把所有数据塞到一个账户里。这有助于：

隔离故障 ------ 一个账户出问题不影响其他账户

独立计费 ------ 不同业务的存储成本清晰可见

精细 RBAC ------ 不同业务可以有不同的访问控制策略

性能隔离 ------ 不同账户的访问模式不会相互影响

10. 管理员视角：存储卷是基础设施侧的资源单位

管理员在 Azure Stack Hub 管理员门户看到的是存储卷（Storage Volume）------这些是 S2D 虚拟磁盘在 Scale Unit 中的具体划分。

10.1 存储卷分类

Azure Stack Hub Scale Unit 的存储池被划分为三类卷，各自承载不同的数据：

卷类型	用途	容量份额（典型）	备注
Infrastructure 卷	Azure Stack Hub 基础设施 VM 与核心服务所需文件	由 OEM 集成系统固定	运营商不可调整
VM Temp 卷	租户 VM 的临时磁盘	按 Scale Unit 总容量按比例划分	临时数据，租户不应在上面存持久数据
Tenant 卷	租户存储账户 / Blob / Table / Queue / VM 数据盘	由 OEM 集成系统 + 容量规划决定	运营商主要运维对象

L1 微软硬要求 ：Infrastructure 卷和 VM Temp 卷的容量分配在 OEM 集成系统出厂时固化，运营商不能通过 PowerShell 或门户调整。运营商可管理的主要是 Tenant 卷的分配、容量监控、跨卷迁移。

10.2 卷的物理映射

每个 Tenant 卷在物理层对应一个 S2D 虚拟磁盘（Virtual Disk），由 S2D 在三节点之间按三路镜像写入：

复制代码

Scale Unit 物理节点分布：
  Server 1 ──┐                ┌── Server 4
             │                │
  Server 2 ──┼── Tenant VDisk│── Server 5 (or N/A)
             │   (三路镜像)    │
  Server 3 ──┘                └── Server N

Tenant VDisk 1 = 卷 1 = 容纳 Storage Account 1/2/3
Tenant VDisk 2 = 卷 2 = 容纳 Storage Account 4/5/6
...

关键澄清 ：一个 Storage Account 的所有数据落在某个 Tenant VDisk 上，但管理员门户不会直接显示这种映射------存储账户和 VDisk 的关联关系在底层由 SRP（Storage Resource Provider）维护。

10.3 管理员的存储运维动作清单

管理员在 Azure Stack Hub 上对存储卷的运维动作（仅这些动作被支持）：

动作	描述	备注
容量监控	通过管理员门户 / PowerShell 监控卷使用率	触发告警 → 容量规划
配额管理	为 Plan / Offer 设置存储容量配额	限制租户使用
告警处理	响应"容量接近上限"告警	触发扩容 / 迁移决策
卷间迁移	把租户托管磁盘从一个卷迁移到另一个卷	离线操作（详见下篇 §6）
回收容量	强制垃圾回收已删除账户	立即回收或等保留期自动回收
恢复已删除账户	在保留期内恢复误删的存储账户	保留期默认 15 天，可配置

关键边界 ：管理员不能 在 Azure Stack Hub 上创建新卷、扩展现有卷、修改卷的冗余策略------这些都是 OEM 集成系统出厂配置的范围。容量扩展只能通过 OEM Support 流程增加 Scale Unit 节点或更换更大容量磁盘。

11. 运维红线：哪些能改、哪些不能改

Azure Stack Hub 作为 OEM 集成系统，对存储的运维动作有明确的边界。下表是常见动作的合规性速查：

动作	管理员能做吗	备注
创建存储账户	✅ 租户可自助	配额管理由管理员控制
创建 VM + 磁盘	✅ 租户可自助	同上
监控容量 / 设置告警	✅	通过管理员门户
修改存储配额	✅	通过 Plan / Offer 配置
回收已删除账户	✅	立即回收或等保留期
卷间迁移托管磁盘	✅	离线操作，详见下篇 §6
修改三路镜像为两路	❌ L1 硬要求	平台级强制
修改 S2D 缓存策略	❌	OEM 验证范围内固定
修改存储池配置	❌	OEM 验证范围内固定
增加物理磁盘	❌	必须通过 OEM Support 流程
更换物理磁盘	✅ 仅故障盘	通过 OEM Support 流程更换
修改 ToR 交换机配置	❌	OEM 验证范围内固定
重启 ERCS VM（紧急情况除外）	⚠️ 不建议	可能影响存储服务

运维红线（强化）：

不要尝试关闭 / 降级三路镜像 ------ 平台级强制，没有开关

不要修改 OEM 验证的物理 / 网络配置 ------ 包括 ToR / 物理磁盘 / 缓存策略

不要在生产时段执行卷间迁移 ------ 这是离线操作，迁移期间 VM 不可用

不要假设"删了账户就立即释放容量" ------ 保留期内数据仍在物理盘上

不要绕过配额审批流程 ------ 配额是 Plan / Offer 治理的基础，绕过等于破坏多租户治理

12. 上篇小结

本篇以 Azure Stack Hub 存储服务为主线，完成了从物理存储栈到租户服务全景的完整图谱。

核心要点回顾：

存储栈结构清晰：S2D + Software Storage Bus + CSVFS + ReFS 五层抽象，从物理磁盘到虚拟磁盘再到租户存储账户，每一层职责明确
三路镜像是平台级约束：不可关闭 / 不可降级，存储效率 33%，换来"任意两块磁盘同时故障仍可用"的强承诺
缓存语义因盘型组合而异：NVMe / SSD 缓存 SSD 时只缓存写；SSD / NVMe 缓存 HDD 时同时缓存读写
冗余是四层叠加：PDU / 交换机 / 服务器 / 磁盘，每一层吸收一种故障
租户视角和管理员视角分离：前者看到存储账户（业务入口），后者看到存储卷（基础设施单位），中间通过 Azure Resource Manager 抽象层连接
运维边界明确：能改的是配额 / 告警 / 卷间迁移 / 容量回收；不能改的是镜像策略 / 物理硬件 / OEM 验证的网络配置

下篇将展开：

托管磁盘（Managed Disks）：1808 起引入的存储抽象、与 Azure 公有云的差异、BitLocker 加密、最大 1023 GiB 上限、2300 IOPs / 145 MB/s 性能 cap
Blob 上传机制：单次 PutBlob（≤ 256 MB）vs 分块 PutBlockList（最高 50,000 块 × 100 MB）
Table 存储：分区键 / 行键 400 字符限制、伸缩边界、单表服务器的速率限制
Queue 队列：64 KB 消息大小、削峰填谷典型应用
容量管理：容量分配（系统 / 租户两套视图）、告警（可用性 / 容量 / 服务健康）、配额管理、卷间迁移、删除保留期

本系列下一篇： $下篇$ Azure Stack Hub 存储服务管理：托管磁盘 + Blob + Table + Queue + 容量管理

Azure Stack Hub 存储服务：从 S2D 物理栈到租户服务全景（上篇）

修订说明：

目录

1. 存储服务全景：与 Azure 一致的 IaaS + PaaS 存储

1.1 五大核心定位

1.2 服务对象全景图

1.3 与 Azure 公有云的存储差异点（关键速查）

2. 物理存储栈：S2D + Software Storage Bus + CSVFS + ReFS

2.1 存储栈五层结构

2.2 与 Windows Server S2D 的关系（关键澄清）

2.3 物理磁盘类型与部署模式

3. 内置缓存：Software Storage Bus 的性能加速层

3.1 缓存语义：读缓存与写缓存的差异

3.2 缓存层与容量层

3.3 缓存对租户的"透明性"

4. 三路镜像：Azure Stack Hub 存储冗余策略

4.1 三路镜像核心特征

4.2 与"普通数据镜像"的对比

4.3 与 Azure 公有云 LRS 的本质差异

4.4 三路镜像的存储效率代价

5. 副本分布：跨节点三副本写入的物理视角

5.1 副本分布规则

5.2 故障场景分析

5.3 补丁更新期间的数据保护

6. 缩放单元冗余：PDU / 交换机 / 服务器 / 磁盘四层叠加

6.1 四层冗余矩阵

6.2 双 ToR + 双 PDU + 服务器双电源：硬件冗余拓扑

6.3 故障穿透的边界（关键误判信号）

7. IaaS 存储：虚拟机磁盘与对象存储基础

7.1 IaaS 存储的两大类

7.2 虚拟机磁盘的存储路径

7.3 磁盘类型与选择

8. PaaS 存储：Blob / Table / Queue 三件套

8.1 三件套语义速查

8.2 Blob 三种类型

8.3 Table 存储特点

8.4 Queue 消息队列

8.5 三件套的存储后端

9. 租户视角：存储账户是工作负载侧的入口

9.1 存储账户的核心职责

9.2 租户的"存储账户 = 业务系统"对应

9.3 租户视角下的存储抽象优势

10. 管理员视角：存储卷是基础设施侧的资源单位

10.1 存储卷分类

10.2 卷的物理映射

10.3 管理员的存储运维动作清单

11. 运维红线：哪些能改、哪些不能改

12. 上篇小结