Azure Stack Hub 存储服务：托管磁盘、Blob/Table/Queue 与容量管理（下篇）

原创于 2026-07-29 12:33:24 发布 · 149 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

Azure Stack Hub

话题

#暑假·七月创作之星博客挑战赛

未经同意，请勿转载！

本篇定位：本文是 Azure Stack Hub 存储服务系列的下篇，专注于 存储服务管理 —— 托管磁盘（Managed Disks）的差异与版本演进、Blob 上传机制（含块 / 大对象模式）、Table 存储的分区与伸缩边界、Queue 消息队列的应用场景、容量分配 / 告警 / 配额 / 卷间迁移 / 删除保留期。

版本基础：本文基于 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 公有云的差异（关键速查）
托管磁盘的 REST 操作集
托管磁盘创建源：四种典型路径
快照：独立生命周期与 SAS 导出
对象存储服务（Blob）：主要特性与上传机制
Table 存储：NoSQL 模型与伸缩边界
Queue 队列：消息中间件与典型应用
容量管理：分配 / 告警 / 配额 / 迁移 / 保留
运维红线与下篇小结

1. 托管磁盘概述：为什么需要托管磁盘

托管磁盘（Managed Disk）是 Azure Stack Hub 自 azs-1808 起引入的存储抽象，它把"VM 磁盘 → 存储账户 → 存储卷"的间接链路变成"VM 磁盘 = ARM 一级资源"的直接链路。

1.1 为什么需要托管磁盘（PPT 列出四大理由）

理由	含义	对谁的价值
更容易管理 blob	租户不需要手动管理底层 Page Blob / 存储账户	应用开发者
磁盘级 RBAC + 锁 + 标记	每个磁盘是独立的 ARM 资源，可独立授权 / 加锁 / 打标签	安全 / 治理
快照	支持磁盘级快照，独立生命周期	备份 / 灾备
自动均匀放置磁盘数据	SRP 自动把磁盘分布到合适的卷，避免单卷过热	性能 / 容量

1.2 托管磁盘 vs 非托管磁盘（架构差异）

L0 版本事实：自 azs-1808 起，创建 VM 时默认使用托管磁盘。这是 PPT slide 17 给出的明确表述。

托管磁盘架构：
  VM
   ↓
  Disk（ARM 一级资源）── 磁盘级 RBAC / 锁 / 标签
   ↓
  托管存储账户（Azure Stack Hub 自动管理，租户不可见）
   ↓
  Storage Volume（S2D VDisk）
   ↓
  物理磁盘

非托管磁盘架构：
  VM
   ↓
  VHD（Page Blob）── 租户需要手动管理存储账户
   ↓
  存储账户（租户管理）
   ↓
  Storage Volume（S2D VDisk）
   ↓
  物理磁盘

关键差异：托管磁盘把"存储账户"这一中间层对租户屏蔽。租户操作的对象是"磁盘"，不是"存储账户里的 VHD"。这一抽象带来四个直接好处：

简单 —— 租户不需要关心存储账户的容量规划、副本策略、访问密钥管理

易管理 —— Azure Stack Hub 自动优化数据放置，避免单卷过热

顶级资源 —— 磁盘、快照、镜像都是 ARM 的一级资源，可独立管理

细粒度访问控制 —— 通过 Azure RBAC 在磁盘级别控制访问权限

1.3 托管磁盘的"顶级资源"属性

在 Azure Resource Manager 视角下，托管磁盘是与其他资源同级的 ARM 对象：

Resource Group
├── VM（Microsoft.Compute/virtualMachines）
├── Disk（Microsoft.Compute/disks）      ← ARM 一级资源
├── Snapshot（Microsoft.Compute/snapshots）  ← ARM 一级资源
├── Image（Microsoft.Compute/images）   ← ARM 一级资源
├── Virtual Network（Microsoft.Network/virtualNetworks）
└── Storage Account（Microsoft.Storage/storageAccounts）  ← 仅用于非托管磁盘

L3 最佳实践：托管磁盘时代，租户通常不需要直接创建存储账户——存储账户成为 Azure Stack Hub 的内部实现细节。这一变化让 RBAC 设计更简单（按磁盘授权而不是按账户授权），也让备份 / 灾备工具（基于磁盘快照）更容易实现。

2. 托管磁盘与 Azure 公有云的差异（关键速查）

