未经同意请勿转载本篇定位上篇把架构 / 虚拟机类型 / 部署体验 / 存储模型讲清楚本篇进入管理与运维维度——Hub 基础架构 VM 生命周期 / 计算资源管理与配额 / 容量公式 / 添加节点 / 市场镜像同步。核心叙事是Azure Stack Hub 的计算不是部署完就完了而是需要在 CRPCompute Resource Provider的管控下持续治理的运行时系统。版本基础本文基于 Azure Stack Hub 早期 GA 介绍材料的工程化整理混合当版本2406 / 2503 等Azure Stack Hub 多代演进的视角撰写。本文对早期版本与当前版本之间的差异做了显式标注目的是从历史维度讲清楚计算治理的设计初衷与演进而不是逐个版本对齐字段。门户默认值、可用 cmdlet、容量上限、镜像格式在不同 OEM 集成系统Dell / HPE / Lenovo 等和不同版本之间可能存在差异当版本与本文描述不一致时以当版本 Azure Stack Hub Operator 文档为准。修订说明v1.02026-07-26本篇为新章首发基于作者 Azure Stack Hub 计算管理与运维介绍资料整理并按当前2026-07写作准则做工程化改写。修订类型关键变更历史视角显式标注全文明确标注基于早期 GA 介绍材料整理区分原始设计目标与当前版本实现。四层原则落地区分L0 版本事实 / L1 微软硬要求 / L2 OEM 实现 / L3 最佳实践对 Gen1/Gen2、放置规则、容量公式、镜像大小等做分层标注。避免硬要求措辞早期材料中只能 / 必须 / 不可 / 强制等绝对化措辞按当前准则降级为通常 / 建议 / 取决于。容量公式严谨化明确标注本节公式是早期材料中的规划模型当前版本以 Azure Stack Hub Capacity Planner 输出为准避免把公式当硬要求。添加节点路径显式标注硬件相关步骤依赖具体 OEM 厂商Dell / HPE / Lenovo出厂规范避免抽象成通用步骤。市场镜像数字审慎30 GB - 127 GB 类数字标注为以当版本市场镜像清单为准。公开术语原则全文使用四层技术事实分类等通用术语不引用内部累计的写作准则。目录Hub 基础架构 VM 生命周期CRP 治理下的特殊运行实体Hub 基础设施 VM 生命周期管理边界计算资源管理内存瓶颈 / 配额 / 容量管理计算容量可放置 VM 内存公式与复原能力保留添加节点扩容 Scale Unit 的物理与逻辑流程市场镜像第三方工作负载的三条分发路径下篇小结与系列收尾附录1. Hub 基础架构 VM 生命周期CRP 治理下的特殊运行实体Azure Stack Hub 的基础架构 VMInfrastructure VM是租户看不见的幕后虚拟机。它们承载 Azure Stack Hub 的核心服务ACS、CRP、NRP、SRP、ERP、Portal、Backup 等由CRPCompute Resource Provider统一管理生命周期。1.1 基础架构 VM 的特殊性维度租户 VM基础架构 VM可见性租户可见User Portal / ARM租户不可见生命周期管理者租户自主创建 / 启动 / 停止 / 删除CRPCompute Resource ProviderGen1 / Gen2通常 Gen1早期实现为 Gen2使用动态内存具体代数随版本演进Portal 显示租户 VM 列表管理员门户中以基础架构角色实例显示放置规则取决于故障域FDCRP 通过放置规则防止相同类型的所有基础架构 VM 落在同一物理主机上1.2 为什么基础架构 VM 要 Gen2 动态内存Gen2相对于 Gen1 提供更现代的虚拟化功能UEFI 启动、安全启动、SCSI 启动等减少遗留 BIOS 复杂性。动态内存允许 Hyper-V 在 VM 空闲时自动回收内存最大化内存利用率——这是基础架构 VM 的关键优化因为基础架构 VM数量相对固定但峰值负载波动。版本演进提示基础架构 VM 的 Gen1 / Gen2 划分、动态内存具体配置在不同版本之间可能会有所调整当前版本的具体实现以 Operator 文档为准。本文不锁定具体代数与配置。1.3 放置规则防止单点故障Azure Stack Hub 的放置规则是L1 微软硬要求——同一类型的基础架构 VM不应全部落在同一物理主机上目的在单台物理主机故障时基础架构 VM 至少有一份实例仍可对外提供服务。实现CRP 在创建 / 重新部署基础架构 VM 时主动避让已经承载同类型基础架构 VM 的物理主机。租户可见性放置规则对租户透明租户无法直接配置。Operator 边界基础架构 VM 的放置与故障恢复策略由系统自动管理Operator 不应直接干预基础架构 VM 的物理位置——这是L1 微软硬要求。2. Hub 基础设施 VM 生命周期管理边界基础架构 VM 的生命周期管理由CRP统一执行Operator 有时也具备启动 / 重启 / 关闭权限。但有一些边界必须明确。2.1 谁做生命周期管理操作CRP 自动执行Operator 手动执行备注创建✅❌部署 Scale Unit 时由系统自动创建启动 / 重启 / 关闭✅按需✅通过 Administrator Portal / PowerShell管理员可手动触发但建议仅在紧急情况下使用删除❌❌基础架构 VM 不应被 Operator 主动删除物理位置 / 放置✅按放置规则❌租户不可见2.2 计算资源控制器不可用时的边界核心原则当 CRPCompute Resource Controller自身不可访问时基础架构 VM 的生命周期管理操作无法执行。这意味着管理员不能绕过 CRP 直接操作基础架构 VM——这是L1 微软硬要求。如果 CRP 自身出现故障需要先恢复 CRP 后才能继续管理其他基础架构 VM。应急场景在 OEM 工程师支持下通过 PEPPrivileged End Point执行底层修复但这是异常路径而非常规操作。2.3 与租户 VM 生命周期的对比维度租户 VM基础架构 VM管理入口User Portal / PowerShell / CLIAdministrator Portal / PowerShell受限故障时的恢复租户自行操作系统自动恢复 管理员辅助删除动作租户可执行Operator 不应执行审计日志租户操作日志管理员审计日志 系统日志3. 计算资源管理内存瓶颈 / 配额 / 容量Azure Stack Hub 的计算资源管理是Operator 日常运维的核心战场。它要回答三个关键问题内存会成为瓶颈吗CPU 配额需要多大容量扩展只能靠加节点吗3.1 内存最容易触发告警的维度Azure Stack Hub 的内存使用极其紧张——这是L1 微软硬要求级别的设计取舍告警 / 警报阈值85% 使用率系统发出告警Warning——意味着资源进入紧张状态。95% 使用率系统发出警报Critical——意味着资源即将耗尽。内存耗尽的后果新 VM 部署可能失败已有 VM 启动可能失败严重时基础架构 VM 自身也会受影响。同时消耗内存的实体基础架构 VM系统内部资源租户 VM用户工作负载。关键提示内存耗尽会导致 VM 部署 / 启动失败——这是 §4 容量公式设计的核心动机。3.2 CPU 配额vCPU 总数可大于物理 CPU 数量一个常见误解Azure Stack Hub 不能 CPU overcommit。事实Azure Stack Hub 支持 CPU 配额层面的 overcommit——租户 VM 的 vCPU 总数可以大于物理 CPU 数量。但实际性能取决于Hyper-V 调度、CPU 抢占开销、VM 放置位置等。Quota 维度CPU 配额基于核心数。物理容量维度物理 CPU 数量由 Scale Unit 实际硬件决定。最佳实践不要无限 overcommit——CPU 配额的总和与物理 CPU 数量应有合理比例L3 最佳实践非微软硬要求。3.3 配额Quota的六大维度Azure Stack Hub 的Compute 配额不只覆盖 vCPU / VM 数量还包括6 个维度维度含义典型单位核心数vCPU 总数vCPU 数量虚拟机数量VM 实例总数VM 数可用性集同一 FD 内的 VM 组可用性集数虚拟机规模集VMSS 实例组VMSS 数标准托管磁盘不带高级 SSD 的磁盘GB高级托管磁盘带高级 SSD 的磁盘GB版本演进提示配额维度在不同 Azure Stack Hub 版本之间可能有所调整当前版本的完整维度清单以 Operator 文档为准。本文不展开枚举。3.4 容量扩展只能加节点Azure Stack Hub 的物理容量扩展只能通过增加新节点——这是L1 微软硬要求不支持在 Scale Unit 内physical CPU / RAM 升级不能把 16 核 CPU 换成 32 核。支持通过添加节点Add Scale Unit Node扩展 Scale Unit 规模。节点前提新增节点必须与现有节点完全同型同配同型号 / 同 CPU / 同 RAM / 同磁盘配置 / 同 firmware baseline——这是L2 OEM 集成要求。3.5 配额 vs 容量核心区分Quota 是逻辑限制约束上限物理容量是 Scale Unit 实际拥有的资源。Quota 生效在 User Portal / API 创建资源时立即校验。实际使用取决于真实部署的 VM占用。Operator 必须做 Quota 与物理容量的对账——这是上篇套餐 / 计划 / 订阅系列1中提到的Capacity vs Quota 对账的核心场景。4. 管理计算容量可放置 VM 内存公式与复原能力保留重要声明本节公式是 早年 Azure Stack Hub Capacity Planner 的规划模型整理。当前版本的容量计算以当版本 Azure Stack Hub Capacity Planner 工具输出为准——本文不替代官方工具的精确计算仅作为理解容量模型的设计逻辑之用。4.1 容量规划要回答的两个问题Azure Stack Hub 的 VM 放置需要考虑两个核心问题主机上是否有足够的可用内存VM 是可用性集的一部分还是 VMSS 的一部分4.2 可用于 VM 放置的内存公式可用内存 主机总内存 - 复原能力保留内存 - 运行租户 VM 所使用的内存 - Azure Stack Hub 基础设施开销这是一个逻辑容量概念不是物理内存的精确减法——实际计算涉及多变量叠加。4.3 复原能力保留内存的物理含义复原能力保留Resiliency Reserve是 Azure Stack Hub 的N1 容错模型——在 Scale Unit 失去一台物理主机时整个 Scale Unit 仍能通过剩余主机承接工作负载。关键术语复原能力保留是Scale Unit 失去一台主机时仍能保持整体可用性的内存预留。本文不展开具体数值——这是L0 版本事实实际值以当版本 Capacity Planner 输出为准。4.4 公式中的变量变量含义备注H单个服务器的内存大小物理服务器配置NScale Unit 大小服务器数量物理服务器总数R针对 OS 开销的操作系统保留本文采用的早期模型取 0.15即 15%具体数值以当版本 Capacity Planner 为准VScale Unit 中最大的 VM单一 VM 占用上限4.5 容量公式的工程含义本节内容是 L3 最佳实践非微软硬要求。不要凭直观估算容量——必须使用Capacity Planner工具。容量公式是规划模型——实际运行时的内存使用受VM 放置、租户行为、基础设施波动等多重影响。残留容量告警阈值85% → 告警Warning95% → 警报Critical容量耗尽的影响新 VM 部署 / 启动失败详见 §3.1。扩容手段通过添加节点扩展 Scale Unit详见 §5。易踩坑点Version 1.0 早期容量公式误把 Resiliency Reserve 理解为(N-1) × M是常见错误。正确理解是Scale Unit 失去一台主机时仍能保持整体可用性的内存预留——这是N1 容错模型不是简单的扣除 N-1 台主机。5. 添加节点扩容 Scale Unit 的物理与逻辑流程添加节点Add Scale Unit Node是 Azure Stack Hub 扩展容量唯一的合法路径。本节把整体流程拆成物理步骤 逻辑步骤。5.1 整体流程概览┌──────────────────────────────────────────────────────────┐ │ 1. 物理准备 │ │ - 物理服务器上架 │ │ - 网络电缆连接 │ │ - BMC IP 配置 BIOS 设置 │ │ - 固件基线同步 │ ├──────────────────────────────────────────────────────────┤ │ 2. 逻辑操作 │ │ - 管理员门户 / PowerShell 调用 Add Node 操作 │ │ - 验证 Scale Unit 状态 │ └──────────────────────────────────────────────────────────┘5.2 物理步骤依赖 OEM 集成规范关键提示物理步骤的具体细节依赖 OEM 集成系统Dell / HPE / Lenovo 等的出厂规范。本节列出通用流程骨架不替代 OEM 厂商的安装手册。步骤操作备注1. 物理部署将新服务器放置在机架中使用电缆连接电源 / 网络遵循 OEM 机架规范2. 交换机配置启用物理交换机端口并调整 ACLToR 交换机配置必须与现有 Scale Unit 保持一致——这是L2 OEM 集成要求3. BMC 配置在基板管理控制器BMC中配置正确的 IP 地址BMC 是 Out-of-Band 管理通道必须与现有 Scale Unit 同一网段4. BIOS 设置根据 OEM 规范应用所有 BIOS 设置BIOS 设置必须与现有节点完全一致——这是L2 OEM 集成要求5. 固件基线同步在 HLHHardware Lifecycle Host上运行 OEM 工具将当前固件基线应用于所有组件固件版本不对齐会导致节点添加失败6. 验证物理就绪通过 BMC / HLH 验证节点可被 OEM 工具识别进入下一步前必须确认5.3 逻辑步骤管理员门户 PowerShell物理就绪后Operator通过 Azure Stack Hub 管理员门户执行添加节点操作步骤操作备注1. 进入 Add Node管理员门户 → Region Management → Scale Unit Nodes → Add按当版本路径调整2. 选择节点列出可添加的物理节点基于 BMC 发现只能选择与现有节点同型同配的节点3. 启动添加系统开始自动化部署耗时数小时期间不能中断4. 验证状态在 Scale Unit 状态中查看节点是否就绪新节点变为 Available 才算成功5.4 添加节点的关键约束约束原因性质新增节点必须与现有节点完全同型同配Scale Unit 是统一硬件池混搭会导致故障域 / 性能不一致L2 OEM 集成要求固件基线必须一致不同固件版本在 BIOS / NIC / 磁盘控制器上可能行为不一致L2 OEM 集成要求ToR 交换机配置必须与现有节点一致网络栈统一性L2 OEM 集成要求添加节点期间不能中断部分操作不可回滚L1 微软硬要求同一 Scale Unit 一次只能添加一个节点避免批量并发导致集群抖动L1 微软硬要求具体并发上限以当版本文档为准关键提示具体的并发上限、节点最大规模、Scale Unit 节点总数等参数随版本演进。本文不锁定具体数字——实际部署前请查阅当版本 Azure Stack Hub Operator 文档与Microsoft Lifecycle 页面。5.5 添加节点后的验证节点状态在 Scale Unit 状态中显示Available。资源可见性Operators 端为该节点创建 NVMe / 内存的容量可见。故障域新节点自动纳入 Scale Unit 的故障域FD规划。基础架构 VM 布局CRP 会按放置规则重新规划基础架构 VM 在新节点上的分布。6. 市场镜像第三方工作负载的三条分发路径Azure Stack Hub 的市场Marketplace是第三方工作负载进入 Azure Stack Hub 的标准入口。它提供三类内容6.1 镜像同步Image SyncImage Sync是 Azure Stack Hub 接入 Azure 公有云 Marketplace 的官方机制流程Operator 在管理员门户中注册 Azure 公有云 Marketplace选择需要同步的镜像系统后台下载处理后的镜像Azure Stack Hub 专用格式。限制镜像通常较大30-127 GB 范围以当版本市场镜像清单为准磁盘空间消耗每个镜像都会占用存储池容量需要 Operator 在容量规划中预留。典型镜像Windows Server 各版本、各 Linux 发行商官方镜像、SQL Server 镜像、Bitnami 应用镜像等。关键提示镜像大小数字会随当版本镜像清单变化——本文列出的30-127 GB只是参考范围实际部署请以当版本 Azure Stack Hub Marketplace 镜像清单为准。6.2 应用程序扩展同步Application Extension SyncApplication Extension是 Azure Stack Hub 上的应用层扩展机制范围包含第一方微软 第三方应用程序扩展。典型内容SQL Server 扩展、Antimalware 扩展、Custom Script 扩展、监控类扩展等。限制并非所有 Azure 公有云扩展都同步到 Azure Stack Hub——可用扩展集合以当版本市场清单为准。6.3 自定义镜像Custom ImageCustom Image是 Operator 自行准备的私有镜像适用场景企业内部定制化 Windows / Linux 镜像含预装软件 / 配置 / 域加入脚本。使用方式通过管理员门户或 PowerShell 上传租户可基于 Custom Image 创建 VM。Linux 镜像要求Linux 镜像需要 walinuxagent v2.2.22具体版本要求以当版本文档为准——这是L1 微软硬要求。6.4 市场镜像对存储容量的影响本节内容是 L3 最佳实践非微软硬要求。每个同步的镜像都会占用存储池容量——50 个镜像 × 平均 60 GB 3 TB 存储空间占用。镜像副本不可直接删除——只能通过Retire 镜像进行软下线详见上篇 OSS 行的可观测性设计。建议在 Scale Unit 容量规划中预留 5-10% 的存储空间用于市场镜像。7. 下篇小结与系列收尾7.1 下篇小结本篇把上篇的架构 / 虚拟机类型 / 部署体验 / 存储模型推到管理与运维维度Hub 基础架构 VM 生命周期由 CRP 统一管理Gen2 动态内存是早期实现的关键设计放置规则防止单点故障是L1 微软硬要求。生命周期管理边界CRP 不可用时无法管理基础架构 VMOperator 不应直接删除基础架构 VM紧急情况通过 PEP 修复是异常路径。计算资源管理内存是最容易触发告警的维度85% 告警 / 95% 警报vCPU overcommit 由 Hyper-V 调度实现扩容只能通过添加节点L1 微软硬要求。配额覆盖 6 个维度核心 / VM / 可用性集 / VMSS / 标准托管盘 / 高级托管盘Quota 是逻辑限制≠ 物理容量。容量公式早期 Capacity Planner 模型提供可放置 VM 内存公式复原能力保留是 N1 容错模型当前版本以 Capacity Planner 工具输出为准。添加节点唯一的扩容量路径物理步骤依赖 OEM 规范关键约束是新增节点必须与现有节点完全同型同配 固件基线一致 ToR 配置一致。市场镜像Image Sync / Application Extension / Custom Image 三条分发路径镜像大小范围 30-127 GB 是参考范围建议预留 5-10% 存储空间用于市场镜像。版本演进视角本篇以早期 GA 介绍资料为基线显式标注与当前版本的差异实际部署时以当版本 Operator 文档为准。7.2 全系列收尾上篇架构四层 VM 类型 性能仿真边界 部署体验 托管磁盘 临时磁盘。下篇本篇Hub 基础架构 VM 生命周期 计算资源管理 容量公式 添加节点 市场镜像。整个系列的核心叙事始终围绕一个观点Azure Stack Hub 的计算不是几台服务器上的虚拟机而是在 ARM 控制面 CRP / NRP / SRP 协同治理下由 Quota / Plan / Offer / Subscription 围绕承载的云服务资源。Operator 的角色不是管理几台 Hyper-V而是运营一朵云的计算资源池。希望这个系列能帮助更多管理员从虚拟化思维切换到云运营思维把 Azure Stack Hub 的计算服务真正用成可治理的云服务。8. 附录附录 A本文涉及的关键概念速查概念定义所在章节CRPCompute Resource Provider管控租户 VM 与基础架构 VM 生命周期§1, §2基础架构 VM承载 Azure Stack Hub 内部服务、租户不可见的 VM§1, §2放置规则防止相同类型基础架构 VM 落在同一物理主机的策略§1.3优先级端点PEPPrivileged End Point紧急修复入口§2.2Quota逻辑资源限制约束上限§3.3复原能力保留Scale Unit N1 容错模型的内存预留§4.3Capacity PlannerAzure Stack Hub 容量规划工具§4Scale Unit一组协同提供 Azure Stack Hub 服务的物理服务器集合§5添加节点唯一的扩容量路径§5HLHHardware Lifecycle Host硬件生命周期管理主机§5.2BMC基板管理控制器Out-of-Band 管理通道§5.2Image Sync市场镜像同步§6.1Application Extension应用程序扩展§6.2Custom Image自定义镜像§6.3walinuxagentLinux VM 的 Azure 代理§6.3附录 B版本事实与历史数字的说明本附录是本文四层技术事实分类的显式落地目的是让读者理解哪些内容是早期材料中的参考描述、哪些是当版本以来可能调整的具体数字。内容层级说明可用 VM 系列A / Av2 / D / Dv2 / DS / DSv2 / F / Fs / Fsv2L0 版本事实早期 GA 介绍材料中的清单当前版本支持的系列以当版本文档为准基础架构 VM 使用 Gen2 动态内存L0 版本事实早期实现描述当前版本的具体实现以当版本文档为准放置规则防止同类型基础架构 VM 落在同一物理主机L1 微软硬要求跨版本稳定的设计原则内存告警阈值 85% / 警报阈值 95%L0 版本事实早期材料中的参考值当前版本可能调整Scale Unit 容量扩展只能通过添加节点L1 微软硬要求跨版本稳定的设计原则新增节点必须与现有节点完全同型同配L2 OEM 集成要求跨 OEM 集成系统的稳定要求R 0.15OS 开销保留 15%L0 版本事实早期容量公式中的参考值当前版本以 Capacity Planner 输出为准Linux 镜像需要 walinuxagent v2.2.22L0 版本事实早期材料中的版本要求当前版本可能升级镜像大小 30-127 GBL0 版本事实早期材料中的参考范围当前版本以当版本市场清单为准Quota 6 个维度核心 / VM / 可用性集 / VMSS / 标准托管盘 / 高级托管盘L0 版本事实早期材料中的维度清单当前版本可能调整预留 5-10% 存储空间用于市场镜像L3 最佳实践行业经验非微软硬要求添加节点时不能中断L1 微软硬要求跨版本稳定的设计原则同一 Scale Unit 一次只能添加一个节点L0 版本事实早期材料中的描述当前版本可能调整并发上限附录 C参考文档路径以当版本 Azure Stack Hub Operator 文档为准本文列出的 URL 是当版本 Active 期间的入口地址不预测未来路径变更。Azure Stack Hub Operator 文档主入口Azure Stack Hub Documentation - Tutorials, API Reference | Microsoft LearnCapacity Plannerhttps://learn.microsoft.com/en-us/azure-stack/capacity-planner/添加节点扩容 Scale UnitAdd scale unit nodes in Azure Stack Hub - Azure Stack Hub | Microsoft Learn基础架构 VM 概念https://learn.microsoft.com/en-us/azure-stack/operator/azure-stack-infrastructure-vm配额类型Quotas and quota types in Azure Stack Hub - Azure Stack Hub | Microsoft Learn托管磁盘注意事项Azure Stack Hub managed disks differences and considerations - Azure Stack Hub | Microsoft Learn市场镜像同步https://learn.microsoft.com/en-us/azure-stack/operator/azure-stack-marketplace创建自定义镜像https://learn.microsoft.com/en-us/azure-stack/operator/azure-stack-create-and-offerm-vm-imageVisual Studio 集成Install Visual Studio and connect to Azure Stack Hub - Azure Stack Hub | Microsoft Learn作者徐火军Principal Engineer Dell TechnologiesAzure Stack Hub 解决方案首席架构师。上篇回顾Azure Stack Hub 计算服务从架构组件到虚拟机类型与存储模型上篇
