Azure Stack Hub 容量规划指南（下篇：实战踩坑 / 工具 / 监控 / 扩展 / 对比）

未经同意，请勿转载！

文档版本：v1.1-R3（2026-07-18，与上篇 v1.2-R3 同步审校） 核心来源：Microsoft Learn（azs-2604）+ Dell AS-760 公开支持矩阵 + 实际部署经验整理 写作原则：本文采用四层技术事实分类方法——① Azure Stack Hub / Microsoft 官方硬性要求 ② OEM 合作伙伴实现与默认行为 ③ 企业容量规划最佳实践 ④ L0：版本事实（所有数字标注对应 Azure Stack Hub 版本 azs-XXXX，版本变化时数字可能失效）。

v1.1-R3 主要修订（针对 v1.1 反馈，本轮与上篇 v1.2-R3 同步）：

• ✅ §E.4 从"微软产品演进方向"重构为"三种产品的官方现状"——移除"微软投资方向"等未经官方公开声明的产品战略表述
• ✅ §E.4 删除"新建项目优先选 Azure Local"等基于产品战略推测的选型推荐
• ✅ §E.4.2 新增"产品定位 vs 产品战略"分层说明——明确本文回答技术事实，不替微软回答商业战略
• ✅ §E.4.3 重写"适用场景"为基于产品定位（而非基于微软战略推测）的参考表述
• ✅ 与上篇 §6.8 / §6.9 运营模式分析保持一致表述

v1.1 范围（下篇修订版）：

• §A 实战踩坑与最佳实践（计算 / 存储 / 网络 / IOPS / 方法论 8 类）
• §B Capacity Planner 实操指南（从需求反推 + 从硬件出发）
• §C 容量监控与预警阈值（70% / 85% 阈值策略）
• §D 多 scale unit / 多 stamp 扩展（节点添加 / scale unit / stamp 边界）
• §E Azure Stack Hub vs Azure Stack HCI vs Azure Local 对比
• §F 引用清单 + v1.x 修订记录

配套文档：Azure Stack Hub 容量规划指南（上篇：Microsoft 软件层公式 + Dell AS-760 OEM 视角）

0. 阅读地图

┌──────────────────────────────────────────────────────────────────────────┐
│ Azure Stack Hub 容量规划下篇全景 │
├──────────────────────────────────────────────────────────────────────────┤
│ │
│ 上篇（已发布）： │
│ §1 容量规划总览 + 三层原则 + 三产品边界 │
│ §2 计算容量公式（N+1 容错、储备容量、FD、批处理） │
│ §3 存储容量公式（S2D 三镜像、VmTemp、ACS） │
│ §4 VM Size / IOPS（L0 版本事实 + OEM 实现） │
│ §5 网络与数据中心集成（5 逻辑网络、ToR、2% 流量类别预留） │
│ §6 Dell AS-760 集成系统视角（OEM SKU 边界 + AS-760 容量模型） │
│ │
│ 本篇（下篇）： │
│ §A 实战踩坑与最佳实践 → 怎么避免常见错误 │
│ §B Capacity Planner 实操 → 怎么用 aka.ms/azstackcapacityplanner │
│ §C 容量监控与预警 → 怎么知道什么时候要扩容 │
│ §D 多 scale unit / 多 stamp 扩展 → 怎么扩展 │
│ §E 三种产品对比 → 什么时候选 Azure Stack Hub / HCI / Local │
│ │
│ 阅读建议： │
│ 容量规划初期 → 先读 §B（工具实操） │
│ 容量落地前 → 读 §A（避免踩坑） │
│ 扩容决策 → 读 §C（预警阈值）+ §D（扩展路径） │
│ 产品选型 → 读 §E（横向对比） │
│ │
└──────────────────────────────────────────────────────────────────────────┘

§A. 实战踩坑与最佳实践

本章全部为 L3 企业最佳实践，非微软官方承诺。来源：实际部署经验 + 第三方 PoC 报告 + OEM 工程师反馈 + Azure Stack Hub 用户社区案例。仅作参考，具体决策需结合业务场景。

A.1 计算容量常见踩坑

A.1.1 【常见错误】"内存除以节点数就得到每节点可用"

v1.0 错误示例：

