Azure Stack Hub 容量规划指南(上篇：Microsoft 软件层 + 架构原理)

XUHUOJUN2026-07-19 11:59

未经同意，请勿转载！

文档版本 :v1.2-R2(2026-07-17 第二轮深度审校版) 核心来源校对 :Microsoft Learn azure-stack-capacity-planning-compute / azure-stack-capacity-planning-storage / azure-stack-vm-sizes / azure-stack-datacenter-integration / azure-stack-network / azure-stack-connection-models(azs-2604) 辅助来源 :Dell Technologies Azure Stack Hub Support Matrix(公开部分)+ Dell 16G AS-760 公开文档 写作原则 :本文采用四层技术事实分类方法 --1 Azure Stack Hub / Microsoft 官方硬性要求 2 OEM 合作伙伴实现与默认行为 3 企业容量规划最佳实践 4 L0:版本事实(所有数字标注对应 Azure Stack Hub 版本 azs-XXXX,版本变化时数字可能失效)。

0. 阅读地图

复制代码 
┌──────────────────────────────────────────────────────────────────────────┐
│               Azure Stack Hub 容量规划全景(一图)                          │
├──────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  Stamp(数据中心级:1+ 个独立 Azure Stack Hub 部署)                          │
│  └─ Scale Unit(4-16 节点,由 OEM 认证 SKU 决定具体配置)                     │
│      ├─ 物理资源:CPU / Memory / NVMe+SSD or NVMe+HDD                      │
│      ├─ 逻辑网络:Public VIP / BMC / Switch / Infra / Private              │
│      └─ 软件栈:Windows Server 2022 + Hyper-V + S2D + Azure Stack Hub      │
│                                                                          │
│  容量规划要回答三件事:                                                     │
│    1 我能开多少 VM?       → Compute 公式                                   │
│    2 我能存多少数据?      → Storage 公式 + ACS 公式                         │
│    3 我能给 VM 多少 IOPS? → VM Size 矩阵(按 SKU + 版本决定)                 │
│                                                                           │
│  容量规划的两层现实约束(重要):                                              │
│    L0:版本事实        ─→ 数字随 azs-XXXX 版本变化                           │
│    L2:OEM SKU 边界    ─→ 不是客户要什么 OEM 就配什么                        │
│                                                                          │
│  微软提供的官方容量规划工具:                                                │
│    https://aka.ms/azstackcapacityplanner  (Excel 容量规划电子表格)         │
│    注:微软明确声明"该工具不作官方承诺"                                      │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘

章节地图(上篇):

  • §1 Azure Stack Hub 容量规划总览(先讲清楚"为什么容量不是简单加法")
  • §2 计算容量规划(微软官方公式 + N+1 容错 + 故障域 + 批处理)
  • §3 存储容量规划(S2D 三镜像 + VmTemp + ACS 公式)
  • §4 VM 规格与磁盘 IOPS 矩阵(【OEM/版本实现】,不是微软硬要求)
  • §5 网络与数据中心集成(【微软硬性】 + 推荐做法)
  • §6 Dell AS-760 集成系统视角(OEM SKU 边界,含 AS-760 容量规划示例)
  • §7 引用清单 + v1.1 修订记录

1. Azure Stack Hub 容量规划总览

1.1 为什么容量不是"组件简单相加"

微软官方文档明确指出:

"Unlike a traditional virtualization solution, the simple arithmetic of these components to determine usable capacity doesn't apply. The first reason is that Azure Stack Hub is architected to host the infrastructure or management components within the solution itself. The second reason is that some of the solution's capacity is reserved in support of resiliency by updating the solution's software in a way that minimizes disruption of tenant workloads." (learn.microsoft.com, azure-stack-datacenter-integration)

翻译成可执行的三句话:

  1. 基础设施自己吃一份:Hyper-V host、Storage Spaces Direct、SLB、监控 / 备份 / PEP 等基础组件本身就要占用 CPU / 内存 / 存储。这意味着你买的 N×M vCore,实际能分给租户的可能远低于 N×M(具体公式见 §2)。
  2. 更新 / 故障时也要预留一份 :Azure Stack Hub 是"封装的"(sealed)系统,OEM + 微软会推送整体更新(Update Bundle),更新期间或单个节点故障时必须能容纳租户 VM 在剩余节点上 Live Migrate 不中断,所以要预留一台服务器容量的冗余(N+1 容错)。
  3. 每个 OEM 的硬件配置不同 :节点数、CPU 型号、单节点内存、单节点 NVMe / SSD / HDD 组合都是 OEM 认证 SKU 决定的(典型如 Dell 16G AS-760 Scale Unit、HPE ProLiant DL 系列、Lenovo ThinkSystem SR 系列)。OEM 不接受客户自由 BOM 配置--这是 Azure Stack Hub 与普通虚拟化集群、Azure Stack HCI Validated Node 的核心区别(详见 §6.1)。

1.2 容量规划的两个维度

容量规划在 Azure Stack Hub 上需要回答两个独立但相互制约的问题:

|----------|--------------------------|-------------------------------------------------------|
| 维度 | 关键问题 | 主要约束 |
| 计算容量 | 能开多少 VM?CPU / 内存够不够? | Hyper-V host 的 vCPU / 内存;故障域;GPU VM 不参与 HA |
| 存储容量 | 能存多少数据?每个 VM 能拿到多少 IOPS? | S2D 三镜像 + BitLocker + ReFS;VM Size + 版本共同决定单盘 IOPS 上限 |

注:Azure Stack Hub 没有"网络容量"维度的硬上限(受限于 ToR 上行带宽,详见 §5.3),但 SLB 的吞吐量、Public VIP 数量等需要单独规划。

1.3 容量规划的两条入口路径

