未经同意，请勿转载！
本篇定位 ：面向 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）
配额决定一个资源使用者可以使用多少资源。
- Azure Stack Hub 的 Quota 主要用于具有容量限制的 Resource Provider，例如 Compute、Network、Storage，以及部分 PaaS Resource Provider。部分平台服务通过服务级配置控制，并不存在租户级 Quota。
- 配额只包含使用上限，不涉及服务启用 / 禁用。
- 可以为同一种资源创建多个级别的配额（例如"计算配额-小" / "计算配额-大"），用于差异化的资源分配。
- 配额既可以全局修改（影响所有引用它的计划），也可以通过"将用户移到另一个配额"来定向调整。
一个常见的误区：很多人以为"配额 = 资源是否可用"。配额只决定"上限"，服务的可用性由计划（Plan）决定。 详细见 §2.2。
2.2 计划（Plan）
计划是把多个配额组合在一起的逻辑单元。
类比：移动电话运营商的"套餐"是把短信分钟数、语音分钟数、流量绑定在一起售卖的。Azure Stack Hub 的"计划"类似，把"我能给你多大计算容量 + 多大存储容量 + 多少 IP"打包成一个粒度适中的服务包。
- 一个计划包含一项或多项服务（IaaS / PaaS / SaaS 任选）。
- 每项服务都引用一个具体的配额。
- 计划本身不直接面向用户------它是套餐的"积木"。
- 管理员可以修改现有配额 ，从而调整所有引用该配额的计划的容量；也可以为一部分用户新增一个更高规格的计划作为附加计划。
举例（常见组合）：
|--------------------------|-----------------------------|---------------------------------------------------|
| 计划名 | 包含服务 | 引用的配额 |
| Plan-VMs-Base | Compute + Storage + Network | Compute-Small / Storage-Default / Network-Default |
| Plan-Compute-Large-AddOn | Compute | Compute-Large |
| Plan-Web-AppService | App Service | AppService-Default |
2.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 ，并继承该 Offer 中定义的服务能力。Subscription 是用户对 Offer 服务目录的消费实例，同时可以根据授权增加 Add-on Plan。
- 一个用户可以拥有多个订阅------例如分别用于"测试环境" / "生产环境"，或不同的计费类别。
- 订阅是资源编排的边界：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 数 |
| 最大标准托管磁盘大小（GB） | 2048 | 所有标准托管磁盘 + 标准快照的分配 / 已用总容量 |
| 最大高级托管磁盘大小（GB） | 2048 | 所有高级托管磁盘 + 高级快照的分配 / 已用总容量 |
5.2 网络配额
|-------------|-------------|------------------------------|
| 类型 | 默认值（参考） | 描述 |
| 最大公共 IP 地址数 | 50 | 订阅可在该位置创建的公网 IP 数 |
| 最大虚拟网络数 | 50 | 订阅可在该位置创建的 VNet 数 |
| 最大虚拟网关数 | 1 | 订阅可在该位置创建的 VPN 网关数 |
| 最大网络连接数 | 2 | 订阅可在该位置创建的 P2P / S2S VPN 连接数 |
| 最大负载均衡数 | 50 | 订阅可在该位置创建的 Load Balancer 数 |
| 最大虚拟网卡数 | 100 | 订阅可在该位置创建的 NIC 数 |
| 最大网络安全组数 | 50 | 订阅可在该位置创建的 NSG 数 |
5.3 存储配额
|----------|-------------|---------------------------------|
| 类型 | 默认值（参考） | 描述 |
| 最大容量（GB） | 2048 | 订阅在该位置可使用的总存储容量（含 blob、表、队列、快照） |
| 最大存储账户数 | 20 | 订阅可在该位置创建的 Storage Account 数 |
5.4 其他资源提供程序的配额（简表）
|-----------------------|-----------|--------------------------------------------|
| Resource Provider | 可配置配额 | 默认参考 |
| Compute | Yes | Default |
| Network | Yes | Default |
| Storage | Yes | Default |
| Key Vault | No | Unlimited |
| SQL | Yes | Default Basic / Standard / Premium / Admin |
| MySQL | Yes | None |
| App Service | Yes | Default |
| Event Hubs | Yes | Default |
| IoT Hub | No | S2 & S3 |
| Health | No | None |
5.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 Plan：
Offer-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） | 已下架，新订阅无法创建；现有订阅不受影响 | 服务下线时的过渡期，保留现有用户的资源访问，避免一刀切 |
几个实战注意：
- 公开 / 私有转换：可以随时切换，便于灰度发布。例如，先把一个新套餐设为私有，验证通过后再切到公开。
- 退役 ≠ 删除：退役状态保留套餐定义但不接受新订阅。删除套餐会让所有引用它的订阅失效，是破坏性操作。
- 状态变更要通知到用户：尤其是从公开改为退役时，要提前通过公告或工单通知现有订阅者，避免误解。
- 多租户下要分用户群控制：经销商场景下，云管理员可以把"公开"与"私有"分配给不同经销商，让每个经销商在自己的租户内独立控制可见性。
注意：Retired 并不是 Azure Stack Hub Offer 对象中的原生属性，而是云运营团队对服务下线阶段的一种管理策略。
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 走 AddOn | Prod 私有先验证 |
| 制造（多工厂） | 集团统一 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 Technologies，Azure Stack Hub 解决方案首席架构师。 下一篇：Azure Stack Hub 套餐、计划与订阅模型深度解析（下篇）