托管磁盘与 Azure 公有云的对比矩阵，本节显式标注差异来源层（L0 版本事实 / L1 微软硬要求 / L2 OEM 实现）。

2.1 核心差异速查表

差异点	Azure（公有云）	Azure Stack Hub	差异来源
备份选项	Azure Backup 服务	尚未支持	L0 版本事实（azs 版本演进中）
灾难恢复选项	Azure Site Recovery	Azure Site Recovery on Azure Stack Hub	L0 版本事实
磁盘性能分析	聚合指标 + 每盘指标	尚未支持	L0 版本事实
磁盘大小上限	P80（32 TiB）/ E80（32 TiB）/ S80（32 TiB）	M30（1023 GiB）	L1 微软硬要求（Hub 平台限制）
磁盘快照复制	运行中 VM 磁盘快照支持	通过备份厂商支持	L0 版本事实
磁盘类型	Premium SSD / Standard SSD / Standard HDD	Premium SSD + Standard HDD（无 Standard SSD）	L0 版本事实
静态加密	Azure SSE / Azure Disk Encryption	BitLocker 128-bit AES	L1 微软硬要求（Hub 平台限制）
磁盘扩容	支持（Windows / Linux）	支持（Windows / Linux）	L0 版本事实
镜像	托管自定义镜像	支持	L0 版本事实
迁移工具	ConvertTo-AzVMManagedDisk cmdlet	不支持（需手动重建 VM）	L0 版本事实
Premium 性能保证	完全支持（按 SKU 分级）	可配置但无性能保证	L1 微软硬要求
Premium IOPs	取决于磁盘大小	2300 IOPs / 单盘 cap	L0 版本事实
Premium 吞吐	取决于磁盘大小	145 MB/s / 单盘 cap	L0 版本事实

关键澄清：上表中标注"尚未支持"的项是 L0 版本事实——它们随 azs 版本演进可能逐步补齐，不应被理解为"长期或永久不可用"。本文表述以当期 azs 版本为准。

2.2 关键数字的来源层解读

数字	数值	来源层	含义
托管磁盘最大 1023 GiB	M30 SKU	L1 微软硬要求	Azure Stack Hub 平台级容量上限，未来版本可能变化
Premium IOPs 上限 2300	2300 IOPs / 单盘	L0 版本事实	cap（上限）而不是 provisioned（保证）
Premium 吞吐上限 145 MB/s	145 MB/s / 单盘	L0 版本事实	cap 而不是 provisioned
BitLocker 128-bit AES	128-bit AES	L1 微软硬要求	Azure Stack Hub 静态加密的唯一选项

关于 IOPs / 吞吐的"cap"语义：微软官方明确说明"Managed disks IOPs and throughput in Azure Stack Hub is a cap number instead of a provisioned number, which can be impacted by hardware and workloads running in Azure Stack Hub." —— 这是非常重要的差异点。Azure 公有云的 Premium SSD 是按 SKU 保证的，Azure Stack Hub 的 Premium SSD 只是上限。

2.3 与 Azure 公有云的迁移注意事项

从 Azure 公有云迁回 Azure Stack Hub 时，托管磁盘相关代码需要做以下调整：

场景	Azure 公有云做法	Azure Stack Hub 做法
磁盘大小	可选 32 TiB / P80	最大 1023 GiB / M30
加密选项	SSE / ADE 多套选项	仅 BitLocker
Premium 性能假设	按 SKU 保证	无保证，仅 cap 上限
ConvertTo-AzVMManagedDisk	支持	不支持（手动迁移）
磁盘性能监控	聚合 + 每盘指标	尚未支持（需依赖 OEM 监控工具）

L3 最佳实践：不要假设 Azure Stack Hub 与 Azure 公有云的存储性能线性对应。在做工作负载迁移时，必须在 Azure Stack Hub 上做实际性能测试，根据实测结果调整应用层假设。

3. 托管磁盘的 REST 操作集

托管磁盘的 REST 操作分为四类，本节把它们与实际运维场景对应。

3.1 REST 操作分类

操作类别	典型 REST 调用	运维场景
磁盘创建 / 更新 / 删除	PUT /subscriptions/.../disks/{diskName}、DELETE /subscriptions/.../disks/{diskName}	创建新盘 / 修改 SKU / 删除盘
创建快照	PUT /subscriptions/.../snapshots/{snapshotName}	备份 / 灾备
导出快照 / 磁盘	GET /subscriptions/.../snapshots/{snapshotName}（返回 SAS URI）	数据迁移 / 备份归档
VM 操作（挂载磁盘）	VM 创建 / 更新 API 中 disks 数组	创建 VM 时挂载 / 热添加磁盘
VM 读写磁盘 IOPS / 时延 / 吞吐量	在 VM 内部通过 OS 工具（iostat / PerfMon）观测	性能调优