• 12 节点 × 768 GB = 9216 GB
• 错误结论：每节点 ~768 GB 可用
• 实际：每节点 ~576 GB 可用（按 N+1 容错 + 15% OS 保留 + 基础设施占用）

【最佳实践】：

• 永远用 Microsoft 公式计算（上篇 §2.4）：((N-1)×M – (268+4N)) × 0.85 / N
• 永远预留 30% 缓冲：微软公式算出的"可用容量"是理论上限，实际不要打满
• 永远做 PoC 验证：公式算的是"Azure Stack Hub 软件层上限"，实际受 OEM 固件、S2D 行为、NUMA 拓扑等影响

A.1.2 【常见错误】"vCore 没限制，我可以 overcommit"

v1.0 措辞风险：写"不要 overcommit" 容易让读者误以为是 Azure Stack Hub 限制。

【实际】：

• Azure Stack Hub 本身不强制禁止 vCPU overcommit
• Hyper-V 技术上支持 vCPU overcommit（多个 VM 共享 1 个物理 Core）
• 但：vCPU 满载时 VM 性能不可预测地下降，生产环境通常不开 overcommit

【最佳实践】：

• 生产环境不开 vCPU overcommit（非 Azure Stack Hub 限制，是生产建议）
• Dev/Test 环境可以按需 overcommit（如 1.5x – 2x）
• 监控：用 Get-VM | Get-VMProcessor 检查 VM 的 vCPU 配置，结合 Hyper-V Hypervisor Virtual Processor\\CPU Wait Time Per Dispatch 性能计数器判断 overcommit 是否合理

A.1.3 【常见错误】"GPU VM 放在可用性集里应该能 HA"

【实际】：

• 【微软硬要求】 GPU VM 不参与 Live Migration
• 节点 GPU 故障时 GPU VM 直接宕机
• 可用性集对 GPU VM 仅"尽力而为"（best-effort）

【最佳实践】：

• GPU 训练任务自带 checkpoint（断点续训）
• 不要把 GPU VM 放在可用性集里指望 HA
• 重要 GPU VM 在更新窗口期主动关机（Live Migration 会失败）
• 关键 GPU 工作负载考虑双节点 GPU 备份（每节点独立 GPU，业务层做冗余）

A.1.4 【常见错误】"一次创建 200 个 VM 应该没问题"

【实际】：

• 【微软硬要求】 每次最多 40 个 VM 同时创建，间隔 5 分钟（上篇 §2.7）
• 触发原因：S2D RDMA 网络 + Storage Pool 在大并发配置时元数据操作压力大

【最佳实践】：

• 自动化脚本创建 VM 时强制加 5 分钟 sleep
• 不要试图用 ARM 模板并发创建数百个 VM
• 紧急扩容场景（如促销日）提前批量化预创建
• 创建大量 VM 期间避免触发 update bundle（更新会强制 Live Migration，可能与新 VM 创建冲突）

A.1.5 【常见错误】"我把 VM 都放在一个可用性集里，性能应该更好"

【实际】：

• 可用性集只影响故障域分布，不影响性能
• 同一可用性集的 VM 强制分布在不同 FD（最大 3 FD）
• 单 FD 内 VM 数量过多反而降低 Live Migration 成功率

【最佳实践】：

• 单可用性集 VM 数 不超过节点数 × FD 数（如 12 节点 × 3 FD = 36 VM 上限）
• 重要业务 VM 用专用可用性集，避免与 Dev/Test VM 混部
• 不要为了"性能"把所有 VM 放在一个可用性集

A.2 存储容量常见踩坑

A.2.1 【常见错误】"ACS 容量看起来很大，应该够用"

【实际】：

• ACS 承担：
  • 租户对象存储（Blob / Table / Queue）
  • 诊断日志（每 VM 默认每天产生诊断日志）
  • 镜像仓库（VHD / VHDX）
  • 备份（Infrastructure Backup 默认每天）
  • Kubernetes 持久卷（AKS on Azure Stack Hub）
  • App Service / Functions / SQL RP 等 PaaS 内部数据

【最佳实践】：

• ACS 容量规划至少预留 30% 给"未预期的对象存储增长"
• 定期清理诊断日志（默认保留期可调整，【微软硬要求】 不要超过 90 天）
• 备份定期清理过期备份（保留期可调整）
• 监控 ACS 使用率（Get-AzsStorageQuota）

