Azure Stack Hub 套餐、计划与订阅模型深度解析（上篇）

未经同意请勿转载本篇定位面向 Azure Stack Hub 管理员、云架构师、企业 IT 决策者。 以概念模型 → 管理员视角 → 配额参考 → 客户场景套餐选型为主线下篇将聚焦 PowerShell 自动化、与 Azure 的差异、多租户治理与最佳实践。版本基础本文基于 Azure Stack Hub 当前主流 GA 版本2306 / 2311 / 2402 / 2406 等积压版本整理。部分 cmdlet 与门户默认值在不同 OEM 集成系统上可能略有差异以当版本的 Azure Stack Hub Operator 文档为准。目录为什么 Azure Stack Hub 也要谈订阅模型四要素配额 / 计划 / 套餐 / 订阅四要素关系全景图从管理员视角看服务的组装与分发IaaS 配额详解计算 / 网络 / 存储5 步创建流程配额 → 套餐 → 用户订阅套餐状态公开 / 私有 / 退役客户场景实战不同业务如何选套餐上篇小结1. 为什么 Azure Stack Hub 也要谈订阅很多人初识 Azure Stack Hub 时会有一个疑问既然它是部署在客户数据中心的本地 Azure为什么要套一层订阅 / 套餐 / 计划这种云端抽象答案可以从两个角度看第一业务治理的延续性。Azure 上的资源不是用就完了而是要回答几个治理问题谁有权用最多能用多少用的是哪一类服务组合怎么计费 / 怎么报销这些问题的标准答案就是订阅 套餐 计划 配额。Azure Stack Hub 把这套模型原样保留本地管理员就能用企业熟悉的语义来分配资源、隔离环境、区分部门。第二混合云的一致体验。Azure Stack Hub 的核心定位是Azure 在客户数据中心的延伸。当企业要把一部分工作负载从 Azure 公有云迁回本地或反之最理想的状态是管理语义不切换——管理员在 Azure Portal 上习惯了的订阅视图、套餐视图、配额视图在 Azure Stack Hub 管理员门户里仍然存在只是由本地管理员来掌控。因此理解套餐 / 计划 / 订阅就是理解 Azure Stack Hub 如何把资源变成可治理的服务。2. 模型四要素配额 / 计划 / 套餐 / 订阅Azure Stack Hub 的服务治理模型由四个核心概念组成按粒度由小到大排列如下2.1 配额Quota配额决定一个资源使用者可以使用多少资源。每一种资源提供程序Resource Provider都配置有配额计算、网络、存储、Key Vault、SQL、MySQL、App Service、Event Hubs 等。配额只包含使用上限不涉及服务启用 / 禁用。可以为同一种资源创建多个级别的配额例如计算配额-小 / 计算配额-大用于差异化的资源分配。配额既可以全局修改影响所有引用它的计划也可以通过将用户移到另一个配额来定向调整。一个常见的误区很多人以为配额 资源是否可用。配额只决定上限服务的可用性由计划Plan决定。详细见 §2.2。2.2 计划Plan计划是把多个配额组合在一起的逻辑单元。类比移动电话运营商的套餐是把短信分钟数、语音分钟数、流量绑定在一起售卖的。Azure Stack Hub 的计划类似把我能给你多大计算容量 多大存储容量 多少 IP打包成一个粒度适中的服务包。一个计划包含一项或多项服务IaaS / PaaS / SaaS 任选。每项服务都引用一个具体的配额。计划本身不直接面向用户——它是套餐的积木。管理员可以修改现有配额从而调整所有引用该配额的计划的容量也可以为一部分用户新增一个更高规格的计划作为附加计划。举例常见组合计划名包含服务引用的配额Plan-VMs-BaseCompute Storage NetworkCompute-Small / Storage-Default / Network-DefaultPlan-Compute-Large-AddOnComputeCompute-LargePlan-Web-AppServiceApp ServiceAppService-Default2.3 套餐Offer套餐是用户实际看到并能订阅的服务商品。一个套餐包含一个基本计划Base Plan 零个或多个附加计划Add-on Plan。基本计划是订阅该套餐时默认获得的附加计划是用户可以在订阅后追加的也可由管理员代为追加。套餐是用户在订阅 Azure 或 Azure Stack Hub 时看到的内容——这一点很关键套餐决定了用户面对什么样的服务目录。通过不同的套餐组合管理员可以面向不同部门 / 不同项目 / 不同客户提供差异化服务目录。举例Offer IaaS Only Base: Plan-VMs-Base Offer IaaS Web Base: Plan-VMs-Base AddOn: Plan-Compute-Large-AddOn, Plan-Web-AppService同一个 Plan-VMs-Base 可以出现在多个 Offer 中从而实现复用 差异化。2.4 订阅Subscription订阅是用户或组织对一个套餐的实例化。当用户或组织开始使用 Azure Stack Hub 资源时必须先选一个套餐再创建订阅。一个订阅只映射一个套餐即一个订阅属于一个 Offer。一个用户可以拥有多个订阅——例如分别用于测试环境 / 生产环境或不同的计费类别。订阅是资源编排的边界Azure 资源管理器ARM的资源组 / 资源都归属于某个订阅。理解这一点之后订阅在 Azure Stack Hub 上的语义就和 Azure 公有云完全一致了——差别仅在于这个订阅背后映射的套餐是由本地管理员而不是微软定义的。3. 四要素关系全景图用一个全景图把四要素串起来┌──────────────────────────────────────┐ │ 资源提供程序RP │ │ Compute / Storage / Network / … │ └────────────────┬─────────────────────┘ │ 每个 RP 配置一组配额 ▼ ┌──────────────────────────────────────┐ │ 配额Quota │ │ Compute-Small / Compute-Large / … │ └────────────────┬─────────────────────┘ │ 多个配额组合成一个计划 ▼ ┌──────────────────────────────────────┐ │ 计划Plan │ │ Plan-VMs-Base │ │ Compute-Small Storage-Default │ │ Network-Default │ └────────────────┬─────────────────────┘ │ 1 Base N AddOn 组合成一个套餐 ▼ ┌──────────────────────────────────────┐ │ 套餐Offer │ │ Offer-IaaS-Web Base AddOn×2 │ └────────────────┬─────────────────────┘ │ 用户订阅该套餐获得一个订阅 ▼ ┌──────────────────────────────────────┐ │ 订阅Subscription │ │ Subscription-A → 用户/项目/环境 │ └──────────────────────────────────────┘ │ 订阅下创建资源组、VM、网络、存储… ▼ ┌──────────────────────────────────────┐ │ 资源Resource │ │ Resource Group / VM / VNet / … │ └──────────────────────────────────────┘关键不变量配额 → 计划多对一一个计划可以引用多个配额一个配额可被多个计划复用计划 → 套餐多对一 / 一对多一个套餐包含 1 Base N AddOn同一个计划可出现在多个套餐套餐 → 订阅一对多一个套餐可以被多个用户订阅每个订阅都是套餐的一个实例化订阅 → 资源一对多一个订阅下可以有多个资源组和资源记住这张图后面的管理员操作与客户场景都可以在这张图上摆位。4. 从管理员视角看服务的组装与分发Azure Stack Hub 的管理员本质上是云服务的组装者与分发者组装把底层资源提供程序的能力按业务粒度打包成计划。分发把计划按用户角色 / 业务类型组合成不同的套餐再分发给用户或部门。4.1 管理员的组装自由度Azure Stack Hub 管理员可以决定维度管理员的可控范围服务类型决定哪些 RP 上线计算、存储、网络、SQL、MySQL、App Service、Event Hubs、Key Vault 等资源上限每个 RP 下每个配额的具体数值如 VM 数量、vCPU 数、公网 IP 数服务打包把哪些配额装进哪个计划粒度自定服务分发哪些计划是 Base / 哪些是 AddOn构成哪些套餐服务可见性哪些套餐公开、哪些私有、哪些退役详见 §7租户管理多租户场景下是否授权经销商 / CSP 注册客户4.2 经销商 / 多租户场景Azure Stack Hub 支持授权经销商Delegated Provider注册他们自己的客户。这一模型下云管理员Cloud Admin保留对底层资源与全局套餐的最终控制权。经销商Delegated Provider可以为自己的客户创建独立的套餐与订阅。客户的资源使用与计费由经销商负责与云管理员的资源视图相互隔离。这是 Azure Stack Hub 在 CSP / 多租户场景下相比传统本地虚拟化平台vSphere / Hyper-V 集群的一个关键差异租户隔离与服务目录治理是从设计第一天就嵌入的。5. IaaS 配额详解计算 / 网络 / 存储配额是用户实际能消费多少资源的硬上限。下面整理 IaaS 三大类配额的典型项与默认值默认值取自 Azure Stack Hub Operator 文档的参考值实际部署应结合硬件容量评估调整。5.1 计算配额类型默认值参考描述最大虚拟机数量50订阅可在该位置创建的最大 VM 数最大虚拟机核数100订阅可在该位置创建的最大 vCPU 数最大可用性集数量10订阅可在该位置创建的最大 Availability Set 数最大 VMSS 数量100订阅可在该位置创建的最大 VM Scale Set 数最大标准托管磁盘大小GB2048所有标准托管磁盘 标准快照的分配 / 已用总容量最大高级托管磁盘大小GB2048所有高级托管磁盘 高级快照的分配 / 已用总容量5.2 网络配额类型默认值参考描述最大公共 IP 地址数50订阅可在该位置创建的公网 IP 数最大虚拟网络数50订阅可在该位置创建的 VNet 数最大虚拟网关数1订阅可在该位置创建的 VPN 网关数最大网络连接数2订阅可在该位置创建的 P2P / S2S VPN 连接数最大负载均衡数50订阅可在该位置创建的 Load Balancer 数最大虚拟网卡数100订阅可在该位置创建的 NIC 数最大网络安全组数50订阅可在该位置创建的 NSG 数5.3 存储配额类型默认值参考描述最大容量GB2048订阅在该位置可使用的总存储容量含 blob、表、队列、快照最大存储账户数20订阅可在该位置创建的 Storage Account 数5.4 其他资源提供程序的配额简表Resource Provider可配置配额默认参考ComputeYesDefaultNetworkYesDefaultStorageYesDefaultKey VaultNoUnlimitedSQLYesDefault Basic / Standard / Premium / AdminMySQLYesNoneApp ServiceYesDefaultEvent HubsYesDefaultIoT HubNoS2 S3HealthNoNone5.5 设置配额的几个实战要点配额不是容量。配额是允许用户消费的上限实际可用容量取决于物理硬件与 S2D / 超融合集群的实际负载。配额过高会导致理论允许但实际无法分配的资源争用。Capacity Planning 是前置动作。在正式开放订阅前建议先用 Azure Stack Hub Capacity Planner 对集群容量建模再倒推配额上限。Capacity view 在管理员门户的区域管理中可见。配额调整时建议对照容量视图避免承诺超出物理资源的可用量。配额可分级别。同一资源可以创建多个配额如 Compute-Small / Compute-Large通过不同计划打包给不同用户群。SQL 配额的Admin档要谨慎。这是为管理员管理服务器预留的不应下发给普通用户订阅。6. 5 步创建流程配额 → 套餐 → 用户订阅Azure Stack Hub 管理员通过 5 步把资源变成可订阅的服务。下图是从配额到用户订阅的标准流程Step 1 创建配额Compute / Storage / Network / AppService … │ ▼ Step 2 创建计划将一个或多个配额组合到一个 Plan │ ▼ Step 3 创建套餐1 Base Plan N AddOn Plan 1 Offer │ ▼ Step 4 创建订阅管理员为指定用户 / 部门代创建 │ ▼ Step 5 用户自助订阅用户在用户门户中选 Offer自助创建订阅Step 1创建配额进入管理员门户 → 区域管理 → 对应资源提供程序 → 新建配额。命名建议体现资源类型 容量级别便于在计划 / 套餐中复用与辨识Compute-Small (50 VM / 100 vCPU) Compute-Large (200 VM / 500 vCPU) Storage-Default (2 TB) Network-Default (50 PIP / 50 VNet) AppService-DefaultStep 2创建计划进入管理员门户 → 套餐 计划 → 新建计划。一个典型的计划命名为Plan-VMs-Base ├── Compute-Small ├── Storage-Default └── Network-Default计划的是否可作为 AddOn属性在创建时确定。如果该计划是某个套餐的 Base就设为不可作为 AddOn如果它专门用于 AddOn如扩容配额就设为可作为 AddOn。Step 3创建套餐新建 Offer关联 1 个 Base Plan 0 或多个 AddOn PlanOffer-IaaS-Only Base: Plan-VMs-Base Offer-IaaS-Plus-Web Base: Plan-VMs-Base AddOn: Plan-Compute-Large-AddOn AddOn: Plan-Web-AppService套餐的可见性公开 / 私有 / 退役也在这一步设置详见 §7。Step 4创建订阅管理员代操作管理员可以在管理员门户中为指定用户 / 部门 / 项目直接创建订阅选择目标用户从 AAD 用户列表。选择一个公开或私有的套餐。指定订阅名称建议带业务标识例如dev-team-A/prod-project-x。Step 5用户自助订阅普通用户在用户门户登录后进入获取订阅页从可见的套餐列表中选择一个套餐管理员代创建的除外。输入订阅名称。系统自动创建订阅用户立即可以在该订阅下创建资源组与资源。参考文档搜索 - Microsoft 必应7. 套餐状态公开 / 私有 / 退役套餐有三种常见状态分类。这一分类源自运营实践与多个 OEM 集成系统的实际配置选项便于管理员控制服务目录的可见性。状态含义典型使用场景公开Public所有用户可见可自助订阅通用 IaaS / 标准 Web 服务面向全员开放私有Private只对管理员可见 / 仅由管理员代创建订阅内部测试 / 内部 demo / 定制化套餐避免全员误订退役Retired / Decommissioned已下架新订阅无法创建现有订阅不受影响服务下线时的过渡期保留现有用户的资源访问避免一刀切几个实战注意公开 / 私有转换可以随时切换便于灰度发布。例如先把一个新套餐设为私有验证通过后再切到公开。退役 ≠ 删除退役状态保留套餐定义但不接受新订阅。删除套餐会让所有引用它的订阅失效是破坏性操作。状态变更要通知到用户尤其是从公开改为退役时要提前通过公告或工单通知现有订阅者避免误解。多租户下要分用户群控制经销商场景下云管理员可以把公开与私有分配给不同经销商让每个经销商在自己的租户内独立控制可见性。8. 客户场景实战不同业务如何选套餐Azure Stack Hub 落地的真实场景里套餐设计是最容易被低估的环节。下面给出 4 类典型客户场景的套餐选型参考。场景 A金融行业客户——开发测试 vs 生产严格隔离业务诉求开发测试环境与生产环境完全隔离不同订阅、不同套餐、不同计费主体。生产环境需要更高的配额上限业务高峰期峰值。开发测试环境需要快速销毁 重建配额可以小一些。套餐设计Offer-Dev-Test Base: Plan-VMs-Small - Compute-Small (20 VM / 40 vCPU) - Storage-Default (1 TB) - Network-Default (20 PIP / 20 VNet) Offer-Prod-Standard Base: Plan-VMs-Large - Compute-Large (200 VM / 500 vCPU) - Storage-Large (10 TB) - Network-Large (100 PIP / 100 VNet) AddOn: Plan-AddOn-DB - SQL-Premium - MySQL-Default要点Base Plan 必须包含最基础的能力VM 存储 网络任何订阅都要有。数据库 / App Service 等非必备服务放 AddOn用户按需追加——既隔离又灵活。通过私有状态先小范围上线 Prod-Standard验证后再切公开避免一上来就全员误订。场景 B制造行业客户——多工厂分级订阅业务诉求集团下有 6 个工厂每个工厂有不同的资源使用习惯成都工厂用 GPU 推理、上海工厂偏 Web 应用。总集团 IT 想集中管控配额但又要给每个工厂一定的自主权。套餐设计Offer-Group-Standard 全集团通用 Base Base: Plan-VMs-Standard Offer-GPU-Inference-AddOn 仅 GPU 推理工厂追加 AddOn: Plan-GPU-Nvidia Offer-WebApp-AddOn 仅 Web 应用工厂追加 AddOn: Plan-AppService操作建议每个工厂单独建一个订阅sub-plant-cd/sub-plant-sh…共享集团通用 Base按需追加 AddOn。配额按工厂历史用量分级别避免一刀切。场景 C政府/国企客户——套餐私有 手工审批业务诉求所有新订阅需要走 OA 审批流程不能让用户自助订阅。套餐仅管理员可见对普通用户隐藏。套餐设计状态: Private Offer-Internal-IT Base: Plan-Internal-Standard AddOn: Plan-AddOn-DB操作建议套餐设为私有。管理员接到审批单后在管理员门户手动为申请人创建订阅。申请人在用户门户直接看到管理员代创建的订阅无需自助订阅操作。场景 D教育/科研客户——分级别套餐 公开 私有并存业务诉求教学环境学生 / 教师用户量大单订阅配额小公开订阅。科研环境少数课题组配额大私有订阅 手动审批。套餐设计Offer-Teaching-Public 公开 Base: Plan-Teaching-VMs-Small Offer-Research-Private 私有 Base: Plan-Research-VMs-Large AddOn: Plan-GPU-Nvidia AddOn: Plan-AppService操作建议公开 / 私有两套机制并行针对不同人群的治理诉求。科研套餐的配额上限按课题组人数 × 单人配额反向推导避免被单个课题组独占资源。场景选择速查表客户行业 / 场景Base Plan 粒度AddOn 策略套餐可见性金融开发/生产隔离大粒度按环境分数据库 / App Service 走 AddOnProd 私有先验证制造多工厂集团统一 Base按工厂特性推 AddOn公开 私有并存政府国企审批流单一 Base内部按需 AddOn全私有教育科研教学/科研分立按用户角色分GPU / App Service 走 AddOn教学公开 / 科研私有9. 上篇小结本篇我们沿着为什么 → 是什么 → 怎么建 → 怎么用的脉络把 Azure Stack Hub 的配额 / 计划 / 套餐 / 订阅模型完整拆解了一遍概念模型四要素粒度由小到大是 配额 → 计划 → 套餐 → 订阅服务编排路径是 RP → Quota → Plan → Offer → Subscription → Resource。管理员视角管理员是服务的组装者与分发者掌控 6 个维度服务类型 / 资源上限 / 服务打包 / 服务分发 / 服务可见性 / 租户管理。IaaS 配额计算 / 网络 / 存储三大类配额默认值是参考起点实际部署需结合 Capacity Planner 与容量评估调整。5 步创建流程配额 → 计划 → 套餐 → 订阅 → 用户自助订阅每一步都有明确的命名与可见性管理建议。套餐状态公开 / 私有 / 退役三种常见状态可随时切换便于灰度发布与服务下线过渡。客户场景金融、制造、政府国企、教育科研四类典型场景的套餐选型参考与操作建议。下篇我们将进入实战与治理维度PowerShell 自动化New-AzsPlan / New-AzsOffer / Get-AzsUserSubscription 等 cmdlet 的批量操作范式。与 Azure 的差异本地管理员控制 vs 微软控制、套餐生命周期的不同、商用化模型PAYG / Capacity的关联。多租户与经销商治理Delegated Provider 模型的实际操作与边界。最佳实践命名规范、配额分级别、Capacity 与 Quota 的对账、审计与变更管理。作者徐火军Principal Engineer Dell TechnologiesAzure Stack Hub 解决方案首席架构师。下一篇Azure Stack Hub 套餐、计划与订阅模型深度解析下篇