L3 最佳实践："VM 读写磁盘 IOPS / 时延 / 吞吐量"观测在 VM 内部完成——这不属于 Azure Stack Hub 平台的 REST API 范围，而是 OS 内部的性能工具范畴。常见的观测手段包括 Linux 的 iostat / fio、Windows 的 PerfMon / Get-Disk + Get-Counter。

3.2 与 Azure 公有云的 API 兼容性

L0 版本事实：Azure Stack Hub 托管磁盘支持的 API 版本比 Azure 公有云滞后数代。当前主流 azs 版本支持的版本号（按版本段）：

azs-2102 ~ azs-2604：2019-07-01

azs-2008 ~ azs-2604：2019-03-01 / 2018-09-30 / 2018-06-01 / 2018-04-01 / 2017-03-30

azs-1802 ~ azs-2005：2017-03-30 / 2017-12-01（managed images only）

迁移含义：从 Azure 公有云下载的 ARM 模板，如果使用了较新的 API 版本，可能无法直接部署到 Azure Stack Hub——需要把 apiVersion 字段改写为 Azure Stack Hub 支持的版本。这一改写是迁移 Azure Stack Hub 时最容易踩坑的环节之一。

3.3 ConvertTo-AzVMManagedDisk cmdlet 不可用

L0 版本事实：Azure PowerShell 的 ConvertTo-AzVMManagedDisk cmdlet 在 Azure Stack Hub 上不可用——这是与 Azure 公有云的明确差异。如果租户从 Azure 公有云导入一个非托管磁盘 VM，不能直接用 ConvertTo cmdlet 转换，需要通过：

导出 VHD（通过存储账户 SAS）

创建托管磁盘（指定 VHD 作为创建源）

创建 VM 并挂载新磁盘

4. 托管磁盘创建源：四种典型路径

"多种创建源"——本节展开四种典型创建源及适用场景。

4.1 磁盘创建源速查

创建源	用途	典型场景
空盘	创建全新空磁盘	新 VM 的数据盘
从 VHD 创建	指定 VHD URL 创建磁盘	跨 Azure Stack Hub 实例迁移
从快照创建	从已有磁盘快照恢复	备份恢复、版本回滚
从托管镜像创建	从共享镜像创建	标准化 VM 模板

4.2 通过 VHD 文件创建托管磁盘（迁移场景）

这是 Azure Stack Hub 之间迁移数据的典型路径：

源 Azure Stack Hub
  └─ Storage Account 1
       └─ Page Blob (vhd-source.vhd)
                ↓ (生成 SAS URI)
                ↓ (提供 read 权限)
目标 Azure Stack Hub
  └─ 创建托管磁盘（Source = SAS URI）
       └─ 挂载到新 VM

L3 最佳实践：VHD 跨实例迁移期间，源 Page Blob 的 SAS URI 必须保持有效——使用短期 SAS（数小时）即可，避免暴露长期 SAS。

4.3 创建快照（独立生命周期）

快照是独立的 ARM 资源，不依赖于父磁盘：

Disk（ARM 资源 #1）── 父
  └─ Snapshot 1（ARM 资源 #2，独立生命周期）
  └─ Snapshot 2（ARM 资源 #3，独立生命周期）

关键特性：

独立生命周期：删除父磁盘时，快照可以独立保留

快照级 RBAC：可以为每个快照单独设置访问权限

基于 SAS URI 导出：可以生成 SAS URI 供其他实例读取

5. 快照：独立生命周期与 SAS 导出

Azure Stack Hub把快照定位为"独立的 ARM 资源"。本节展开快照的运维动作。

5.1 快照的核心特性

特性	含义	对运维的价值
独立生命周期	快照是独立 ARM 资源，可独立保留 / 删除	父磁盘删除不影响快照
快照级 RBAC	每个快照可独立授权	不同快照可分发给不同租户
基于 SAS URI 的导出	可生成 SAS URI 供其他实例读取	跨实例数据迁移

5.2 快照的存储方式

L0 版本事实：Azure Stack Hub 快照是完整复制（full copy） 而不是 Azure 公有云的"增量快照"（incremental snapshot）。