A.2.2 【常见错误】"临时盘（VmTemp）10% 够了"

【实际】：

• 大数据 / SQL ETL / 视频转码任务经常用临时盘作为 scratch 空间
• VmTemp 默认按物理内存 × 0.65 × 8 计算，可能远超过实际需要
• 【微软硬要求】 VmTemp 上限 10% 总容量，超过会被截断

【最佳实践】：

• 业务大量使用临时盘时，主动降低 VM 内存（反直觉但合规）
• 或将大数据 scratch 放到 ACS 而非 VmTemp（容量更大、跨节点共享）
• 监控临时盘使用率（Get-AzsVM | Get-VMHardDiskDrive | ?{$_.Name -eq "D:"}）

A.2.3 【常见错误】"临时盘是 SSD 性能应该很高"

【实际】：

• Azure Stack Hub 的 VmTemp 是 S2D 三镜像上的虚拟磁盘，不是本地 NVMe 直通
• 性能受 S2D 存储池整体 IOPS 影响，远低于本地 NVMe

【最佳实践】：

• 对延迟敏感的工作负载，使用带本地 NVMe 临时盘的 SKU（如 Lsv2 系列，【OEM 实现】）
• Lsv2 在 Azure Stack Hub 上仅部分 OEM 支持，Dell AS-760 Support Matrix 需具体核实
• 一般 VM 临时盘用于非性能敏感的 scratch / 页面文件 / 中间结果

A.2.4 【常见错误】"BitLocker 加密对性能影响可以忽略"

【实际】：

• BitLocker 加密消耗少量 CPU（典型 3–5%，【OEM 实测】）
• 增加内存使用（BitLocker metadata）
• 影响 S2D 写性能（写前加密 → 三镜像 → 解密读取）

【最佳实践】：

• CPU 密集型工作负载预留 5% vCore 给 BitLocker
• 存储密集型工作负载预留 10% 存储 IOPS 给 BitLocker 开销
• 不要尝试关闭 BitLocker（【微软硬要求】 BitLocker 全卷加密不可关闭）

A.2.5 【常见错误】"S2D 三镜像后容量够用"

【实际】：

• 三镜像 = 1 TB 写入需要 3 TB 物理容量
• 实际物理容量 = 原始容量 × 2/3
• 再扣 VmTemp（10%）、Infrastructure（3.5 TB）、每节点 1 容量盘保留
• BitLocker 开销 ~5–10%
• 实际 ACS 可用 ≈ 物理容量 × 0.55 – 0.60

【最佳实践】：

• 永远按"实际 ACS 可用 ≈ 物理容量 × 0.55"做粗算
• 详细算用 Microsoft 公式（上篇 §3.6）

A.3 网络容量常见踩坑

A.3.1 【常见错误】"Public VIP /24 子网有 254 个 IP，足够"

【实际】：

• 【微软硬要求】 254 − 31（基础设施）− 16（Azure 保留）= 207 个 VIP 可用
• 每个租户 VM 至少配 2 个 VIP（主备 / 负载均衡）
• 207 个 VIP 实际仅能服务 ~100 个 VM

【最佳实践】：

• 业务量预估时按"每 VM 2 个 VIP" 计算
• 早期部署用 /24，未来扩展改 /23 或 /22（【微软硬要求】 最大 /22 = 1022 hosts）
• 不要假设 VIP 是"无限"的——Azure Stack Hub 不像 Azure 公有云有全球 VIP 池

A.3.2 【常见错误】"S2S VPN 100-200 Mbps 够了"

【实际】（v1.1 已修正）：

• 【L0 版本事实】 VPN 性能取决于 VPN Gateway SKU、加密算法、CPU，没有固定带宽数字
• Azure Stack Hub 上的 S2S VPN 通常低于 Azure 公有云 VPN Gateway 性能（受限于 Azure Stack Hub 自身的资源）
• 备份 / 数据库同步 / 大文件传输容易超过 S2S VPN 实际可用带宽

【最佳实践】：

• 核心业务数据同步用 ExpressRoute（性能可控、有 SLA）
• S2S VPN 仅作管理通道 / 备份通道 / 低流量业务
• 不要依赖 S2S VPN 做实时数据同步
• 监控 VPN 性能：Get-AzsVirtualNetworkGatewayConnection + Get-AzsNetworkUsage