微软官方文档 azure-stack-datacenter-integration §"Capacity planning considerations" 给出的官方入口是:Azure Stack Hub Capacity Planner (https://aka.ms/azstackcapacityplanner)。

两种使用方式:

  • 从硬件出发:先选一个 OEM SKU(如 Dell AS-760),尝试往里塞各种 VM 组合,看是否能装下。
  • 从工作负载出发:先定好业务要跑什么 VM,反推需要哪个 OEM SKU + 多少节点。

重要 :微软同时声明: "The spreadsheet isn't intended to serve as a substitute for your own investigation and analysis. Microsoft makes no representations or warranties, express or implied, with respect to the information provided within the spreadsheet."

翻译:电子表格只作辅助决策 ,不作官方承诺。最终容量评估必须结合业务 PoC 和 OEM 厂商的硬件验证。

1.4 三层区分原则 + 版本事实层(贯穿全文)

本文严格区分以下四层技术事实,绝不混淆:

|----------------------|----------------------------------------------------------------------------------|-------------------|
| 层级 | 定义 | 文中标识 |
| L0:版本事实层 | 所有数字必须标注对应 Azure Stack Hub 版本(azs-XXXX)。版本变化时数字可能失效 | 【L0 azs-XXXX】 |
| L1:微软官方硬性要求 | Microsoft Learn 文档中以 must / required / not supported / maximum 等明确措辞声明的项 | 【微软硬要求】 |
| L2:OEM / 合作伙伴实现层 | Dell / HPE / Lenovo 等 OEM 在自家集成系统中的默认配置、推荐 SKU、官方支持的服务 | 【OEM 实现】 |
| L3:企业容量规划最佳实践 | 来自实际部署经验、PoC 数据、第三方测试的方法论(非微软官方背书) | 【最佳实践】 |

L0 的引入原因 :Azure Stack Hub 是持续演进的集成系统,不同版本之间容量限制可能变化(如 VM 数上限、FD 数、Batch VM 数量等都经历过版本调整)。任何"硬要求"都必须先问"哪个版本"。

1.6 容量规划三大误区("买了 ≠ 实际可得")

v1.2 新增 。在深入容量公式之前,先澄清 Azure Stack Hub 容量规划最大的误区--物理容量 ≠ 租户可用容量。

误区一:买了 1 PB 存储 ≠ 租户能用 1 PB

Azure Stack Hub 1 PB 原始容量在多层扣除后,给租户用的 ACS 容量只有约 28%-30%(参考 §3.6 示例):

复制代码 
原始物理容量(1 PB = 1024 TB)
    │
    ├─→ 每节点保留 1 容量盘(重建空间)        ≈ -7%
    ├─→ S2D 池剩除 1 容量盘后的容量            ≈ -7%
    └─→ 三路镜像实际可用(÷ 3)                ≈ ÷ 3 (-67%)
    │
    逻辑可用容量                              ≈ 307 GB
    │
    ├─→ Infrastructure 虚拟磁盘(3.5 TB)      ≈ -1%
    ├─→ VmTemp(上限 10% 总容量)              ≈ -10%
    ├─→ BitLocker 开销                         ≈ -5%
    └─→ ACS 可用                              ≈ ~ 250 GB

比喻:买了 1024 TB 原料肉,做成需要的菜 ≈ ~250 TB。

误区二:买了 1024 Core ≠ 可用 1024 vCPU
复制代码 
物理 Core(1024 Physical Core)
    │
    ├─→ Infrastructure VM (146 vCore)            -146
    ├─→ Hyper-V Host OS + Scheduler              (受 NUMA / SMT 影响)
    ├─→ VM Placement(FD / UD 约束)
    └─→ 每节点 VM 数限制(60 VM/node)× 节点数
    │
    租户粗略可用 vCore   ≈ 1024 - 146 - 多重叠加约束 = 不确定

重要 :"TotalPhysicalvCore - 146" 仅是粗算公式 。实际可部署 VM 的 vCPU 总和受 VM Size / NUMA / Placement 等多重影响,不是简单的 Core 减法。(详见 §2.4.4)

误区三:客户要什么 OEM 就配什么
复制代码 
客户需求(vCPU / 内存 / 存储)
    │
    └─→ Capacity Planner 反推
        │
        └─→ OEM 认证 SKU 集合中**最接近需求**的配置
            │
            ├─→ 可能超配(资源过剩)
            ├─→ 可能略不够(资源不足)
            └─→ 极少情况下精确匹配

Azure Stack Hub 是 Appliance 模式 --客户不能像普通服务器采购那样自由指定 BOM 。最终配置由 OEM 认证 SKU 集合中最接近需求的选项决定。这就是为什么容量规划不能只盯"我买了多少",而要关注"我实际能拿到多少 + 我未来怎么扩展"。(详见 §6.1)

1.5 Azure Stack Hub 与 Azure Stack HCI / Azure Local 的边界

这是常见的概念混用风险,必须在容量规划前澄清:

|-------------------------------------------------|-------------------------------------------|----------------------------------------------|-----------------------------------------|
| 产品 | 部署模式 | 硬件来源 | 容量规划边界 |
| Azure Stack Hub | OEM 集成系统(Integrated System Appliance) | OEM 认证 SKU 唯一(Dell AS-760 等),不接受客户自由 BOM | 由 OEM SKU + Microsoft 公式共同决定 |
| Azure Stack HCI(历史名称) | Validated Node(OEM 验证节点) | OEM 验证节点(多 SKU 可选) | 微软公式 + Validated Node 边界 |
| Azure Local(2024 起新名称 = Azure Stack HCI 演进) | Validated Node + 越来越灵活 | OEM Validated Node + 部分场景支持自建 | 微软公式 + Validated Node 边界,最接近传统 HCI 自由组合 |
| 普通 Hyper-V 集群 / VMware 集群 | 自由 BOM | 客户自由选择 | 无公式约束 |

关键区别 :Azure Stack Hub 是 appliance 模式,客户不能像普通服务器那样指定"2 颗 Xeon + 1 TB RAM + 24 块 SSD"这种 BOM;只能从 OEM 认证的 SKU 集合中选择最接近业务需求的容量组合(详见 §6)。

2. 计算容量规划

2.1 关键术语

|------------------------|-----------------------------------------------------------------------------------|----------|
| 术语 | 微软官方定义 | 通俗理解 |
| Stamp | 一个完整的 Azure Stack Hub 部署(1+ 个 scale unit 共享同一 ARM / 计量 / 备份基础设施) | 数据中心级别 |
| Scale Unit | 一个由 4-16 节点组成的故障域 + 计算 + 存储单元 | 机柜级别 |
| Node | 一个物理服务器(OEM 认证 SKU 提供,如 Dell AS-760 节点) | 单台服务器 |
| Resiliency Reserve | 微软为支持"更新 / 单节点故障时 Live Migration 不中断租户"而保留的一台服务器容量的冗余 (N+1 容错,不是 N-1 个节点) | 见 §2.3 |
| Infra Overhead | 微软自留用于承载基础设施组件(Hyper-V host、SLB、监控、PEP 等)的资源 | 见 §2.2 |
| Fault Domain (FD) | 同一 scale unit 内的逻辑故障域 | 见 §2.6 |
| Update Domain (UD) | 更新域,配合 FD 用于 Live Migration 滚动更新 | 更新域 |
| Availability Set | 一组 VM 的 FD + UD 关联约束 | 可用性集 |
| VM Placement | 决定 VM 落在哪个 FD / UD 的算法 | 放置策略 |

2.2 基础设施占用(Infra Overhead)【L0 azs-2604】【微软硬要求】

微软官方明确:

"There's overhead to host the Azure Stack Hub infrastructure VMs. For the infrastructure VM overhead, allocate 146 vCore and 268 GB of memory. Additionally, for each additional server added to the scale unit, allocate an additional 4 GB of memory."

即:

  • vCore 占用 :146 vCore (整个 scale unit 固定值,不随节点数变化)
  • Memory 占用 :268 GB + 4 GB × N(N = 节点数)

版本警告(L0) :146 vCore / 268 GB 是 azs-2604 及相近版本 的数值。Azure Stack Hub 历史版本(azs-2002 之前)的具体数值可能不同;规划前请核实当期版本官方文档。

举例:

  • 4 节点:268 + 4×4 = 284 GB
  • 8 节点:268 + 4×8 = 300 GB
  • 12 节点:268 + 4×12 = 316 GB
  • 16 节点:268 + 4×16 = 332 GB

2.3 储备容量(Resiliency Reserve)【L0 azs-2604】【微软硬要求】

2.3.1 微软原始描述(重要,重读)

"Azure Stack Hub has reserved capacity to ensure tenant VMs remain available during infrastructure updates and node failures. This reserved capacity is implemented as a memory equivalent of one server less than the total number of servers in the scale unit. ... Azure Stack Hub reserves the memory equivalent of one server less the number of servers in the scale unit, and 15 percent of the remaining memory is reserved for OS reservation."

2.3.2 容量保障模型(v1.2 表述升级)

v1.1 表述回顾 :v1.1 把 Resiliency Reserve 简化为"Reserve = M(单节点内存)"。这个表述方向正确,但过于简化。

v1.2 升级后的表述:

Azure Stack Hub 的 Resiliency Reserve 本质是 N+1 容量保障设计 --容量规划时必须确保 Scale Unit 在失去一个节点后,剩余节点仍能满足租户 VM 的运行需求 + OS Reservation + 基础设施占用的总和。

这意味着:

  • 内存容量估算时,可以近似按"一个节点的物理内存容量"作为预留参考 (容量规划粗算近似,非精确等式)
  • 实际上还需要进一步扣除 :
    • Infrastructure Overhead(§2.2:146 vCore + 268+4×N GB)
    • OS Reservation(§2.3.3:剩余内存的 15%)
    • S2D Cache / Memory 消耗
    • Host reservation(Hyper-V 自身保留)

如果不显式扣除这些项,就会出现 v1.0 那种"4% 利用率"或"无脑扣一个节点"的误读。

2.3.3 容量模型要点(【L0 azs-2604】)
  • N+1 容错:4 节点 → 失去 1 节点后剩 3 节点可工作;12 节点 → 剩 11 节点可工作
  • 不要把"Reserve = M"理解为"扣一整台服务器的内存" --这是一个粗算参考值,不是字面等式
  • 实际预留量 :取决于基础设施 / OS / S2D / Host 多层扣除后的复合值
  • 微软原文"memory equivalent of one server less than the total number of servers" 的字面意思是"总节点数减去一个节点容量的内存等效量",保留量为 1 个节点容量(不是 N-1 个节点)
2.3.4 OS Reservation(OS 层保留)【微软硬要求】

扣除基础设施占用和 Resiliency Reserve(容量保障)后,剩余内存的 15% 留给 OS(页缓存、内核、驱动等):

复制代码 
OS Reservation = 0.15 × (TotalMemory - InfraOverhead - ResiliencyReserve)

即实际可用内存 = 剩余内存 × 85%。

2.4 计算可用容量（核心公式，v1.1 完整重写）

⚠️ 【v1.2 模型假设说明】 ：本章公式均来自 Microsoft 公开容量规划文档中的内存容量估算模型 ，仅适用于容量 Sizing 阶段 ，不适用于运行时实时评估 。实际运行过程中，Infrastructure VM、Host OS、驱动、Storage Stack 等资源消耗会随版本（azs-XXXX）和 OEM 实现变化，可能与公式估算值存在偏差。

运行时的实际可用内存应以 PEP 上的 PowerShell 实测为准：

复制代码 
Get-VM | Measure-Object -Sum MemoryAssigned
Get-ClusterNode | Get-VM | Get-VMProcessor
Get-VMHostNumaNode | ForEach-Object { $_.AvailableMemory }

上述公式是"购买前规划模型"，不替代运行实测。

2.4.1 整个 Scale Unit 可用内存（微软官方逻辑）
复制代码 
TotalMemory = N × M

InfraOverhead = 268 + 4 × N  (GB)

ResiliencyReserve = M  (GB,N+1 容错)

UsableMemory = (TotalMemory - InfraOverhead - ResiliencyReserve) × 0.85
             = (N × M - 268 - 4 × N - M) × 0.85
             = ((N - 1) × M - (268 + 4 × N)) × 0.85

重要解读 :公式中出现的 (N - 1) × M 是整个 scale unit 的剩余内存 (扣除 1 节点 Reserve 后),不是 Resiliency Reserve 本身。v1.0 把这两者搞混了。

2.4.2 单节点平均可用内存
复制代码 
SingleNodeUsableMemory = UsableMemory / N
                       = ((N - 1) × M - (268 + 4 × N)) × 0.85 / N

注意 :单节点平均可用内存是算术平均,实际 Live Migration 不一定把 VM 平均分配到每个节点(VM Placement 算法会考虑 FD / UD),但作为容量规划粗算是合理的近似。

2.4.3 计算容量举例(示例,非官方承诺)

【说明】 以下数字仅作算例演示 Microsoft 公式用法。OEM SKU 的具体单节点内存配置需查 OEM Support Matrix(如 Dell AS-760 单节点 1 TB / 2 TB / 4 TB 等由 Dell 认证决定,不是客户自由指定)。

示例配置 A:4 节点 scale unit,每节点 768 GB 内存

|--------------------------|------------------|---------------|
| 项目 | 计算 | 结果 |
| 节点数 N | - | 4 |
| 单节点内存 M | - | 768 GB |
| 总内存 | 4 × 768 | 3072 GB |
| 基础设施占用 | 268 + 4 × 4 | 284 GB |
| Resiliency Reserve(1 节点) | - | 768 GB |
| 剩余内存 | 3072 - 284 - 768 | 2020 GB |
| OS Reservation (15%) | 2020 × 15% | 303 GB |
| 整个 Scale Unit 可用 | 2020 × 85% | ~1717 GB |
| 单节点平均可用 | 1717 / 4 | ~429 GB |

示例配置 B :12 节点 scale unit,每节点 768 GB 内存(v1.0 错误对比)

|----------------------|-------------------|----------------|
| 项目 | v1.0 错误结果 | v1.1 正确结果 |
| 节点数 N | 12 | 12 |
| 单节点内存 M | 768 GB | 768 GB |
| 总内存 | 9216 GB | 9216 GB |
| 基础设施占用 | 316 GB | 316 GB |
| Resiliency Reserve | 8448 GB(错误!) | 768 GB(正确) |
| 剩余内存 | - | 8132 GB |
| OS Reservation (15%) | - | 1220 GB |
| 整个 Scale Unit 可用 | 384 GB(严重错误!) | ~6912 GB |
| 单节点平均可用 | ~32 GB(严重错误!) | ~576 GB |

v1.0 错误代价 :v1.0 的错误公式让 12 节点 768 GB 配置看起来只能给租户 ~384 GB 内存(4% 利用率),这是完全错误的。正确值约 6.9 TB(75% 利用率)。

示例配置 C:16 节点 scale unit,每节点 1 TB 内存

|--------------------------|--------------------|----------------|
| 项目 | 计算 | 结果 |
| 节点数 N | - | 16 |
| 单节点内存 M | - | 1024 GB |
| 总内存 | 16 × 1024 | 16384 GB |
| 基础设施占用 | 268 + 4 × 16 | 332 GB |
| Resiliency Reserve(1 节点) | - | 1024 GB |
| 剩余内存 | 16384 - 332 - 1024 | 15028 GB |
| OS Reservation (15%) | 15028 × 15% | 2254 GB |
| 整个 Scale Unit 可用 | 15028 × 85% | ~12774 GB |
| 单节点平均可用 | 12774 / 16 | ~798 GB |

2.4.4 计算可用 vCore(粗算)【L0 azs-2604】

微软文档没有给出 vCore 的精确"扣除公式",但基础设施占 146 vCore 是固定值。因此作为粗算参考:

复制代码 
ScaleUnitUsablevCore ≈ TotalPhysicalvCore - 146

⚠️ v1.2 重要补充 :Azure Stack Hub 的 vCore 容量规划不是 简单的 CPU Core 减法。146 vCore 仅代表 Infrastructure VM 的资源占用,实际 VM 可部署数量还受到以下因素影响:

  • VM Size:每个 VM 系列有自身的 vCPU 配置范围(详见 §4)
  • NUMA 拓扑:大尺寸 VM 的 vCPU 跨 NUMA 节点会显著降低性能
  • Logical Processor / SMT:Hyper-V 调度使用 Logical Processor,物理 Core / SMT 关系影响调度
  • VM Placement 策略:FD / UD / 可用性集对 VM 实际落点的影响
  • 每节点 VM 数限制 :【微软硬要求】 60 VM/node(上篇 §2.5.3)

因此**"1024 Physical Core → 878 Core 租户 CPU"** 这种推论是粗算 ,不能等同于"实际可部署 VM 的 vCPU 总和"。具体容量必须以 Microsoft Capacity Planner 计算结果 + OEM PoC 验证为准。

【最佳实践】 :vCore 不要超分配 (overcommit)。Hyper-V 的 vCPU 调度在 vCore 满载时会让 VM 性能不可预测地下降。Azure Stack Hub 本身不强制 禁止 vCPU overcommit,但生产环境通常不开 overcommit(非微软官方承诺)。
版本警告(L0):146 vCore 是 azs-2604 当期值,不同版本可能不同。

2.5 节点规模与 VM 数量边界

2.5.1 节点规模(【微软硬要求】)

|----------------------|-------------------------------------------------------|----------------|
| 项目 | 微软硬性边界 | 备注 |
| Scale Unit 最小节点数 | 4(scale unit 启动最小规模) | 【微软硬要求】 |
| Scale Unit 最大节点数 | 16 | 【微软硬要求】 |
| Stamp 总规模 | 由多个 Scale Unit 聚合,受部署模型、OEM 支持矩阵、RP 容量、管理组件容量共同限制 | 非简单 16 × N |

⚠️ v1.2 重要补充 :Stamp 不等于无限扩展。即使有"4 个 scale unit × 16 节点 = 64 节点"这种推导,实际 Stamp 总规模还受以下限制:

  • RP 容量上限:每个 Resource Provider(如 Compute RP、Network RP、Storage RP、Key Vault RP 等)有自己的内部对象数上限
  • 管理组件容量上限:ARM、SAS、PEP、Backup Infrastructure 等管理组件的处理能力
  • OEM Support Matrix:Dell AS-760 等 OEM 通常对单 Stamp 最大 scale unit 数有上限(典型 4 个)
  • 租户门户性能:单 Stamp 租户 VM / 资源数过多时 Portal UI 性能下降

实际 Stamp 扩展时必须 与 OEM + Microsoft Support 沟通上限,不能假设"线性扩展"。

2.5.2 VM 数量限制(【L0 版本事实】)

⚠️ v1.2 重要修订 :v1.1 表格列出"早期 azs-2005 之前 700 VM"等历史数字,这些数字易被截图传播、作为当前规划依据使用。Azure Stack Hub 的 VM 数量上限是版本演进的 ------历史版本曾存在不同上限(700、1000 等),但这些数字不能直接用于当前容量规划。

|--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|
| 项目 | 说明 |
| 单 Scale Unit VM 数量上限 | 随 Azure Stack Hub 版本演进变化 |
| 参考来源 | 当前版本 Capacity Planner(搜索 - Microsoft 必应 Microsoft Learn azure-stack-vm-sizes 当期页面 |
| 历史版本数字 | 仅作版本演进参考,不作为当前容量规划依据 |

【L0 警告 + v1.2 表述升级】:

  • 任何"VM 数量上限"的数字必须 先核实当前部署的 azs 版本
  • 微软官方 Capacity Planner 是权威参考,但微软明确不作官方承诺
  • 历史版本曾存在不同 VM 数量限制(如 700、1000 等),但不建议作为当前容量规划依据
2.5.3 每节点 VM 数(【微软硬要求】)

|----------------|----------------------|
| 项目 | 微软硬性边界 |
| 每节点最大 VM 数 | 60 (【微软硬要求】) |

2.6 故障域(Fault Domain)与可用性集

2.6.1 FD 数量随版本变化(【L0 版本事实】)

⚠️ v1.2 表述升级 :v1.1 用具体版本(≤ azs-2002 / ≥ azs-2108)列表 FD 数,容易被截图传播为"硬规则" 。Azure Stack Hub availability set 当前版本支持最多 3 个 Fault Domain ,但不同版本和升级路径可能影响已有 stamp 的实际 FD 行为。

|------------------------------------|--------------------------------------------------------------------|
| 项目 | 说明 |
| Availability Set 最大 FD 数(当前版本) | 3 FD (【微软硬要求】,当期版本) |
| 历史版本 FD 数 | 历史曾存在 2 FD 的部署形态 |
| 升级路径影响 | 历史 stamp 升级后的 FD 行为取决于具体升级路径 ,不是"自动变为 3 FD"------需参考当期升级指南 |
| 未来版本变化 | 后续 azs-2610+ 是否调整 FD 数需以官方公告为准 |

微软原文 (azure-stack-capacity-planning-compute): "When a virtual machine is created, it's placed in an availability set. Azure Stack Hub availability sets can have a maximum of three fault domains."
【L0 版本警告】:

  • 新部署:默认按当期版本规则(当前 3 FD)。
  • 历史环境升级 :FD 数变化取决于升级路径 --azs-2108 之前的 stamp 升级后可能仍保持 2 FD,不是"自动改 3"。具体升级行为需参考当期升级指南。
  • 后续版本(azs-2610+)是否调整 FD 数需以官方公告为准。
2.6.2 可用性集创建规则(【微软硬要求】)
  • 一个可用性集最多 3 个 FD + 最多 N 个 UD(N = scale unit 节点数)
  • 一个 FD 内的所有 VM 必须 分布在不同的物理节点
  • 微软放置算法会自动 避开同一节点(azs-2108+ 已废弃显式 -UseNonUniformVmPlacement 参数)
2.6.3 单 FD / UD 的 VM 数上限(【最佳实践】)

微软未给"单 FD 最大 VM 数"的硬性数字。【最佳实践】:

  • 单 FD 内 VM 总 vCore 不超过该 FD 物理总 vCore 的 70%(预留 30% 给 Live Migration)
  • 单 FD 内 VM 总内存 不超过该 FD 物理总内存的 70%
  • 这些经验数字非微软官方承诺,请结合业务容忍度调整

2.7 批处理 VM 配置(Batch Provisioning)【微软硬要求】

微软官方文档指出:

"VMs are provisioned in batches of 40 with a 5-minute interval between batches."

即:【微软硬要求】 每次最多 40 个 VM 同时创建,间隔 5 分钟。这是因为 S2D 的 RDMA 网络和 Storage Pool 在大并发配置时会对元数据操作造成压力。

【L0 版本警告】 :40 / 5 分钟是较新版本(azs-2005+)的限制,早期版本可能不同(如 20 / 5 分钟)。

【最佳实践】:

  • 自动化脚本创建 VM 时强制加 5 分钟 sleep
  • 不要试图用 ARM 模板并发创建数百个 VM,会触发 S2D 控制器队列拥塞
  • 紧急扩容场景(如促销日)请提前批量化预创建

2.8 节点添加(Scale Out)

微软官方建议在 scale unit 现有节点上预留 1 个空节点位 (【最佳实践】),以便:

  • 节点故障时新节点快速加入
  • Azure Stack Hub Update Bundle 更新期间临时替换
  • OEM 维护窗口期临时下架

微软原文 (azure-stack-add-scale-node): "Microsoft recommends that you leave at least one node slot free for scale-out operations. ... To add a scale unit node, the deployment must have been initially deployed as an Azure Stack Hub system with at least the minimum supported number of scale unit nodes for the OEM hardware solution."
【OEM 实现 + 微软硬要求】 :新增节点必须与现有节点完全同型同配同 firmware baseline,由 OEM 验证(详见 §6)。

2.9 计算容量规划步骤(综合)

复制代码 
步骤 1:确定业务需求(VM 数量 / vCore / 内存 / 存储 / 网络)。
步骤 2:用 aka.ms/azstackcapacityplanner 反推 OEM SKU + 节点数。
步骤 3:确认 N(节点数)和 M(单节点内存),由 OEM Support Matrix 决定。
步骤 4:计算基础设施占用:vCore = 146,Memory = 268 + 4×N。
步骤 5:计算储备容量:Reserve = M(1 节点容量)。
步骤 6:计算可用内存:((N-1)×M - (268+4N)) × 0.85。
步骤 7:检查 VM 数 ≤ 节点数上限、≤ 每节点 60 VM 硬上限。
步骤 8:检查可用性集 FD ≤ 3、UD ≤ N。
步骤 9:用 Capacity Planner 工具交叉验证。
步骤 10:PoC 验证(必须)。

3. 存储容量规划

3.1 存储架构总览(【微软硬要求】)

Azure Stack Hub 的存储是 Storage Spaces Direct(S2D)+ 三层虚拟磁盘 的超融合架构:

复制代码 
Azure Stack Hub Storage
├── Local / Boot 设备(每节点独立,非 S2D 管理)
│   └─ 操作系统镜像、本地基础设施组件(容量由 OEM 认证方案决定)
│
└── S2D Pool(**整个 scale unit 共一个池**,所有节点共享)
    ├── Infrastructure 虚拟磁盘(3.5 TB,整个 scale unit,**逻辑容量**)
    ├── VmTemp 虚拟磁盘(每节点一个,临时盘存储)
    └── ACS 虚拟磁盘(Azure Consistent Storage,剩余容量全部给 ACS)

⚠️ v1.2 修正 :v1.1 / v1.0 写"≥ 340 GB"是微软原文脚注 ("^1^ Minimum storage capacity required of the Azure Stack Hub solution partner" ),但这是 OEM 解决方案合作伙伴的最低要求 ,不是 Azure Stack Hub 平台的硬性要求 。每个节点的实际 Boot 设备大小由 OEM 认证方案决定,Dell / HPE / Lenovo 各 OEM 不同。

3.2 S2D 池与镜像(【微软硬要求】)

微软官方明确:

"One Storage Spaces Direct pool per scale unit ... Virtual disks are created as a three-copy mirror for best performance and resiliency. Each virtual disk is formatted as an ReFS file system. Virtual disk capacity is calculated and allocated in a way as to leave one capacity device's amount of data capacity unallocated in the pool. This is the equivalent of one capacity drive per server. Each ReFS file system has BitLocker enabled for data-at-rest encryption."

即:

  • ✅ 整个 scale unit 一个 S2D 池
  • ✅ 当前 Azure Stack Hub Integrated System 默认采用 three-way mirror(三路镜像)设计--这不是客户可配置的选项
  • ✅ 文件系统ReFS(不提供 NTFS 选项)
  • ✅ 每节点等效保留一个容量设备容量的未分配空间 (用于节点/容量设备故障后的数据重建空间 --不是传统 spare disk,S2D 没有传统 RAID spare 概念,而是 Pool free capacity 中的保留)
  • ✅ BitLocker 全卷加密(静态数据加密)

⚠️ v1.2 补充 :Azure Stack Hub 与 Azure Stack HCI / Azure Local 不能简单对等 。Azure Stack HCI / Azure Local 中 S2D 支持 Mirror / Parity / Mixed 等多种布局 (运营管理员可自由选择);Azure Stack Hub 当前设计为强制 Three-Way Mirror --这是 Appliance 级别的架构决策,不可由租户 / 运营者更改。
v1.1 修正 :v1.0 用"spare capacity"描述该保留空间,容易让熟悉传统 RAID spare 的读者误解。准确含义是为故障重建预留的容量空间 ,S2D 通过池级别重建机制使用该空间,不等同于传统 RAID 专用热备盘。

3.3 缓存与容量分层(【OEM 实现】)

Azure Stack Hub 的存储设备按**缓存(cache)+ 容量(capacity)**两层组织,具体配置由 OEM 认证方案决定:

|------------------|---------------------------|---------------------------------|-----------|
| 配置 | 缓存设备 | 容量设备 | 备注 |
| All-Flash 单层 | 不使用 | NVMe 或 SATA SSD 或 SAS SSD(全部同类) | 性能最高,成本最高 |
| All-Flash 双层 | NVMe | SATA SSD 或 SAS SSD | 性能与成本折中 |
| Hybrid 双层 | NVMe / SATA SSD / SAS SSD | HDD | 容量最大,成本最低 |

v1.1 修正 :v1.0 暗示"现代系统都是 NVMe 缓存"是错误的。缓存设备类型由 OEM 认证方案决定 ,可能是 NVMe SSD、SATA SSD、SAS SSD 等。客户不能自由指定缓存设备类型。
微软官方说明 :"Operators can choose between either an all flash or a hybrid storage configuration" 。但实际上 OEM 通常按 SKU 固定配置,用户没有"自己选缓存 vs 容量"的自由度。

3.4 VmTemp 容量公式(【微软硬要求】)

VmTemp 是租户 VM 的临时盘(D: 盘)存放位置。微软官方公式:

复制代码 
DesiredTempStoragePerServer = PhysicalMemory × 0.65 × 8

TempStoragePerSolution = DesiredTempStoragePerServer × NumberOfServers

PercentOfTotalCapacity = TempStoragePerSolution / TotalAvailableCapacity

If PercentOfTotalCapacity <= 0.1:
    TempVirtualDiskSize = DesiredTempStoragePerServer
Else:
    TempVirtualDiskSize = (TotalAvailableCapacity × 0.1) / NumberOfServers

翻译:

  • 每节点期望临时盘大小 = 物理内存 × 0.65 × 8(即每 GB 内存给 5.2 GB 临时盘)
  • 整个 stamp 临时盘 = 每节点 × 节点数
  • 如果临时盘总和 ≤ 总容量 10%:临时盘大小 = 期望大小
  • 如果临时盘总和 > 总容量 10% :临时盘大小 = (总容量 × 10%) / 节点数(即上限 10% 总容量)

解读 :微软主动给临时盘设置 10% 的容量上限,以防止临时盘把所有存储都吃掉。这与 §3.5 的 ACS 容量是直接竞争关系。

3.5 ACS 容量公式

微软官方说明:

"The virtual disks created for use by ACS are a simple division of the remaining capacity."

即:

复制代码 
ACS 容量 = 总可用容量 - Infrastructure 虚拟磁盘 - VmTemp 虚拟磁盘

ACS 提供 Blob / Table / Queue 服务,所有租户的对象存储 / 文件存储 / 备份 / 诊断日志 / 镜像仓库都从 ACS 来 。这是 Azure Stack Hub 容量规划中最容易被低估的一块。

3.6 存储容量规划示例(示例,非官方承诺)

3.6.1 有效容量链(v1.2 新增)

Azure Stack Hub 的物理容量到租户可用 ACS 容量的转换,需要经过四层扣除 + 一层三路镜像。理解这条链对容量规划至关重要:

复制代码 
┌─────────────────────────────────────────────────────────────────┐
│ 原始物理容量(Raw Capacity)                                       │
│    8 节点 × 24 × 7.68 TB = 1474.56 TB                            │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│ - 每节点保留 1 容量盘容量(Capacity Device Reserve)               │
│   1 × 7.68 TB × 8 = 61.44 TB                                    │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│ S2D 可用容量(S2D Usable Capacity)                                │
│   1474.56 − 61.44 = 1413.12 TB                                  │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│ ÷ 3(Three-way Mirror,Azure Stack Hub 强制)                       │
│   1413.12 / 3 = 471.04 TB                                       │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│ 虚拟磁盘逻辑容量(Virtual Disk Logical Capacity)                  │
│   471.04 TB                                                      │
│                                                                  │
│   - Infrastructure 虚拟磁盘逻辑: 3.5 TB                          │
│   - VmTemp 上限 10%: 47.104 TB                                   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│ ACS 租户可用容量(ACS Tenant Capacity)                             │
│   471.04 − 3.5 − 47.104 = 420.436 TB                             │
│                                                                  │
│   **实际可用 / 物理 ≈ 28.5%**                                   │
└─────────────────────────────────────────────────────────────────┘

【v1.2 新增说明】 这条容量链是所有 Azure Stack Hub OEM 共同适用 的扣除模型,无论 Dell / HPE / Lenovo 都遵循相同的层级。不同之处只在于 OEM SKU 的原始物理容量(节点数 / 容量盘数 / 单盘容量)。

【说明】 以下为算例演示 Microsoft 公式用法。OEM SKU 具体单节点容量盘配置由 OEM Support Matrix 决定 (如 Dell AS-760 节点容量盘数 / 单盘容量由 Dell 认证),客户不能自由指定。

示例配置:8 节点 scale unit,每节点 24 × 7.68 TB NVMe(容量盘)

【v1.2 精度修正】 :v1.1 在 12 节点 8 TB 单盘配置下做了早期四舍五入(1474 → 1412 / 3 → 470),本示例改用 8 节点 7.68 TB 配置展示不早四舍五入的计算过程。

|---------------------------|-----------------------|---------------------|
| 项目 | 计算 | 结果 |
| 单节点裸容量 | 24 × 7.68 TB | 184.32 TB / 节点 |
| 8 节点总裸容量 | 184.32 × 8 | 1474.56 TB |
| 每节点保留 1 容量盘 | 1 × 7.68 TB × 8 | 61.44 TB |
| S2D 池剩余 | 1474.56 - 61.44 | 1413.12 TB |
| 三路镜像实际可用(÷3) | 1413.12 / 3 | 471.04 TB(逻辑容量) |
| Infrastructure 虚拟磁盘(逻辑容量) | 固定 | 3.5 TB |
| VmTemp 上限 10% | 471.04 × 10% | 47.104 TB |
| ACS 可用(逻辑容量) | 471.04 - 3.5 - 47.104 | 420.436 TB |

最终约为 ~420 TB ACS 可用 (物理容量 1474.56 TB → ACS 420.44 TB,实际可用 / 物理 ≈ 28.5%)。

重要细节:

  • 3.5 TB 是 Infrastructure 虚拟磁盘的逻辑容量**(用户可见),不是物理容量。物理占用是三副本后的 3.5 TB × 3 ≈ 10.5 TB。
  • BitLocker 开销 :约 5-10%,实际可用 ACS 容量应再减。
  • 去重 / 压缩 :Azure Stack Hub 默认不启用 ReFS 去重压缩(与 Windows Server 2022 S2D 默认不同),按需开启。
  • 容量规划应保留小数精度,不要早期四舍五入--后期累积误差可达数 TB。

3.7 存储 IOPS 与带宽限制(【OEM 实现】)

Azure Stack Hub 没有公开"单盘最大 IOPS"的硬性数字(微软未给 ,与 Azure Stack HCI 不同)。【OEM 实现】:

  • Dell / HPE / Lenovo 的 spec sheet 通常会标注"最大聚合 IOPS"(如 Dell AS-760 全 NVMe 配置可达数百万 IOPS)
  • 不要把这些数字当作"租户能拿到的 IOPS"--租户 IOPS 受 VM Size + 版本共同决定(见 §4)

4. VM 规格与磁盘 IOPS 矩阵(【OEM/版本实现】)

⚠️ v1.1 重大修正 :v1.0 把 VM Size / IOPS 表标为"微软硬要求"是错误的。VM Size 的实际可用性取决于:1 Azure Stack Hub 版本 2 OEM SKU 认证 3 节点 CPU 数量 4 NUMA 拓扑 。本文仅列常见示例 ,不代表所有版本 / OEM 都支持。

4.1 VM 系列总览(【OEM/版本实现】)

Azure Stack Hub 提供与 Azure 公有云部分对齐 的 VM 系列,不是全部 Azure VM 系列都可用:

|--------------------------------------|--------------------------------|----------------------|-----------------------|
| 系列 | 当前版本可用性 | 用途 | 依赖条件 |
| General Purpose(GP / A / D) | ✅ 通常可用 | 通用 Web / 中小型数据库 | OEM 认证 CPU |
| Memory Optimized(E / Mo) | ✅ 通常可用 | 内存数据库 / SAP | OEM 认证内存 |
| Storage Optimized(So / Lsv2) | ⚠️ 部分 OEM 可用 | 大数据 / NoSQL / 高吞吐临时盘 | OEM 认证 NVMe |
| Compute Optimized(Co / F / Fsv2) | ⚠️ 部分 OEM 可用 | CPU 密集型 | OEM 认证 CPU |
| GPU(NV / NVv2 / NCv3) | ⚠️ OEM 决定具体 SKU | GPU 计算 / 渲染 / AI | OEM 认证 GPU |
| H / H_B 系列(高性能) | ⚠️ 部分 OEM 可用 + 需 InfiniBand 网络 | MPI / HPC | OEM + InfiniBand ToR |
| Av2 / B 系列 | ✅ 通常可用 | 入门级 | 通用 |
| M 系列(超大型) | 当前版本通常不可用 | 超大型 VM | 受 OEM 单节点内存上限限制 |
| 机密计算(DC 系列) | 当前版本通常不可用 | 机密计算 | Azure Stack Hub 当前未集成 |
| Premium Storage v2 / Ultra Disk | 当前版本通常不可用 | 高性能磁盘 | 见 §4.3 |

⚠️ v1.2 措辞升级 :v1.1 用 ❌ / ✅ 表达"不支持",容易被理解为"永久禁止"。Azure Stack Hub VM 系列支持是 Azure Stack Hub 当前版本与 OEM SKU 联合决定的 ,未来版本可能新增支持、当前版本的部分支持也可能调整。准确表述是"当前版本 + 当期 OEM 通常不可用",而非"永久不支持"。
【L0 版本警告】 :上表是常见可用性 的总结。同一 VM 系列在不同 OEM SKU、不同 azs 版本上不一定都提供。实际规划必须以 OEM Support Matrix + Capacity Planner 为准。

4.2 VM 规格示例(General Purpose,【L0 版本示例】)

以下表格列出典型 GP / D_v2 / D_v3 系列示例 。实际可用 VM Size 以部署的 azs 版本 + OEM SKU 为准。

|-----------------|----------|------------------|--------------------|-------------------|-------------------------|
| Size | vCPU | Memory (GiB) | Max data disks | Max disk IOPS | Max disk throughput |
| Standard_A0 | 1 | 0.768 | 1 | 1 × 300 | 1 × 20 MB/s |
| Standard_A1 | 1 | 1.75 | 2 | 2 × 300 | 2 × 20 MB/s |
| Standard_A2 | 2 | 3.5 | 4 | 4 × 300 | 4 × 20 MB/s |
| Standard_A4 | 4 | 7 | 8 | 8 × 500 | 8 × 30 MB/s |
| Standard_A5 | 8 | 14 | 16 | 16 × 500 | 16 × 30 MB/s |
| Standard_A7 | 8 | 56 | 16 | 16 × 500 | 16 × 30 MB/s |
| Standard_D1_v2 | 1 | 3.5 | 2 | 2 × 300 | 2 × 30 MB/s |
| Standard_D2_v2 | 2 | 7 | 4 | 4 × 300 | 4 × 30 MB/s |
| Standard_D4_v2 | 8 | 28 | 8 | 8 × 500 | 8 × 30 MB/s |
| Standard_D5_v2 | 8 | 56 | 16 | 16 × 500 | 16 × 30 MB/s |
| Standard_D2_v3 | 2 | 8 | 4 | 4 × 300 | 4 × 30 MB/s |
| Standard_D4_v3 | 4 | 16 | 8 | 8 × 500 | 8 × 30 MB/s |
| Standard_D8_v3 | 8 | 32 | 16 | 16 × 500 | 16 × 30 MB/s |
| Standard_D16_v3 | 16 | 64 | 32 | 32 × 500 | 32 × 30 MB/s |
| Standard_D32_v3 | 32 | 128 | 32 | 32 × 500 | 32 × 30 MB/s |
| Standard_D48_v3 | 48 | 192 | 32 | 32 × 500 | 32 × 30 MB/s |
| Standard_D64_v3 | 64 | 256 | 32 | 32 × 500 | 32 × 30 MB/s |

4.3 磁盘 IOPS 限制(【L0 版本事实 + OEM 实现】)

⚠️ v1.1 修正 :v1.0 把 500 / 2300 IOPS 标为"微软硬要求"是不准确的。Azure Stack Hub 的磁盘 IOPS 限制取决于:1 Disk SKU 2 VM Size 3 部署的 azs 版本 4 Storage RP 实现。以下是典型规律:

|---------------------------|-----------------|--------------|-----------|
| VM 磁盘类型 | 典型单盘最大 IOPS | 典型单盘最大吞吐 | 适用版本 |
| 标准非托管磁盘(Standard HDD) | 500 IOPS | 60 MB/s | 多数 azs 版本 |
| 标准 SSD(S 系列) | 500 IOPS | 60 MB/s | 多数 azs 版本 |
| 高级 SSD(P 系列) | 2300 IOPS | 150 MB/s | 多数 azs 版本 |
| Ultra Disk | 当前版本通常不可用 | - | - |
| Premium Storage v2 | 当前版本通常不可用 | - | - |

【L0 版本警告】:

  • 500 / 2300 IOPS 是典型规律 ,不是所有版本通用。不同 azs 版本可能调整这些数字。
  • 每个独立磁盘的 IOPS 限制是单独计算 ,不按 VM 总和自动聚合。16 盘的 D16_v3 最多拿到 32 × 500 = 16000 IOPS(uncached,【L0 版本示例】)。
  • Premium Storage 在 Azure Stack Hub 上没有 "自动扩展"机制(不同于 Azure 公有云的 P30/P40/P50 自动升档)。容量与 IOPS 一次到位。
  • 临时盘(local SSD,Fs / Lsv2 等) 在 Azure Stack Hub 上不享有 Azure 公有云的"高性能临时存储" SLA,性能取决于 OEM 硬件 (典型如 NVMe SSD,【OEM 实现】)。

4.4 GPU VM 与 HA 限制(【微软硬要求】)

微软官方说明(azure-stack-vm-sizes):

"GPU VMs aren't automatically highly available. The availability of GPU VMs in an availability set is best-effort."

即:【微软硬要求】

  • GPU VM 不参与 Live Migration 故障转移
  • GPU VM 在可用性集内只能保证"尽力而为"的高可用
  • 节点 GPU 故障时,GPU VM 上的租户必须自行处理恢复

【最佳实践】:

  • GPU 训练任务务必自带 checkpoint(断点续训)
  • 不要把 GPU VM 放在可用性集里指望 HA
  • 重要 GPU VM 在更新窗口期主动关机(Live Migration 会失败)

4.5 Standard_H / H_B 系列(【L0 版本示例 + OEM 实现】)

|----------------|----------|------------------|--------------------|-------------------|
| Size | vCPU | Memory (GiB) | Max data disks | Max disk IOPS |
| Standard_H8 | 8 | 56 | 16 | 16 × 500 |
| Standard_H16 | 16 | 112 | 32 | 32 × 500 |
| Standard_H8m | 8 | 112 | 16 | 16 × 500 |
| Standard_H16m | 16 | 224 | 32 | 32 × 500 |
| Standard_H16r | 16 | 112 | 32 | 32 × 500 |
| Standard_H16mr | 16 | 224 | 32 | 32 × 500 |

【OEM 实现】 :H 系列需要 InfiniBand / RoCE 网络,仅 OEM 硬件合作伙伴支持。具体 OEM SKU 是否提供 H 系列以 OEM Support Matrix 为准。

5. 网络与数据中心集成

5.1 五大逻辑网络(【微软硬要求】)

Azure Stack Hub 部署必须规划以下 5 个 IPv4 子网:

|---------------------------|--------------------------------------------------|----------------------------------------------|
| 逻辑网络 | 用途 | 官方推荐子网大小 |
| Public VIP | 租户对外服务的公共 IP 地址池(SLB 使用) | /26 (62 hosts) - /22 (1022 hosts),推荐 /24 |
| Switch Infrastructure | ToR 交换机的路由 / 管理 IP(含 /30 点对点、/32 loopback) | /26 |
| Infrastructure | Azure Stack Hub 内部组件通信(PEP、备份等) | /24 |
| Private | 存储网络 / 内部 VIP / 容器网络(当前版本每 scale unit 需 /20) | /20(当前版本) |
| BMC | iDRAC / iLO 等带外管理网络 | /26 |

【微软硬要求】:

  • 每 scale unit 需额外预留 1 个 /20 Private IP 空间(仅在该 scale unit 内路由,不可全局路由)
  • 5 个子网不允许互相重叠
  • 这些子网不允许与数据中心现有任何子网重叠
    【L0 版本警告】 :上述子网大小是典型 azs-2604 数值 。早期版本(如 azs-2002)Private 子网要求可能不同--具体数值以当期部署工作表为准。

5.2 ToR 上行(【微软硬要求】)

微软官方说明:

"It expects a minimum of one connection between ToR and Border when using BGP Routing and a minimum of two connections (one per ToR) between ToR and Border when using Static Routing, with a maximum of four connections on either routing option. These connections are limited to SFP+ or SFP28 media and a minimum of one GB speed."

即:

|------------|-----------------------|----------|
| 路由方式 | ToR ↔ Border 最小连接 | 最大连接 |
| BGP 路由 | 1 条 | 4 条 |
| 静态路由 | 2 条(每个 ToR 一条) | 4 条 |

【微软硬要求】:

  • 连接介质:SFP+ 或 SFP28(10 Gbps / 25 Gbps)
  • 最低速率:1 Gbps(虽然物理上是 SFP+ / SFP28)
  • ToR 的具体型号由 OEM 决定(Dell 典型用 Dell EMC Networking S5248F-ON / S5224F-ON;HPE 用 Aruba CX 8325;Lenovo 用 ThinkSystem NE2572)

5.3 带宽分配与流量分离(【微软硬要求】)

⚠️ v1.1 重大修正 :v1.0 把"2% 带宽用于 Failover Cluster 心跳"是错误描述 。微软原文中 2% 带宽预留的实际含义是集群 / 基础设施通信流量类别预留,包含但不限于 FC 心跳。

微软官方说明(重读):

"The network configuration uses traffic classes to separate the Spaces Direct, RDMA-based communications from that of the network utilization by the Azure Stack Hub infrastructure and/or tenant. ... This new traffic class definition is configured to reserve 2% of the available, physical bandwidth. This traffic class and bandwidth reservation configuration is accomplished by a change on the top-of-rack (ToR) switches ... and on the host or servers of Azure Stack Hub."

正确理解:

  • 2% 物理带宽 预留给集群 / 基础设施通信流量类别(traffic class 层面的预留,不等同于单一用途)
  • 该 traffic class 主要用于 Azure Stack Hub 基础设施及 Storage Spaces Direct 相关通信类别
  • 不应简单理解为"单独用于 Failover Cluster Heartbeat"--Heartbeat 只是该 traffic class 承载的多种流量之一
  • Microsoft 文档原文使用宽泛描述 ("cluster communication"),实际承载内容由网络 QoS 配置决定,包括但不限于:
    • Storage Spaces Direct RDMA 通信
    • Failover Cluster 心跳
    • 集群基础设施通信

v1.0 错误代价 :把"2% 带宽"等同于"FC 心跳"会让读者严重低估该预留带宽的承载内容,实际承载的流量类型比 FC 心跳广泛得多。
【最佳实践】:在 ToR 上联口不要与 S2D RDMA 通信共享物理端口;典型拓扑是 ToR 上联口(10/25 Gbps SFP+ / SFP28)和 storage 内部网络(25/100 Gbps)分开。

5.4 Public VIP 数量规划

微软官方说明:

"Azure Stack Hub uses a total of 31 addresses from this network and the rest are used by tenant VMs. From the 31 addresses, 8 public IP addresses are used for a small set of Azure Stack Hub services. If you plan to use App Service and the SQL resource providers, 7 more addresses are used. The remaining 16 IPs are reserved for future Azure services."

即:

  • 基础设施预留 31 个 IP(其中 8 个用于 Azure Stack Hub 服务、7 个用于 App Service + SQL RP、16 个留给未来服务)
  • 剩余 IP 全部归租户 VM 使用
  • 子网大小:/26(62 IP)- /22(1022 IP) ,推荐 /24(254 IP)

举例:/24 子网,254 个 IP,扣除基础设施 31 个 + Azure 保留 16 个,租户可用 ~207 个 Public VIP。

5.5 DNS、NTP、身份、证书(【微软硬要求】)

|-------------------|----------------------------------------------------------------------------------------------|
| 项目 | 微软硬要求 |
| DNS Forwarder | 客户必须提供至少 2 个 DNS forwarder IP,用于解析外部域名(如 www.bing.com) |
| NTP 时间源 | 必须提供时间服务器 IP。非 Windows NTP 服务器需在 IP 后加 ,0x8 (如 10.1.1.123,0x8) |
| PKI 证书 | 必须使用 SSL 证书保护公共端点。可用通配符证书或专用证书 + 通配符(仅 Storage / Key Vault) |
| 身份提供商 | Microsoft Entra ID 或 AD FS ,部署时选定,部署后不可更改(除非重新部署整个 stamp) |
| 时区 | 部署时设定,部署后修改需谨慎 |

5.6 连接模式(【微软硬要求】)

|------------------------|------------------------|------------------------|
| 选项 | Connected(连 Azure) | Disconnected(脱机) |
| Microsoft Entra ID | ✅ | ❌ |
| AD FS | ✅ | ✅ |
| Pay-as-you-use 计费 | ✅(含 AD FS 模式) | ❌ |
| Capacity-based 计费 | ✅ | ✅ |
| 许可方式 | EA 或 CSP | EA |
| 补丁与更新 | 自动从 Internet 下载 | 必须通过可移动介质 + 单独联网设备 |
| 注册 | 自动 | 必须通过可移动介质 + 单独联网设备 |

【微软硬要求】 :身份提供商一旦选定,部署后不可更改 (重新部署 stamp)。该决策是 Azure Stack Hub 部署前最重要的架构决策之一。

5.7 混合连接(【微软硬要求】)

Azure Stack Hub 与 Azure 之间的混合连接仅支持三种方式:

|----------------------|----------------|---------------------------------------------------|
| 方式 | 适用场景 | 性能说明 |
| Site-to-site VPN | 多租户、流量需加密隔离 | 性能取决于 VPN Gateway SKU、加密算法、CPU ,没有固定带宽数字 |
| ExpressRoute | 企业与 Azure 已有专线 | 需通过 connectivity provider;性能取决于 ExpressRoute 线路规格 |
| Outbound NAT | 单租户、内网部署 | 不加密、不隔离 |

v1.1 修正 :v1.0 写"S2S VPN 100-200 Mbps 带宽瓶颈"是过于绝对 的错误描述。VPN 实际带宽受 VPN Gateway SKU、加密算法、CPU 等多种因素影响 ,微软未给固定数字。ExpressRoute 通常高于 VPN 但具体带宽取决于运营商线路。
【最佳实践】 :单租户内网场景优先用 Outbound NAT(带宽大、不加密);多租户隔离必须用 S2S VPN 或 ExpressRoute。核心业务数据同步推荐 ExpressRoute,S2S VPN 可作管理通道或备份通道。

5.8 Switch Infrastructure 子网详细规划

微软未给子网内具体子网划分细节,但通常(【OEM 实现 / 最佳实践】):

  • 路由器 ID(loopback):1 × /32
  • 点对点链路:每条 ToR-Border 链路 1 × /30
  • Switch 带内管理:1 × /27 或 /28
  • Switch OOB 管理:1 × /27(通常在 BMC 子网而非 Switch 子网)

【最佳实践】:在 ToR 上下联、Border 上下联至少留 50% 的 IP 余量,便于未来扩展。

6. Dell AS-760 集成系统视角(【OEM 实现】)

⚠️ v1.1 重大修正 :v1.0 把 Dell 部分写成"基于 PowerEdge R650 / R750 / R760 平台"是错误的 。Azure Stack Hub 是 OEM 集成系统(Integrated System Appliance) ,客户不能像普通服务器那样自由 BOM 配置。本节按 Dell 16G AS-760 公开支持矩阵重写。

6.1 Azure Stack Hub 容量规划的 OEM SKU 边界(【OEM 实现】)

6.1.1 为什么 Azure Stack Hub 不能自由配置

Azure Stack Hub 与普通虚拟化集群、Azure Stack HCI / Azure Local Validated Node 有本质区别:

|---------------------------------------|-----------------------------|-------------------------|
| 部署模式 | 硬件选择方式 | OEM 灵活性 |
| 普通 Hyper-V / VMware 集群 | 客户自由选择服务器配置 | 完全自由 |
| Azure Stack HCI(历史) | OEM Validated Node + 多种 SKU | 较高灵活性 |
| Azure Local(2024+) | Validated Node + 越来越多灵活组合 | 逐步向自由组合演进 |
| Azure Stack Hub Integrated System | OEM 固定认证 SKU | 极低灵活性(appliance 模式) |

Azure Stack Hub 的所有组件必须通过 OEM 认证:

  • BIOS
  • Firmware
  • Driver
  • NIC(含 RDMA 网卡)
  • HBA / 存储控制器
  • Storage Device
  • ToR Switch
  • HLH(Hardware Lifecycle Host)

客户不能自由指定 CPU 型号、内存容量、磁盘数量 / 类型 / 容量。

6.1.2 Azure Stack Hub 真实采购 / 容量规划流程
复制代码 
客户业务需求(VM 数、vCore、内存、存储)
        │
        ↓
Azure Stack Hub Capacity Planner(aka.ms/azstackcapacityplanner)
        │
        ↓
选择 OEM 认证 SKU 集合中最接近需求的配置
        │
        ↓
确定节点数(4 / 8 / 12 / 16)
        │
        ↓
用 Microsoft 容量公式(§2 + §3)验证
        │
        ↓
OEM 出具最终 SKU 报价 + Support Matrix 校验
        │
        ↓
PoC 验证(必须)
        │
        ↓
Dell 工程师 ProDeploy 交付

关键现实 :客户提出"我要 600 vCPU + 8 TB RAM + 500 TB 存储",Dell 不会按这个 BOM 直接配服务器--而是在 AS-760 认证 SKU 集合中选最接近的配置(如 8 节点 vs 12 节点的取舍)。

6.2 Dell Azure Stack Hub 集成系统生命周期(【OEM 实现】)

Dell Azure Stack Hub 集成系统并不简单跟随 PowerEdge 全产品线同步发布:

|------------------|-------------------------------------------------------------|------------------------------------------------------------------------|
| PowerEdge 世代 | 是否为 Dell Azure Stack Hub Integrated System | 备注 |
| 13G | 历史平台 | 历史 OEM 文档支持 |
| 14G | ✅ 有 Azure Stack Hub Integrated System 公开支持文档 | 如 R940 等 |
| 15G | ❌ Dell 没有公开发布 15G Azure Stack Hub Integrated System 产品线 | PowerEdge 15G(R750 等)主要用于 Azure Stack HCI / Azure Local + 通用 PowerEdge |
| 16G | ✅ 有 Azure Stack Hub Integrated System 公开支持文档(如 AS-760) | Dell 当前 Azure Stack Hub 16G Scale Unit 平台 |

【OEM 实现】 :Dell 当前公开维护 AS-760 16G Scale Unit 平台。不要把 PowerEdge 通用平台(R650 / R750 / R760)简单等同于 Azure Stack Hub 集成系统。

6.3 Dell 16G AS-760 Scale Unit 容量规划模型(【OEM 实现】)

6.3.1 AS-760 定位

|----------|---------------------------------------------------|
| 项目 | 说明 |
| 产品类型 | Azure Stack Hub Integrated System |
| 节点角色 | Scale Unit Node |
| 节点规模 | 4 / 8 / 12 / 16 节点 |
| 计算 | Intel Xeon Scalable(具体型号由 Dell Support Matrix 决定) |
| 存储 | S2D 管理的 NVMe / SSD / HDD 组合(由 OEM 认证) |
| 网络 | RDMA 网络(具体网卡由 Dell 认证) |
| 管理 | Dell iDRAC + OpenManage Enterprise(OME) |
| 扩展 | 仅可增加同规格 AS-760 节点 |

6.3.2 AS-760 容量规划抽象模型(非 Dell 官方 SKU 分类)

⚠️ v1.2 重要说明 :Dell Azure Stack Hub Integrated System 公开资料主要提供 Support Matrix(支持矩阵)+ 认证配置 ,而不是类似 PowerEdge 服务器的自由配置型号表 。本节描述的是容量规划阶段的抽象配置模型 ,用于演示 Microsoft 容量公式在不同内存 / 存储组合下的输出,绝非 Dell 公开报价 SKU。

|-----------------------------|-----------------|-------------|----------------|--------------|----------------------------------|
| 抽象模型 | CPU | 单节点内存 | 存储 | 网络 | 适用场景 |
| Compute Dense(抽象模型) | 2 × OEM 认证 Xeon | 1 TB - 2 TB | NVMe / SSD | 25 GbE RDMA | 通用 VM / Web / 应用服务器 / 中小数据库 |
| Memory Dense(抽象模型) | 2 × OEM 认证 Xeon | 2 TB - 4 TB | NVMe | 25 GbE RDMA | SAP HANA / 大型 SQL Server / 内存数据库 |
| Storage Optimized(抽象模型) | 2 × OEM 认证 Xeon | ~1 TB | 大容量 NVMe / SSD | 25 / 100 GbE | Blob / Backup / Kubernetes 持久卷 |

【OEM 实现 + 警告】 :上述是抽象容量规划模型 ,不是 Dell 公开报价 SKU 。Dell AS-760 的具体配置(CPU 型号 / 内存容量 / 磁盘数量 / 网络规格)由 Dell Support Matrix 定义,客户在 Dell 销售配置器中可选 ,但不能跨 SKU 自由组合 。Dell 不公开 AS-760 与 PowerEdge 通用服务器类似的 BOM 报价表。

6.3.3 AS-760 8 节点容量计算示例

【示例说明】 以下数字为算例演示 ,非 Dell 公开承诺。实际容量以 Dell AS-760 Support Matrix + Capacity Planner 为准。

假设 Dell AS-760 配置:

  • 8 节点 Scale Unit
  • 每节点 :
    • CPU:2 × OEM 认证 Intel Xeon Scalable(示例假设每 CPU 64 Physical Core,仅用于容量公式演示--OEM 实际 SKU 的 CPU 型号由 Dell Support Matrix 决定)
    • Memory:2 TB
    • Storage:24 × 7.68 TB NVMe

计算资源:

|--------------------------|-----------------------|------------------------|
| 项目 | 计算 | 结果 |
| 单节点 CPU Core | 2 × 64 | 128 Core |
| 8 节点总 CPU Core | 128 × 8 | 1024 Physical Core |
| 8 节点总内存 | 2 TB × 8 | 16 TB |
| 基础设施占用 | 268 + 4 × 8 | 300 GB |
| Resiliency Reserve(1 节点) | - | 2 TB |
| 剩余内存 | 16 TB - 0.3 TB - 2 TB | 13.7 TB |
| OS Reservation (15%) | 13.7 TB × 15% | ~2.06 TB |
| 租户可用内存 | 13.7 TB × 85% | ~11.65 TB |

存储资源:

|-------------------------|-----------------|--------------------|
| 项目 | 计算 | 结果 |
| 单节点裸容量 | 24 × 7.68 TB | 184.32 TB |
| 8 节点总裸容量 | 184.32 × 8 | 1474 TB |
| 每节点保留 1 容量盘(重建空间) | 1 × 7.68 TB × 8 | 61.44 TB |
| S2D 池剩余 | 1474 - 61.44 | 1412 TB |
| 三路镜像实际可用(÷3) | 1412 / 3 | ~470 TB(逻辑容量) |
| Infrastructure 虚拟磁盘(逻辑) | 固定 | 3.5 TB |
| VmTemp 上限 10% | 470 × 10% | 47 TB |
| ACS 可用(逻辑容量) | 470 - 3.5 - 47 | ~420 TB |

最终结论:

|--------|------------------|------------------------|
| 资源 | AS-760 物理总容量 | 租户可用容量 |
| CPU | 1024 Core | ~878 Core(扣 146 基础设施) |
| 内存 | 16 TB | ~11.65 TB |
| 存储 | 1.47 PB | ~420 TB ACS |

再次强调 :客户买的 16 TB 物理内存 ≠ 16 TB 租户可用内存,实际可用约 11.65 TB。

6.3.4 AS-760 不同节点数容量趋势

|-----------|-------------------|--------------------------------|
| 节点数 | 定位 | 特点 |
| 4 节点 | 小规模 / 边缘 | 成本最低,容灾余量最低,VM 数受限 |
| 8 节点 | 最常见生产规格 | 适合企业私有云 / 部门云 / 中型数据中心 |
| 12 节点 | 多租户 / PaaS 服务 | 适合多租户场景 / App Service / SQL RP |
| 16 节点 | 单 Scale Unit 最大规模 | 适合大型企业 / 政府 / 金融 |

6.3.5 AS-760 节点扩展约束(【OEM 实现 + 微软硬要求】)

扩展节点必须满足 Dell OEM Support Matrix 定义的兼容条件,通常要求:

|--------------------------------------|------------------------------------|
| 维度 | 兼容性要求 |
| CPU 型号 | 同型(同代 / 同 SKU,由 Support Matrix 规定) |
| 内存容量 + 布局 | 同型(同 DIMM 容量 / 频率 / 数量 / 拓扑) |
| 存储设备(缓存 / 容量盘)型号 + 容量 + 固件 | 同型(同型号 / 同容量 / 同固件 baseline) |
| 网络设备(网卡型号 + 固件) | 同型(同型号 / 同固件) |
| BIOS / iDRAC / Firmware Baseline | 同 baseline |
| ToR 交换机型号 + 固件 | 同型(同型号 / 同固件,多 scale unit 时) |

【OEM 实现】 :Azure Stack Hub 扩展节点不是"同规格"三个字能精确描述 --它要求满足 Dell Support Matrix 中明确定义的兼容性矩阵。不能 混合使用 PowerEdge 通用 SKU 与 AS-760 SKU;不能增加不同 OEM 认证配置的节点;不能在 Support Matrix 范围外混插硬件。Dell Support Matrix 是硬约束 ,扩展前必须由 OEM 工程师审核。

6.3.6 OEM SKU 导致的容量偏差(【OEM 实现】)

典型场景:客户需求 → OEM 现实的偏差。

|-----------------------------------|---------------------------|
| 客户需求 | OEM 实际方案 |
| 600 vCPU + 8 TB RAM + 500 TB 存储 | 8 节点 AS-760 可能 CPU 够、内存不足 |
| 600 vCPU + 8 TB RAM + 300 TB 存储 | 8 节点 AS-760 可能内存够、存储过剩 |
| 1000 vCPU + 10 TB RAM + 400 TB 存储 | 12 节点 AS-760 可能满足,但成本上升 |

最终选择 :满足业务目标的最小认证 SKU 组合 (不是精确满足需求)。

6.3.7 AS-760 容量规划建议表(【OEM 实现 + 最佳实践】)

|--------------|--------------------------|----------------------|
| 规划因素 | Azure Stack Hub 通用要求 | Dell AS-760 实际影响 |
| 节点数 | 4-16 节点 Scale Unit | 决定总体容量 |
| CPU | OEM 认证 CPU | 不能自由替换 |
| 内存 | OEM 认证 DIMM 布局 | 决定 VM 密度上限 |
| 存储 | 认证 SSD / NVMe 组合 | 决定 ACS 容量 |
| 网络 | 认证 RDMA NIC | 决定 S2D 性能 |
| GPU(如启用) | 认证 GPU 组合 | 决定 AI / HPC 能力 |

6.4 Dell 管理控制(【OEM 实现】)

|-----------------------------------|-----------------------------------------------|------------------------------------|
| 组件 | Dell 典型实现 | 备注 |
| iDRAC | Dell Integrated Dell Remote Access Controller | 带外管理,接入 BMC /26 子网 |
| OpenManage Enterprise (OME) | Dell 集中管理平台 | 监控所有 PowerEdge 服务器 / ToR 交换机 / HLH |
| Hardware Lifecycle Host (HLH) | 独立 Dell 服务器 | OEM 部署 / 监控工具 / Dell ProDeploy 入口 |

v1.2 进一步收紧 :Dell iDRAC 版本和其他管理组件组合以 Dell Azure Stack Hub Support Matrix 为准 。本文不假设具体 iDRAC 版本 (如 iDRAC 9 / iDRAC 10)、不假设具体 OpenManage 版本------这些细节由 Dell Support Matrix 明确定义,客户应直接以 Dell 官方公开资料为准。

6.5 Dell ToR 交换机(【OEM 实现】)

|------------|--------------------------------------------------------------------------------|
| 组件 | Dell 典型实现 |
| ToR 型号 | Dell EMC Networking S5248F-ON 或 S5224F-ON(以 Dell AS-760 Support Matrix 为准) |
| 端口 | 25 GbE SFP28 下联 + 100 GbE QSFP28 上联 |
| 管理 | 通过 Dell OpenManage Network Manager 或 OME |
| 配置 | OEM 预配置带宽预留、流量分离、VLAN |

v1.1 修正:v1.0 写"客户不能自行修改 ToR"过于绝对。准确说法:

不建议客户直接修改 OEM 预配置的 ToR 配置。任何影响 Azure Stack Hub 网络验证的变更需通过 OEM 支持流程(通常需 Dell ProSupport 工单)。简单配置调整(如添加客户侧 VLAN / 路由条目)在与 OEM 沟通后可能允许,但 不得修改 已验证的 Azure Stack Hub 网络配置(如 S2D RDMA 带宽预留、流量分离规则)。

6.6 Dell 部署与运维服务(【OEM 实现】)

  • Dell ProDeploy for Azure Stack Hub :Dell 工程师负责首次完整部署(客户不能自行部署 Azure Stack Hub)
  • Dell ProSupport Plus:OEM 一线支持(包括硬件 + Azure Stack Hub 软件栈的 co-support 与微软对接)
  • Connected Configuration:通过 Dell 远程连接通道,Dell 工程师可远程诊断
  • OpenManage Enterprise (OME):Dell 集中管理平台

6.7 Dell 与微软的 Co-Support 模型(【OEM 实现】)

  • 硬件问题(Dell 服务器、ToR、iDRAC)→ Dell 一线
  • 软件问题(Azure Stack Hub 更新、租户服务异常)→ 微软一线
  • 跨硬件 + 软件的复杂问题 → Dell + 微软联合 RCA

【OEM 实现】 :客户不应绕过 Dell 直接联系微软支持硬件相关问题--按 OEM 协议,必须先经 Dell 排查。

6.8 Azure Stack Hub vs Azure Local:为什么不能像 Azure Local 一样自由扩容?(v1.2 新增)

Azure Stack Hub 与 Azure Local 同为 Microsoft 超融合解决方案 ,但容量规划模型完全不同。本节澄清两者的根本区别,避免读者将 Azure Local 的规划经验直接套用到 Azure Stack Hub。

|----------------|---------------------------------------------------------|--------------------------------------------------------------|
| 维度 | Azure Stack Hub | Azure Local |
| 硬件模式 | Integrated System | Validated Node |
| BOM 自由度 | 低 -- OEM 认证 SKU 集合内可选 | 较高 -- Validated Node 范围内可调 |
| 节点扩展 | OEM 认证 SKU 同型同配(Support Matrix 兼容) | Validated Node 列表内 + 灵活混配 |
| 存储配置 | 强制三路镜像 -- OEM 固定 | Mirror / Parity / Mixed -- 可配置 |
| 容量规划驱动 | OEM SKU 驱动 -- 业务需求 → Capacity Planner → 选最接近的认证 SKU | 工作负载驱动 -- 业务需求 → Validated Node 选型 → Capacity Planner 验证 |
| 节点添加流程 | OEM 工程师现场 + OEM 固件 baseline 对齐 | 客户自助 + Validated Node 兼容性 |
| 典型规模 | 4 - 16 节点 Scale Unit,多 Scale Unit 聚合 | 1 - 16 节点 Cluster |
| Azure 服务集成 | IaaS + 完整 PaaS(App Service / SQL RP / Event Hubs) | IaaS + 部分 PaaS(主要通过 Arc 集成) |
| 微软投资方向 | 稳定维护,不发展新功能(2024+) | 重点投资方向 |

核心区别一句话 :Azure Stack Hub 是 OEM Appliance 模式 (买设备送云体验),Azure Local 是 Validated Node + 越来越灵活(接近自由组合)。

为什么 Azure Stack Hub 不能像 Azure Local 一样自由扩容?

  • OEM 集成系统的认证约束:Azure Stack Hub 的每个 Scale Unit 都是 OEM 预配置 + 微软认证的集成系统。新增节点必须满足 OEM Support Matrix 的多维度兼容性要求(详见 §6.3.5)。这不是"保守",而是 Appliance 模式的本质约束。
  • 存储布局固定 :Azure Stack Hub 强制 Three-Way Mirror(§3.2),客户不能像 Azure Local 那样选择 Parity 节省容量。
  • 管理组件配套:OEM 工程师、Dell ProDeploy、Connected Configuration 等配套是 Azure Stack Hub 部署 / 运维不可分割的一部分。
  • Azure Stack Hub 在 2024 年起微软明确减少投入(参见配套文档下篇 §E.4):新建项目除非有合规 / 数据主权 / 气隙要求,微软推荐 Azure Local。

【最佳实践】:

  • 新建项目:除非有强制合规需求,优先选 Azure Local(详见配套文档下篇 §E.4)。
  • Azure Stack Hub :适合已部署 或合规强制的场景。
  • 混合策略:部分业务用 Azure Stack Hub(合规),部分用 Azure Local(灵活)。
  • 从 Azure Stack Hub 迁移到 Azure Local:详见配套文档下篇 §E.5 的 5 阶段迁移路径。
相关推荐
seacracker6 小时前
HPC存储I/O抖动无解？PowerFS基于CRDT弱一致架构，彻底实现前台零抖动
架构·分布式存储·powerfs·hpc存储·i/o零抖动
解局易否结局7 小时前
ArkTS 设计模式与架构进阶：构建可维护的 HarmonyOS 应用
华为·设计模式·架构·harmonyos
Swift社区8 小时前
AI 为什么越来越像微服务？
人工智能·微服务·架构
ai_coder_ai9 小时前
基于架构的软件设计方法
架构
AA陈超9 小时前
006 T03 — 蓝图操作指南
c++·游戏·架构·ue5·github·虚幻引擎
●VON10 小时前
鸿蒙 PC Markdown 编辑器导出架构：安全 HTML 与系统 PDF
华为·架构·编辑器·harmonyos·鸿蒙
软件工程师文艺13 小时前
TigerVNC 源码架构深度解析：从协议状态机到拥塞控制的设计哲学
架构
笨蛋不要掉眼泪20 小时前
MySQL架构揭秘：MVCC解决读一致性问题
数据库·mysql·架构
张忠琳21 小时前
【kubernetes】Node Feature Discovery 0.20.0-devel 源码深度解析 — 第四卷：CLI入口、工具链与全局架构总结
云原生·容器·架构·kubernetes·nvidia
热门推荐
012026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片02GitHub 镜像站点03AI科技热点日报 | 2026年07月01日04幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南05如何新建文件夹？ 电脑新建文件夹的4种方法06AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路07国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）082026年AI技术突破与产业落地全景：从GPT-5到多模态智能体的新纪元092026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？10几个好用的ip纯净度检测网站