关键含义：Azure 公有云的快照可以只存储增量差异，节省存储；Azure Stack Hub 的快照是完整复制。这意味着频繁创建快照会显著消耗存储容量——快照存储成本在 Azure Stack Hub 上比 Azure 公有云更高，需要在备份策略中考虑。

5.3 快照 vs 备份 vs 灾备的边界

能力	快照	备份	灾备
数据保护范围	单磁盘 / 单 VM	多 VM / 多业务系统	跨数据中心
恢复速度	秒级	分钟级	小时级
存储成本	高（完整复制）	中（增量 / 压缩）	高（跨地域复制）
Azure Stack Hub 支持	✅ 平台内建	通过备份厂商支持	通过 OEM / 第三方方案

L3 最佳实践：不要把快照当作备份的替代品——快照是"快速回滚"工具，不是"长期数据保护"工具。生产环境的备份 / 灾备应该用专业备份软件 + 异地复制。

6. 对象存储服务（Blob）：主要特性与上传机制

Azure Stack Hub的Blob服务主要特性和两种上传模式。本节展开核心要点。

6.1 Blob 服务的主要功能

功能	含义	价值
弹性伸缩	自动适应负载变化	无需容量规划
数据持久耐用（LRS）	本地三副本（无 GRS / ZRS 选项）	Scale Unit 内高可用
高可用性	多节点冗余 + 自动故障转移	业务连续性
强一致性	写入立即可读	与最终一致性 NoSQL 区分
动态扩展带宽和 TPS	根据负载自动扩展	应对突发流量
成本效益	按用量计费，无最低消费	适合突发工作负载

6.2 上传对象：单次 PutBlob（≤ 256 MB）

L0 版本事实：单次 REST 调用最大支持 256 MB（API version 2016-05-31 之后；更早版本是 64 MB）。

REST Call: PutBlob(Image.jpg)
           ↓
       Image.jpg（≤ 256 MB）
           ↓
       Blob 后端存储

关键特性：PutBlob 是"替换式"上传——单次调用把整个 Blob 内容替换为目标内容。如果上传失败，Blob 内容可能是损坏的旧版本，需要重传。

6.3 上传大容量对象：分块 PutBlockList

L0 版本事实：分块上传（PutBlockList）的限制——

每个数据块最大 100 MB

每个块大小可变

总块数最多 50,000 块

BlockId 长度固定

REST Calls:
  PutBlock(blobName, BL001, BL001Data);
  PutBlock(blobName, BL002, BL002Data);
  ...
  PutBlock(blobName, BLN00, BLN00Data);
  PutBlockList(blobName, BL001, ..., BL00N);  ← 提交块列表，完成上传

关键优势：

高效的上传和重试机制 —— 单块失败可重传，不需要重传整个 Blob

支持并行且无序的上传 —— 块可乱序上传，最后 PutBlockList 提交

适用于大文件 —— 视频 / 备份 / 大文档

6.4 100 MB / 50,000 块的存储容量含义

限制	数学含义	实务含义
每块最大 100 MB	单块大小上限	单块超过 100 MB 的应用需要分块
最多 50,000 块	单 Blob 容量上限 = 50,000 × 100 MB = 5 TB	单 Blob 最大 5 TB；超过此值需要分片

关键判断：Azure Stack Hub Blob 单 Blob 最大 5 TB 与 Azure 公有云对齐——这是 Block Blob 设计的硬上限。如果业务需要存超过 5 TB 的单个对象，需要在应用层做分片。

6.5 Blob 服务在实际场景中的典型应用

场景	Blob 类型	模式
用户上传图片 / 文档	Block Blob	小于 256 MB 用 PutBlob；更大用 PutBlockList
视频文件	Block Blob	通常用 PutBlockList 分块上传
虚拟机磁盘（VHD）	Page Blob	通过 VM 管理层创建，租户不需要直接操作
审计日志 / 顺序写入	Append Blob	日志追加场景
备份归档	Block Blob	大文件用 PutBlockList

7. Table 存储：NoSQL 模型与伸缩边界

Azure Stack Hub Table 存储的 NoSQL 模型。本节展开关键限制和应用模式。

7.1 Table 存储的 NoSQL 数据模型

Table 存储的每条记录由三部分组成：

PK（Partition Key） —— 分区键，决定数据物理分布
RK（Row Key） —— 行键，分区内唯一
属性列 —— 灵活 schema，可包含任意属性