A.3.3 【常见错误】"5 个逻辑网络可以放在一个 /16 里"

【实际】：

• 【微软硬要求】 5 个子网不能重叠
• 必须为未来 5 年扩展留余量
• 跨数据中心 / 跨 stamp 不能复用

【最佳实践】：

• 每个子网按"当期 2 倍、5 年 4 倍"规划
• /20 Private 子网每个 scale unit 独立（不跨 scale unit 复用）
• /24 Infrastructure 子网全 stamp 共享（PEP / 备份）
• 记录所有已用 IP 段，避免扩展时冲突

A.4 VM IOPS 常见踩坑

A.4.1 【常见错误】"高级 SSD 有 2300 IOPS，足够我数据库用"

【实际】（v1.1 已修正）：

• 【L0 版本事实】 当前版本每个数据盘约 2300 IOPS 上限（数值随 azs 版本演进变化，以当期 Microsoft Learn azure-stack-vm-sizes 页面为准）
• 数据库如果用多个数据盘不会自动聚合
• IOPS 限制来自 ① Disk SKU ② VM Size ③ azs 版本 ④ Storage RP ⑤ OEM 实际配置
• 历史版本可能存在不同数字，不应作为当前规划依据

【最佳实践】：

• 使用 Windows Storage Spaces（VM 内部）或 Linux mdadm 做条带化（striping）以聚合 IOPS
• 多个数据盘 + striping 配置 = 多盘 IOPS 之和
• 监控：Get-PhysicalDisk | Get-Disk | Get-Partition + Get-Counter "\\PhysicalDisk(*)\\Disk Reads/sec,Disk Writes/sec"

A.4.2 【常见错误】"Azure 公有云的 Premium Storage v2 也能用"

【实际】：

• Azure Stack Hub 当前版本未集成 Premium Storage v2 和 Ultra Disk
• 【L0 版本事实】 Premium Storage v2 / Ultra Disk 在 Azure 公有云是公开预览 / GA 状态，但 Azure Stack Hub 集成与否取决于当期版本 + OEM 实现
• 历史版本曾存在不同支持范围；未来版本可能新增支持——以官方公告为准

【最佳实践】：

• 不要在容量规划中假设未来会支持 v2
• 高 IOPS 需求用多盘 striping（不要等 v2）
• 高吞吐需求用多个 P30 数据盘 + 临时盘

A.4.3 【常见错误】"VM Size 越大，磁盘 IOPS 越高"

【实际】：

• VM Size 决定最大挂盘数和最大 uncached IOPS 总和
• 但单盘 IOPS 上限不变（500 / 2300）
• D64_v3 64 vCPU / 32 数据盘 = 32 × 500 = 16000 IOPS（【L0 版本示例】）

【最佳实践】：

• 高 IOPS 需求先用多盘 striping，再考虑 VM Size 升级
• 监控 Get-Counter "\\Hyper-V Virtual Storage Device(*)\\Read IOPS,Write IOPS" 看 VM 实际拿到的 IOPS

A.5 方法论踩坑

A.5.1 【常见错误】"算完容量就直接上线"

【实际】：

• 微软 Capacity Planner 不作官方承诺
• OEM Support Matrix 可能与你部署的 azs 版本不完全对齐
• 实际容量受 NUMA 拓扑、固件版本、S2D 行为影响

【最佳实践】：

• 永远预留 30% 容量缓冲
• 永远监控容量使用率：> 70% 触发预警，> 85% 触发扩容

A.5.2 【常见错误】"我买 16 节点 Scale Unit 就完事了"

【实际】：

• 【OEM 实现】 单个 Scale Unit 16 节点是上限
• 超过 16 节点必须多 scale unit 或 多 stamp
• 多 scale unit / 多 stamp 增加管理复杂度

【最佳实践】：

• 永远准备扩展路径：
  • 路径 1：scale unit 内扩节点（4 → 16）
  • 路径 2：新增 scale unit（同 stamp）
  • 路径 3：新建 stamp（同数据中心）
  • 路径 4：新建 stamp（新数据中心，多区域灾备）
• 业务增长时逐路径评估（成本 / 复杂度 / SLA）