PK | RK      | Name        | Status    | WebSite        | Email
A  | AlexP   | Alex Pen    | Busy      | http://...     | alexp@...
B  | BillP   | Bill Peters | Available | http://...     | alexp@...

PK | RK      | Name        | Status    | Photo       | Email
B  | BillP   | Bill Peters | Available | http://...  | alexp@...

PK | RK      | Name        | Status    | EmpNo
A  | AliceC  | Alice Clarke| Available | 1223

PK | RK      | Name        | Status
B  | BobS    | Bob Stevens | Offline

关键特性：

NoSQL 键值对存储 —— 灵活 schema，不同行可有不同属性

快速开发 —— 不需要预定义 schema

扩展性 —— 从很少记录扩展到数百万记录

强一致性模型 —— 写入立即可读（区别于最终一致性 NoSQL）

7.2 Table 存储的典型应用场景

场景	描述
购物车	用户会话级数据，PK = UserId
地址簿	用户联系人，PK = UserId，RK = ContactId
设备信息	IoT 设备元数据，PK = DeviceType
服务器状态	监控心跳，PK = ServerId
事件与指标	时序数据，PK = EventTime
应用配置	配置项存储，PK = AppName

7.3 Table 存储的伸缩边界（关键约束）

L0 版本事实：Table 存储有两个明确的伸缩边界——

限制	数值	含义
Partition Key + Row Key 大小限制	400 个字符（800 字节）	PK + RK 联合最大 800 字节
单租户表的伸缩上限	单个表服务器数据库的事务速率限制	一个表的所有分区都存在同一个数据库中

关键含义 1（PK + RK 大小）：PK + RK 联合不能超过 800 字节。PK 设计需要考虑大小——避免把大字符串（如完整的 URL / 长 JSON 串）直接作为 PK。

关键含义 2（伸缩边界）：一个租户表的所有分区都在同一个数据库中，这意味着单表的可伸缩性受限于单个表服务器数据库的事务速率。如果业务需要单表支持超过数据库事务速率的 QPS，应该考虑拆分多个表。

7.4 Table 存储的存储分布（管理员视角）

租户表（多个）
   │
   ├── 表记录（rows）
   │
   └── 数据库（DB1 ~ DB8）
          │
          └── 卷 1 / 卷 2（S2D VDisk）

L2 OEM 实现：数据库的物理分布由 Azure Stack Hub 内部自动管理，管理员不需要也不应该干预。租户只需要关心"表 / 分区 / 行"的概念层级。

8. Queue 队列：消息中间件与典型应用

PPT slide 32 给出 Queue 的核心特性。本节展开实际应用模式。

8.1 Queue 的核心特性

特性	含义
简单	标准 FIFO 消息队列
经济	成本极低，适合大规模消息流
持久	消息持久化到磁盘（三副本）
HTTP / HTTPS 访问	通过标准 HTTP 协议访问，经过身份验证
消息大小上限	64 KB
消息数量上限	数百万条
访问范围	从任何地方通过认证 HTTP / HTTPS

8.2 Queue 的典型应用场景

场景	描述
解耦异步消息	应用程序组件之间的异步通信
故障弹性	应对组件故障的弹性设计
削峰填谷	突发请求缓冲，平滑后端处理
任务分发	把耗时任务异步分发到后台 worker

8.3 Queue 与其他消息中间件的边界

L3 最佳实践：Azure Stack Hub Queue 是轻量级消息队列，不替代以下企业级消息中间件：

中间件	适用场景	Queue 不适合的场景
Azure Service Bus	主题订阅 / 事务消息 / 会话	Queue 不支持主题订阅
Azure Event Hubs	大规模事件流 / 实时分析	Queue 不是事件流方案
Apache Kafka	大数据流处理	Queue 不是流处理平台
RabbitMQ	复杂路由 / 多协议	Queue 不支持高级路由

关键判断：Queue 适合简单 FIFO 场景，复杂消息模式需要用其他中间件或迁移到 Azure 公有云的对应服务。

8.4 Queue 的存储分布（管理员视角）

租户队列（多个）
   │
   ├── 队列消息（messages）
   │
   └── 数据库（DB1 ~ DB8）
          │
          └── 卷 1 / 卷 2（S2D VDisk）

L2 OEM 实现：与 Table 存储类似，Queue 的物理存储分布由 Azure Stack Hub 内部自动管理。

9. 容量管理：分配 / 告警 / 配额 / 迁移 / 保留

Azure Stack Hub容量管理的完整图谱。本节按"分配 → 监控 → 配额 → 迁移 → 保留"的顺序展开。

9.1 容量管理全景

Azure Stack Hub 存储容量管理
   │
   ├── 容量分配（系统订阅 vs 租户订阅）
   │
   ├── 容量监控 + 告警
   │     ├── 可用性告警
   │     ├── 容量用完告警
   │     ├── 服务健康度告警
   │     └── 数据存储不可用告警
   │
   ├── 配额管理（Plan / Offer 配置）
   │
   ├── 卷间迁移（管理员操作）
   │
   └── 删除保留期（默认 15 天）

9.2 容量分配：两套订阅视图

Azure Stack Hub容量分配的"系统订阅 vs 租户订阅"两套视图：

订阅类型	用途	包含内容
系统订阅	Azure Stack Hub 基础设施自身	Infrastructure VM 数据、诊断数据、系统对象
租户订阅	租户工作负载	VM 磁盘、镜像、快照、Blob、Table、Queue

关键认知：两套订阅的容量是分开计数的——租户配额耗尽不影响系统订阅的基础设施运行，但反过来系统订阅预留的容量是"硬预留"的，租户不能使用这部分容量。

9.3 IaaS 场景 vs 应用场景的容量消耗差异

场景	容量消耗主体	容量规划特点
IaaS 场景	VM OS Disk + Data Disk + 镜像 + 快照 + Page Blob	单 VM 容量相对可预测
应用场景	对象存储（Blob）+ 表存储 + 队列 + 诊断 + 应用数据	容量增长模式不规则，需持续监控

L3 最佳实践：IaaS 场景的容量规划相对简单（每 VM 容量 × VM 数量），应用场景的容量规划复杂（Blob 增长、Table 增长、Queue 增长可能非线性）。建议在 Azure Stack Hub 部署前先做应用场景的容量预测，把"未来 12 个月增长曲线"作为容量规划的核心输入。

9.4 容量监控 + 告警：四类告警

四类容量相关告警：

告警类别	触发条件	严重程度
可用性告警	数据存储不可用	紧急
容量用完告警	卷使用率达到阈值	警告
服务健康度告警	存储服务整体异常	警告 / 紧急
数据存储不可用告警	部分数据访问失败	警告
基础设施依赖不可用告警	底层依赖服务故障	警告

L0 版本事实：容量用完告警的阈值随 azs 版本演进变化，通常建议关注 70% 警告 / 90% 紧急这两档。实际阈值以当期版本 + OEM 配置为准，不要假设固定值。

9.5 配额管理（管理员视角）

管理员通过 Plan / Offer 控制租户的容量上限：

配额类型	控制对象	配置位置
存储账户数量	单订阅可创建的存储账户数	Plan / Offer
存储容量	单订阅可使用的总容量	Plan / Offer
容器 / Blob / Table / Queue 数量	各对象的数量上限	Plan / Offer

L3 最佳实践：

为现有 Offer 增加 Plan —— 不影响现有租户，平滑升级配额

修改配额 —— 通过 Plan / Offer 配置，需要走变更审批

不要绕过配额 —— 配额是多租户治理的基础，绕过等于破坏治理

9.6 卷间迁移（管理员关键动作）

L1 微软硬要求：磁盘迁移不支持热迁移，目前是离线操作。

9.6.1 为什么需要卷间迁移

L0 版本事实：由于租户使用模式不同，一些租户份额比其他份额使用更多的空间。结果可能是一个份额（卷）比其他相对未使用的份额占用的空间少。

卷间不平衡场景：

初始状态（不平衡）：
  卷 1 = 80% 已用
  卷 2 = 40% 已用

迁移后（平衡）：
  卷 1 = 50% 已用
  卷 2 = 70% 已用

9.6.2 离线迁移对业务的影响

状态	业务影响
迁移前	业务正常运行
迁移过程中	VM 不可用（磁盘被卸载 → 复制到目标卷 → 重新挂载）
迁移完成后	业务恢复（需要 VM 重新启动）

运维红线：卷间迁移是离线操作，迁移期间相关 VM 不可用。必须在业务低峰期执行，且需要提前通知业务方。不要在生产时段做卷间迁移。

9.6.3 迁移决策清单

在执行卷间迁移前，管理员应该确认：