A.5.3 【常见错误】"Azure Stack Hub 容量规划等同于 Azure Stack HCI / Azure Local"

【实际】（v1.1 已修正）：

• Azure Stack Hub 是 OEM Appliance，不能自由配置
• Azure Stack HCI / Azure Local 是 Validated Node + 自由组合
• 容量规划方法不同：
  • Azure Stack Hub：业务需求 → Capacity Planner → OEM 认证 SKU → 节点数
  • Azure Local：业务需求 → Validated Node 选型 → 自由 BOM → Capacity Planner 验证

【最佳实践】：

• 选型前先读 §E 的对比
• 不要把 Azure Local 的容量规划经验直接套用到 Azure Stack Hub

§B. Capacity Planner 实操指南

B.1 工具概览

官方工具：Azure Stack Hub Capacity Planner（aka.ms/azstackcapacityplanner）

B.2 两种使用方式

B.2.1 从硬件出发（推荐初期）

步骤：

步骤 1：下载 Capacity Planner Excel。
步骤 2：在 "Hardware Configuration" 工作表选择 OEM SKU（如 Dell AS-760 8 节点）。
步骤 3：填写单节点内存 / 存储配置（参考 OEM Support Matrix）。
步骤 4：在 "VM Configuration" 工作表填入要部署的 VM 组合。
步骤 5：观察 "Capacity Summary"：
– CPU 利用率
– 内存利用率
– 存储利用率
– VM 总数
步骤 6：如果某资源超过 100%，尝试调整 VM 组合 / 节点数。
步骤 7：导出 Capacity Planner 结果，作为 PoC 申请依据。

B.2.2 从工作负载出发（推荐业务主导）

步骤：

步骤 1：整理业务 VM 清单：
– VM 数量 / vCPU / 内存 / 磁盘 / 网络
– 业务增长预测（6 / 12 / 24 / 36 个月）
步骤 2：在 "Workload Configuration" 工作表填入 VM 清单。
步骤 3：观察 "Recommended Hardware"：
– 推荐的 OEM SKU
– 推荐的节点数
步骤 4：与 OEM 沟通，确认推荐 SKU 在 Support Matrix 中。
步骤 5：考虑业务增长，重新计算 12 / 24 / 36 月容量需求。
步骤 6：选择满足"未来 24 个月"的最小 SKU。
步骤 7：导出报告，作为 OEM 询价依据。

B.3 Capacity Planner 不覆盖的事项

备注：Azure Stack Hub基本不太可能有与客户完全一致硬件的POC的场景与机会。

B.4 Capacity Planner 使用陷阱

【最佳实践】：

• 永远把 Capacity Planner 结果当作初稿
• 永远与 OEM Support Matrix 对齐

§C. 容量监控与预警阈值

C.1 监控维度

C.2 预警阈值（【最佳实践】）

阈值非微软官方承诺，基于实际部署经验整理。

C.3 监控脚本示例（【L3 示例，非官方承诺】）

C.3.1 PEP 上查看 Scale Unit 整体容量

# 在 Privileged Endpoint (PEP) 上执行

# 查看 Scale Unit 节点
Get-AzsScaleUnitNode | Select-Object Name, ScaleUnit, Status

# 查看 Scale Unit 总体容量
Get-AzsScaleUnit | Select-Object Name, TotalMemoryGB, AvailableMemoryGB, TotalvCore, AvailablevCore

# 查看 ACS 容量
Get-AzsStorageQuota | Select-Object Location, Name, CapacityGB

# 查看 VM 数
Get-AzsVM | Measure-Object

C.3.2 监控告警配置（【最佳实践】）

# 创建 Azure Monitor 告警规则示例（azs-2301+）

# 1. 监控 ACS 容量 > 70%
New-AzAlertRule -ResourceGroup "system.local" `
-TargetResourceId "/subscriptions/xxx/resourceGroups/system.local/providers/Microsoft.AzureStackHCI/storageSubSystems/xxx" `
-MetricName "UsedCapacityPercent" `
-Operator GreaterThan `
-Threshold 70 `
-WindowSize "00:05:00" `
-Description "ACS capacity > 70%"