检查项	目的
目标卷剩余容量足够	避免迁移后目标卷过满
业务时段确认	在业务低峰期执行
VM 数据已备份	迁移失败时可回滚
通知业务方	业务方需提前知晓中断窗口

9.7 删除保留期

保留期的关键参数：

参数	含义	取值范围
保留期	已删除账户在物理盘上的保留时间	0~9999 天（默认 15 天）
"0" 表示立即不保留	删除后立即释放物理空间	0 = 无保留期
按区域定义	每个区域独立配置保留期	—
以天为单位定义	不支持小时 / 分钟粒度	—

L0 版本事实：保留期默认 15 天，可在管理员门户调整到 0~9999 天范围内的任意值。

9.7.1 保留期的实务含义

保留期设置	含义	适用场景
0 天	删除账户立即释放物理空间（无保留）	严格存储效率优先场景
1~7 天	短期保留，主要应对误删除	通用场景
15 天（默认）	中期保留，覆盖多数误删恢复需求	默认配置
30~90 天	长期保留，符合合规要求	合规要求严格的行业
>90 天	超长保留，存储成本显著上升	极少使用

L3 最佳实践：保留期越长，物理存储成本越高（删除的账户数据继续占用三副本空间）。建议根据业务实际需求设置保留期，不要无脑使用最大值。

9.7.2 强制立即回收（管理员动作）

管理员可以选择"立即回收"已删除账户的容量——这绕过了保留期：

动作	效果	风险
等保留期自动回收	数据保留期内可恢复	占物理容量
强制立即回收	立即释放物理容量	不可恢复

运维红线：强制立即回收是不可逆操作——一旦执行，已删除账户无法恢复。必须确认业务方没有恢复需求后才能执行。

9.8 容量管理的常见误判信号

误判	真相	排查建议
"存储账户已删除，容量应该释放了"	删除账户还在保留期内，物理容量未释放	检查保留期配置 + 强制回收
"租户配额满了就是 Scale Unit 满了"	租户配额满只是租户视角上限，管理员可调整 Plan / Offer	区分租户配额 vs Scale Unit 物理容量
"卷使用率 90% 是告警"	告警阈值因版本 / 配置而异	检查当期版本告警阈值配置
"卷间迁移可以热迁移"	当前只支持离线迁移	必须 VM 停机
"保留期 0 = 立即删除账户"	0 = 立即释放物理容量，账户本身不可恢复	区分"账户删除" vs "容量释放"

10. 运维红线与下篇小结

10.1 容量管理运维红线

红线	原因
不要在生产时段做卷间迁移	离线迁移导致 VM 不可用
不要绕过 Plan / Offer 配额	破坏多租户治理
不要假设保留期默认是某个固定值	默认 15 天可配置，要确认当期配置
不要把托管磁盘转换 cmdlet 当作 Azure 等价工具	Azure Stack Hub 上 `ConvertTo-AzVMManagedDisk` 不可用
不要假设 Premium SSD 有性能保证	Azure Stack Hub 上是 cap（上限），不是 provisioned（保证）
不要假设 Azure 公有云的存储性能在 Azure Stack Hub 上线性对应	必须实测，不能假设
不要假设单 Blob 上限是固定值	5 TB 是当前硬上限，未来版本可能变化
不要假设 Table 存储可无限扩展	单表受限于单个表服务器数据库的事务速率

10.2 下篇小结

本篇以 Azure Stack Hub 存储服务管理为主线，完成了从托管磁盘到容量管理的完整图谱。

核心要点回顾：

托管磁盘自 azs-1808 起是默认：创建 VM 时默认使用托管磁盘，把"存储账户"中间层对租户屏蔽
托管磁盘与 Azure 公有云的差异明确：最大 1023 GiB / BitLocker 加密 / 2300 IOPs & 145 MB/s cap（不是保证）/ 多个功能尚未支持
Blob 上传两种模式清晰：单次 PutBlob（≤256 MB）适合小对象；PutBlockList（最多 50,000 块 × 100 MB = 5 TB）适合大对象
Table 存储伸缩边界明确：PK + RK 最大 800 字节；单表受限于单个表服务器数据库的事务速率
Queue 是轻量级消息队列：64 KB 消息大小，不替代 Service Bus / Event Hubs / Kafka
容量管理五类动作明确：分配 / 监控 / 配额 / 迁移（离线）/ 保留（默认 15 天，可配 0~9999 天）