# 2. 监控 Scale Unit 内存 > 85%
New-AzAlertRule -ResourceGroup "system.local" `
-TargetResourceId "/subscriptions/xxx/resourceGroups/system.local/providers/Microsoft.AzureStackHCI/scaleUnits/xxx" `
-MetricName "AvailableMemoryPercent" `
-Operator LessThan `
-Threshold 15 `
-WindowSize "00:05:00" `
-Description "Available memory < 15%"

【L0 警告】：监控脚本和告警规则的具体命令随 azs 版本变化，以当期官方文档为准。

C.4 容量扩容决策树

容量监控触发预警（黄色 / 红色）
│
↓
检查：哪个资源超限？
│
┌────┼────┐
↓ ↓ ↓
CPU 内存 存储
│ │ │
↓ ↓ ↓
1. 业务优化（清理 / 释放）
2. VM 规格降级
3. VM 迁移到其他 stamp
│
↓ 仍不满足
│
扩展路径：
– 路径 1：scale unit 内扩节点（4 → 16）
– 路径 2：新增 scale unit（同 stamp）
– 路径 3：新建 stamp（同数据中心）
– 路径 4：新建 stamp（新数据中心）

【最佳实践】：

• 优先业务侧优化（清理 / 重构），再考虑基础设施扩展
• 单资源超限优先走路径 1（最便宜）
• 多资源超限走路径 2 / 3
• 跨数据中心灾备走路径 4

§D. 多 scale unit / 多 stamp 扩展

D.1 Scale Unit 节点添加（Scale Out）

D.1.1 微软官方流程

前提条件（【微软硬要求 + OEM 实现】）：

• 新节点必须与现有节点完全同型同配（CPU、内存、缓存盘、容量盘）
• 新节点 firmware baseline 必须与现有节点一致
• 当前 scale unit 节点数 < 16

流程：

1. 通过 OEM 订购新节点（同型号）
2. OEM 预配置硬件（固件 / BIOS / 网络）
3. OEM 工程师现场 / 远程上架
4. 通过 PEP 添加节点：
Add-AzsScaleUnitNode -NodeName "NewNode01"
5. 验证 S2D pool 自动重平衡
6. 验证 N+1 后所有 VM 仍在可用性集内
7. OEM 工程师完成支持交接

D.1.2 时间窗口与影响

D.2 新增 Scale Unit（同 stamp 内）

D.2.1 适用场景

• 单 scale unit 已达 16 节点上限
• 需要进一步扩展容量
• 同一 Azure 资源管理器 + 计量 + 备份基础设施

D.2.2 限制（【OEM 实现】）

• 【OEM 实现】：Dell / HPE / Lenovo 各 OEM 对"单个 stamp 最大 scale unit 数"有不同上限（典型 4 个）
• 多个 scale unit 共享：
  • Azure 资源管理器（ARM）
  • 计费 / 计量
  • 备份基础设施
  • 租户门户
• 多个 scale unit 不共享：
  • S2D 存储池
  • 网络 ToR 交换机
  • 物理数据中心位置（同一数据中心但不同机柜）

D.2.3 拓扑示意

┌─────────────────────────────────────────────────┐
│ Azure Stack Hub Stamp（单数据中心） │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────┐│
│ │ Scale Unit 1 │ │ Scale Unit 2 │ │ SU 3/4 ││
│ │ 4-16 节点 │ │ 4-16 节点 │ │ … ││
│ │ │ │ │ │ ││
│ │ S2D Pool #1 │ │ S2D Pool #2 │ │ … ││
│ │ ToR Switch #1│ │ ToR Switch #2│ │ … ││
│ └──────────────┘ └──────────────┘ └────────┘│
│ ↓ ↓ ↓ │
│ ┌─────────────────────────────────────────┐ │
│ │ Azure 资源管理器 + 计量 + 备份基础设施 │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘

D.3 新建 Stamp（同数据中心或跨数据中心）

D.3.1 适用场景

• 单 stamp 已达 scale unit 上限（如 4 个）
• 需要多区域灾备（同数据中心不同 stamp 仍是单点）
• 业务隔离（不同 BU / 不同合规要求）

D.3.2 关键差异（vs scale unit / 多 scale unit）

D.3.3 跨 Stamp 网络连接

【微软硬要求】：跨 Stamp 通信仅支持：

• ExpressRoute（推荐，企业专线）
• S2S VPN（管理通道 / 低流量业务）
• Outbound NAT（仅出站，不推荐用于跨 Stamp 业务）

D.4 扩展路径决策表（【最佳实践】）

§E. Azure Stack Hub vs Azure Stack HCI vs Azure Local 对比

E.1 产品定位对比

E.2 容量模型对比（v1.1 强化）

v1.1 强化：呼应上篇 §6.8，本节从"容量模型"角度对比三种产品，而不仅是"容量计算步骤"。

E.3 选型决策树

问 1：业务是否需要 Azure IaaS/PaaS 完整功能（含 App Service / SQL RP）？
│
├─ ✅ 是
│ ↓
│ 问 2：业务是否在严格监管 / 数据主权 / 气隙环境？
│ │
│ ├─ ✅ 是 → 选 Azure Stack Hub
│ └─ ❌ 否 → 评估是否用 Azure 公有云（合规外）
│
└─ ❌ 否（只需 IaaS）
↓
问 3：业务是否需要 Hyper-V + S2D + Arc 一致体验？
│
├─ ✅ 是
│ ↓
│ 问 4：硬件 BOM 自由度需求？
│ │
│ ├─ 🟢 高（接近自由）→ Azure Local
│ └─ 🟡 中（Validated Node 范围）→ Azure Stack HCI / Azure Local
│
└─ ❌ 否 → 评估 VMware vSphere / Nutanix / 其他

E.4 三种产品的官方现状（截至本文对应版本）

⚠️ v1.2-R3 重要修订：下篇原 §E.4 以"微软产品演进方向"为标题，列出"Azure Stack Hub 稳定维护不发展新功能"、"Azure Local 重点投资方向"等表述，并给出"新建项目优先选 Azure Local"等选型推荐。这些表述存在两个问题：

• 未区分"产品定位"与"产品战略"：产品定位（云服务运营 vs 基础设施运维）是技术层面的事实，产品战略（微软投资方向）是商业层面的判断，本文不应越界。
• 选型推荐基于未经微软公开声明的产品战略判断：微软至今未公开发布任何关于 Azure Local 将替代 Azure Stack Hub 的声明。

v1.2-R3 把本节重构为"官方现状"事实陈述 + "运营模式区别"机制说明，不给出选型推荐。

E.4.1 截至本文对应版本可确认的官方事实

重要：截至本文发布时，微软官方未宣布 Azure Local 将全面替代 Azure Stack Hub，也未发布 Azure Stack Hub 的停止支持（End of Support）或官方迁移路线图。因此，两者应视为并行发展的产品线，具体产品选择应结合官方支持矩阵、业务需求、运营模式要求等因素综合评估，而不应简单理解为替代关系。

E.4.2 产品定位 vs 产品战略

很多读者会把"产品定位"与"产品战略"混为一谈，但二者层次不同：

• 产品定位（技术事实）：Azure Stack Hub 是面向租户的云服务运营平台，Azure Local 是面向基础设施的资源管理平台——这是产品设计层面的事实，不随微软投资方向变化而变化。详见上篇 §6.9 Operating Model 本质区别。
• 产品战略（商业判断）：微软未来对哪个产品投入更多资源、哪个产品更长期——这是商业层面的判断，本文不替微软回答。

E.4.3 适用场景参考

基于产品定位（而非基于微软战略推测），可参考的适用场景：

本文不基于"微软投资方向"给出选型推荐——这是产品战略层面的问题，本文不替微软回答。具体产品选择应结合官方支持矩阵、业务需求、运营模式要求综合评估。

E.5 容量规划迁移路径（Azure Stack Hub → Azure Local）

【最佳实践】：

【L0 警告 + v1.1 收紧】：迁移路径不简单——Azure Stack Hub 与 Azure Local 的 API / 工具链 / 网络模型有差异，需详细评估。 上表的"6 个月 / 3-6 个月 / 6-12 个月 / 12 个月"是经验参考值，具体迁移周期取决于：业务规模 / 数据量 / 合规要求 / 业务中断窗口容忍度，实际项目应单独评估。

§F. 引用清单 + v1.x 修订记录

F.1 微软官方核心文档

F.2 微软官方工具

F.3 OEM 资料

F.4 配套阅读