未经同意，请勿转载！
适用版本：Azure Local 12.2602.1002.501（2602） → 12.2606.1003.205（2606）
文档来源：What's new in Azure Local / Azure Local Overview / Disaggregated deployment / Azure Local Catalog
维护版本：v1.3 · 2026-07-21 · ACP 评审第三轮 · 措辞收敛与事实修正版
导读：Azure Local 是什么（已不是 Azure Stack HCI 的简单演进）
Azure Local 已从Azure Stack HCI 的演进版本，逐步扩展为覆盖HCI、外部 SAN、边缘 AI、混合云管理等多种部署模式的统一基础设施平台。
——这是本文的总纲。
TL;DR
- 2604 不是普通的月度 release——它是 Azure Local 产品线的"架构转折点"。微软在 2604 开始正式形成的多项 GA 能力，可以归纳为4 个架构跃迁支柱：
- 支柱 1 · 存储解耦：从"超融合 HCI 必选"到"FC SAN GA + Disaggregated 部署"——存储与计算可以独立扩展
- 支柱 2 · 异构计算：从"DDA 整卡独占"到"DDA + GPU-P 正式支持"——x86 之外引入 GPU 作为 Azure Local 官方支持的基础资源类型之一
- 支柱 3 · 自带身份：从"必须依赖 Microsoft Entra ID"到"Local Identity + Key Vault GA"——弱连接 / 气隙部署可行
- 支柱 4 · 自助编排：从"微软默认编排"到"Update orchestration configuration + Domain Join 预部署"——客户可自定义部署与更新节奏
- 2606 以质量修复和稳定性提升为主，没有引入新的重大平台能力。本文统一使用保守表述，避免把"质量维护版本"绝对化为"没有任何 GA"——以防后续 release 出现变 GA 的 preview 能力时本文被反向引用。
- 本篇用 4 个跃迁支柱叙事替代逐 Feature 罗列——读者拿到的是"产品形态演进"，不是"feature 列表"。
- 作者声明：本文将 Azure Local 2604 之后的产品形态概括为"Cloud Infrastructure Platform"，属于作者总结，并非微软官方产品定位——用于帮助理解 Azure Local 的产品演进方向。微软官方文档更多使用 Distributed Cloud / Adaptive Cloud / Azure Local / Infrastructure Platform 等术语。
一、跃迁叙事：Azure Local 三阶段产品形态演进
1.1 三阶段时间线
1.2 三阶段产品形态对照
维度 | 23H2 时代（2602 之前） | 2602 / 2603（过渡期） | 2604+（架构跃迁后） |
存储路线 | 仅 S2D HCI | 仅 S2D HCI | HCI / FC SAN / Disaggregated 三选 |
GPU 模式 | 仅 DDA | DDA + Blackwell 引入 | DDA + GPU-P（GA）+ Blackwell |
身份模式 | Microsoft Entra ID 必须 | Microsoft Entra ID 必须 | Microsoft Entra ID / Local Identity + KV 二选 |
更新编排 | 微软默认 | 微软默认 | 客户可自定义 |
部署自动化 | 手动加入集群 | Simplified Provisioning | Domain Join 预部署 + 全自动 |
产品定位 | HCI Appliance（超融合一体机） | HCI Appliance 增强 | 基础设施平台（详见作者声明） |
一·附：为什么 2606 没有新的平台能力？
很多读者会问：2606 是不是"没东西"？
事实上 2606 是稳定性版本（Quality Release），微软 release cadence 通常遵循：
Feature Release → Quality Release → Feature Release → ...- 2604：Feature Release——一次性 GA 一批能力
- 2606：Quality Release——质量修复、稳定性提升、安全补丁为主
2606 体现的是平台成熟，而不是产品形态再次变化。
这也是为什么 2606 看起来"没有新 Feature"——它本来就不是 Feature Release。
二、为什么 2604 集中推出这些能力？
理解 2604 的产品定位，先回答一个问题：为什么微软会在 2604 集中推出这批 GA 能力？
可以归纳为 5 个相互交织的原因：
2.1 原因 1：Azure Stack HCI 时代定位过窄
Azure Stack HCI 的产品定位是"HCI Appliance"——超融合一体机，所有能力都围绕"本地 + 集中"假设设计。随着客户场景多样化（边缘、混合云、AI），单一 HCI 形态已经无法覆盖。
2.2 原因 2：AI 工作负载推动 GPU 能力
GPU 从少数客户的"可选外设"变成主流 AI 推理 / 微调 / RAG 的必需资源。Azure Local 必须把 GPU 从"少数高端客户的可选"提升到"Azure Local 官方支持的基础资源类型之一"。
2.3 原因 3：SAN 客户无法迁移
大量企业数据中心有现成的 FC SAN 投资。Azure Stack HCI 只支持 S2D HCI，意味着这些客户的现有基础设施不能被 Azure Local 复用。SAN GA + Disaggregated 部署直接解决了"已有 SAN 投资的客户如何上 Azure Local"。
2.4 原因 4：边缘客户需要弱连接
零售、制造、政府、军工等边缘场景无法保证稳定的 Microsoft Entra ID 联通。Local Identity + Key Vault 让部署不再依赖云端身份验证。
2.5 原因 5：微软希望 Azure Local 覆盖更多基础设施市场
Azure Local 正在逐步承担 Azure 在本地基础设施中的统一控制平面角色——其能力演进已从"虚拟化平台"转向"混合云基础设施平台"。
架构师笔记：这 5 个原因不是孤立的——它们共同指向"Azure Local 必须从单一 HCI Appliance 演进为可组合的基础设施平台"。这也是 4 个跃迁支柱为什么同时集中在 2604 出现的根本原因。
三、4 个跃迁支柱的关系：不是并列，而是 Cloud Platform 总线
4 支柱的依赖关系：
关系 | 说明 |
Storage ↔ Compute | 存储解耦后，计算节点才能真正独立扩展；异构计算（GPU-P）才有部署灵活性的基础 |
Identity → Orchestration | Local Identity 是 Domain Join 预部署（OS 阶段加入域）的信任前提 |
Orchestration → 其他三支柱 | Update orchestration configuration 让三大支柱的能力可被客户自定义节奏部署 |
四、支柱 1：存储解耦——从耦合到独立扩展
4.1 跃迁前（2602 时代）
Azure Local 2602 的存储模型只有一种：
- 耦合：每节点的 CPU 与本地盘必须共生死——加存储必须加节点，加计算也必须带盘
- 扩展上限：HCI 集群 1~16 节点
- 运维负担：故障盘 → 整机风险；扩存储 → 加整机 → 重新平衡 S2D 池
4.2 跃迁后（2604+）
2604 GA 的 FC SAN + Disaggregated 部署打破了这个绑定：
- 解耦：存储资源池与计算节点独立采购、独立扩展、独立故障域
- 扩展选项：HCI（1~16）/ Disaggregated（独立上限，以 Disaggregated 文档 为准）
- 新运维模型：存储故障不再绑架计算；计算扩容不再绑架存储
4.3 跃迁带来 4 项 GA 能力
能力 | 性质 | 跃迁意义 |
SAN 存储（FC）GA | 与 S2D 并存 | 引入外部存储路线 |
Disaggregated 部署 GA | 集群只走 SAN | 解耦形态正式 GA |
Rack-aware + Local Identity 组合 | 2604 才完整支持 | 多机架场景下的解耦部署 |
Azure Migrate 支持 SAN 目标（含 NTFS 卷） | 2605 | 数据中心迁移可走 SAN |
4.4 选型决策树
你需要的存储容量/性能 是否经常超过本地盘的扩展能力？ ├─ 否 → 保持 HCI（2602 也够用） └─ 是 → 进一步评估： ├─ 已有 FC SAN 投资 → Disaggregated（2604+） ├─ 没 FC 交换机 → iSCSI 预览（2605+，仅评估） └─ 完全新建 → 视总拥有成本决定 HCI vs Disaggregated4.5 重要约束
- SAN 与 S2D 是并存关系，不是替代关系——文档明示 SAN 与 S2D "alongside"
- Disaggregated ≠ "无限扩容"——核心价值是扩展部署拓扑选择，不是绕过任何硬性的集群规模上限
- SAN 设备仍需符合 Azure Local 支持矩阵——具体哪些 SAN 厂商 / 型号可用，参考 Azure Local Catalog 与 External Storage 文档
- iSCSI 是 preview（2605）——生产请等 GA
- Azure Local 并不会把 FC SAN 纳入 Storage Spaces 管理——SAN 存储仍由外部阵列自身负责数据服务（快照 / 复制 / 容灾）与生命周期管理。Azure Local 只是消费 LUN，把 SAN 当作 VM 数据卷的物理载体使用。读者不应误以为"Azure Local 接 SAN = Storage Spaces 接 SAN"，两者是完全不同的管理模型。
五、支柱 2：异构计算——从 x86 到 GPU 基础资源
5.1 跃迁前（2602 时代）
- DDA（Discrete Device Assignment）：整卡通过 PCIe passthrough 独占分配给单 VM，较早期即 GA
- GPU-P（GPU Partitioning）：Azure Local不支持（直到 2604 GA）
澄清一个常见误解：GPU-P技术本身在 Windows Server / Hyper-V 上一直存在；Azure Local从 2604 起才正式支持这种能力。
5.2 跃迁后（2604+）
2604 把 GPU-P 升级为正式支持能力（GA），与 DDA 并存：
模式 | 隔离机制 | 调度方式 | 适用 |
DDA | PCIe 硬件级独占 | 无调度 | 高端 AI 训练 / 推理、对隔离有严格要求的负载 |
GPU-P | 单卡切多 partition | Windows Hyper-V GPU Partitioning + NVIDIA 驱动协同 | 中等负载 / 多租户共享 / 节省成本 |
关键技术澄清：Azure Local 的GPU-P 基于 Windows Hyper-V 的 GPU Partitioning 能力，由NVIDIA 提供驱动协同工作。这是与 NVIDIA vGPU Manager 的不同技术路径——NVIDIA vGPU Manager 是 NVIDIA vGPU 软件栈（vGPU License / DLS 等）的一部分，不是Azure Local GPU-P 的实现基础。
5.3 跃迁带来 4 项 GA / 新能力
能力 | 性质 | 跃迁意义 |
GPU-P 正式支持（GA） | 2604 | partition 模式正式可用 |
NVIDIA RTX PRO 6000 Blackwell | 2603 | 新一代数据中心 GPU 支持 |
GPU-P Azure Monitor 指标 | 2605 | partition 级监控（容量规划、热点识别） |
DDA + GPU-P Day-2 热挂/卸载 | 2604 | 不停机调整 GPU 分配 |
5.4 跃迁带来的产品定位变化
跃迁前：Azure Local 是x86 HCI Appliance——GPU 是少数高端客户的"可选外设"。
跃迁后：GPU 已成为Azure Local 官方重点支持的资源类型之一，与 vCPU / 内存 / 存储并列。
GPU-P 与 DDA 的支持矩阵区别（容易被忽略的关键事实）：
- GPU-P 并不适用于所有支持 DDA 的 GPU
- GPU-P 是否可用取决于GPU 型号 / 驱动版本 / Azure Local 支持矩阵
- 例如：消费级 GPU 即使能跑 DDA，也可能不支持 GPU-P
- 部署 GPU-P 之前，必须参考 Prepare GPUs for Azure Local instance 与 OEM Support Matrix
- 这是微软一直强调的——本文在此显式补充，避免读者误以为"DDA 支持 = GPU-P 支持"
5.5 选型决策
场景 | 推荐 |
单卡跑满一个 VM，对隔离有严格要求 | DDA |
单卡分给多 VM，需要容量规划 / 多租户 | GPU-P + 监控 |
全新部署 | 视 OEM SKU 与 NVIDIA vGPU 许可证模式决定 |
六、支柱 3：自带身份——从 cloud-dependent 到 cloud-optional
6.1 跃迁前（2602 时代）
Azure Local 部署必须接入 Microsoft Entra ID 才能完成注册——这对气隙（air-gapped）/ 弱连接客户是硬约束。
6.2 跃迁后（2604+）
2604 GA 的 Local Identity with Key Vault 让部署不再强依赖 Microsoft Entra ID：
- 本地身份：集群自带身份，在部署身份方面不再强依赖 Microsoft Entra ID
- 客户控制 Key Vault：凭据加密存储在客户自己管理的 Key Vault
- 典型场景：政府 / 军工 / 金融客户的气隙或弱连接环境
6.3 跃迁带来 3 项 GA 能力
能力 | 性质 | 跃迁意义 |
Local identity with Key Vault GA | 2604 | 自带身份正式可用 |
Rack-aware + Local Identity 组合 | 2604 | 多机架 + 自带身份的部署组合 |
Rack-aware clustering 增强 | 2604 | 多机架场景下的扩展能力 |
6.4 选型决策
场景 | 推荐 |
标准企业内网、稳定 Microsoft Entra ID 联通 | Microsoft Entra ID（默认）——简单、运维成本低 |
政府 / 军工 / 严格合规 / 弱连接 | Local Identity with Key Vault（2604+ GA） |
6.5 不要过度承诺
"Local identity with Azure Key Vault"是 GA 能力，不是万能解药。客户仍需自管 Key Vault 的访问策略、网络联通、轮换策略。微软未声明"启用 Local Identity 后所有 Azure 管理功能均可用"——具体服务依赖请查 Generally available or supported services。
七、支柱 4：自助编排——从 vendor-controlled 到 customer-orchestrated
7.1 跃迁前（2602 时代）
- Azure Local 更新节奏由微软默认编排
- 客户不能自定义 maintenance window / cadence / orchestration behavior
- 节点加入集群必须集群已就绪后逐台手动配置
7.2 跃迁后（2604+）
2604 开放了两类客户编排能力：
术语澄清：Domain Join 预部署不是完全独立的新 Feature，而是 Simplified Machine Provisioning 的组成能力之一（2603 起引入该 Provisioning 流程，2604 起支持 Domain Join 在 OS 安装阶段完成）。
7.3 跃迁带来 4 项 GA 能力
能力 | 性质 | 跃迁意义 |
Update orchestration configuration | 2604 | 客户可自定义更新时段、节奏、编排行为 |
Domain Join 预部署 | 2604 | 机器在 OS 安装阶段就加入 AD，而非集群就绪后手动 |
Validation 3 小时续检窗口 | 2604 | 失败后 3 小时内从失败点续检，而非重头跑 |
Deployment 时长缩短至 40%（≤8 节点） | 2604 | 微软官方测试环境（≤8 节点集群）的结果 |
"Deployment 40%" 的实际意义：这是微软官方测试环境下、≤8 节点集群的测量结果。客户实际部署的 40% 收益取决于集群规模、网络延迟、驱动 / 固件校验、OEM SBE 验证时长——不应理解为所有环境都能达到 40%。
7.4 术语澄清
Update orchestration configuration不是Windows Update Settings，也不是 Azure Update Manager 的别名。它是 Azure Local 解决方案自身的更新编排配置（maintenance window / cadence / orchestration behavior）。
7.5 跃迁带来的运维模式变化
跃迁前：Azure Local 是半受控的 appliance——客户能采购、上电、连云，但不能深度自定义运维流程。
跃迁后：Azure Local 是可编排的 platform——客户可定义自己的部署流水线、更新窗口与更新编排策略。
八、4 个跃迁支柱的合力：Azure Local 的产品形态演变
8.1 一句话总结
Azure Local 并非放弃 HCI，而是在保留 HCI 部署模式的基础上，引入 SAN、GPU、Local Identity 和可编排运维等能力，将产品形态从"单一超融合平台"扩展为"面向混合云的基础设施平台"。
这与微软"兼容而非替代"的产品演进思路一致——2604 不是把 HCI 推倒重来，而是在 HCI 之上叠加新能力。
8.2 三阶段定位差异
维度 | HCI Appliance（2602） | 基础设施平台（2606） |
存储 | 只能 S2D HCI | S2D / FC SAN / Disaggregated 任选 |
计算 | x86 + DDA GPU（少数） | x86 + DDA + GPU-P + Blackwell（多种） |
身份 | 必须 Microsoft Entra ID | Microsoft Entra ID / Local Identity + KV 任选 |
更新 | 微软默认编排 | 客户可自定义 orchestration |
部署 | 手动加入集群 | Domain Join 预部署 + Simplified Provisioning |
故障域 | 节点级 | 节点级 + 存储独立 + 解耦形态 |
客户角色 | 运维者 | 平台设计者（受 Azure Local 支持矩阵约束） |
8.3 "哪些东西没变"——澄清 2604 不是推倒重来
2604 引入的能力很多，但产品的核心架构没有变：
组件 / 概念 | 是否变化 | 说明 |
ARM Resource 模型 | 没变 | Azure Local 仍是 Azure 资源，由 Azure Resource Manager 管理 |
Arc Resource Bridge | 没变 | 仍是 Azure 与本地集群的桥梁组件 |
Hyper-V | 没变 | 仍是 Azure Local 的虚拟化底座 |
Azure Arc 管理模型 | 没变 | 仍是基于 Arc 的云端管理平面 |
ARM API 接口 | 没变 | API 表面兼容升级路径不变 |
Azure Local VM 模型 | 增强（2604 加入 GPU） | 底座没变 |
架构师笔记：变化的是能力（capability），不是整个架构（architecture）。读者不应误读为"2604 把 Azure Local 推倒重来"。
九、跃迁的客户价值（按场景）
客户类型 | 跃迁前痛点 | 跃迁后获得 |
AI 推理客户 | GPU 整卡成本高、利用率低 | GPU-P + 监控 + Blackwell（2603~2605） |
政府 / 军工客户 | Microsoft Entra ID 依赖、气隙部署困难 | Local Identity + KV（2604 GA） |
多站点零售 / 分支机构客户 | 集中存储扩展难 | Disaggregated 部署（2604 GA） |
大型企业运维 | 更新窗口固定、不能自定义 | Update orchestration（2604 GA） |
数据中心整合 | 迁移 SAN 目标复杂 | Azure Migrate SAN 目标（2605） |
AKS Arc 客户 | WS2019 node pool EOL | 升至 2604+（KMS v2 / 新 node pool OS） |
十、本篇核心 takeaway
- 2604 是 Azure Local 产品线的"架构转折点"——不是普通月度 release，而是引入 SAN / GPU-P / Local Identity / Update orchestration 等一批 GA 能力的里程碑 release
- 这批 GA 能力可以归纳为 4 个跃迁支柱：存储解耦 / 异构计算 / 自带身份 / 自助编排——它们共同支撑"基础设施平台"的产品形态
- Azure Local 并非放弃 HCI——而是在 HCI 之上叠加新能力，符合微软"兼容而非替代"的产品演进思路
- 2604 的 4 个支柱是 5 个客户场景共同推动的结果——AI / SAN / 边缘 / 弱连接 / 基础设施市场覆盖
- "Cloud Infrastructure Platform" 是作者总结，非微软官方定位——首次出现时已声明，避免读者误以为是官方表述
- GPU-P 基于 Windows Hyper-V GPU Partitioning + NVIDIA 驱动协同——不是 NVIDIA vGPU Manager 实现，这是关键技术事实
- 客户拥有更多架构组合选择，但仍受 Azure Local 支持矩阵约束——SAN / GPU / OEM / SKU 均需符合认证
- 2604 不是把 Azure Local 推倒重来——ARM / Arc Bridge / Hyper-V / Arc 管理模型 / ARM API 都没变，变化的是能力
- Deployment 40% 是微软官方实验环境（≤8 节点）的部署时间缩短结果，不代表所有 OEM 环境
- 四个跃迁支柱并不是四项独立 Feature，而是 Azure Local 从单一 HCI 产品向可组合基础设施平台演进过程中形成的能力集合——这才是全文真正的核心论点
附录 A · GA / Preview 能力状态汇总（2604 ~ 2606）
读者快速参考——区分 GA / Preview / 已 GA 但需支持矩阵
能力 | 状态 | 备注 |
FC SAN 外部存储 | GA | 2604 起；与 S2D 并存 |
Disaggregated（解耦）部署 | GA | 2604 起 |
GPU-P（GPU Partitioning） | GA | 2604 起；支持矩阵需查 OEM |
DDA（Discrete Device Assignment） | GA | 较早期即 GA |
Local identity with Key Vault | GA | 2604 起 |
Rack-aware + Local Identity 组合 | GA | 2604 起 |
NVIDIA RTX PRO 6000 Blackwell | GA | 2603 起支持 |
GPU-P Azure Monitor 指标 | GA | 2605 起 |
iSCSI SAN 外部存储 | 预览（Preview） | 2605 起；生产请等 GA |
Azure Migrate CLI 复制 / 迁移 | 预览（Preview） | 2604 起；生产请等 GA |
Update orchestration configuration | GA | 2604 起 |
Domain Join 预部署 | GA | 2604 起；Simplified Provisioning 组成能力 |
Validation 3 小时续检 | GA | 2604 起 |
Drift Detection | GA | 2602 起 |
Secure Boot 2023 证书编排 | GA | 2603 起 |
22H2 ESU / Subscription 销售 | 已终止 | 2602 起 |
架构师笔记：FC SAN / GPU-P / Disaggregated 都是 GA 能力，但部署前仍需核对 Azure Local 支持矩阵——OEM SKU / SAN 厂商 / GPU 型号 / vGPU License 模式均需符合认证。
附录 B · 4 个跃迁支柱与 GA 能力对照表
跃迁支柱 | 关键问题 | 跃迁前 | 跃迁后（2604+） | 2604 GA 能力 |
支柱 1 · 存储解耦 | 存储与计算能否独立扩展？ | 仅 S2D HCI | S2D / FC SAN / Disaggregated | SAN FC GA / Disaggregated GA / Rack-aware + Local Identity / Azure Migrate SAN 目标 |
支柱 2 · 异构计算 | GPU 是一等公民吗？ | 仅 DDA（少数外设） | DDA + GPU-P + Blackwell | GPU-P GA / RTX PRO 6000 / GPU-P 监控 / Day-2 热操作 |
支柱 3 · 自带身份 | 能否脱 Microsoft Entra ID 部署？ | 必须 Microsoft Entra ID | Microsoft Entra ID / Local Identity + KV | Local Identity with KV GA / Rack-aware + Local Identity |
支柱 4 · 自助编排 | 客户能否自定义更新 / 部署？ | 微软默认编排 | 客户可自定义 | Update orchestration / Domain Join 预部署 / Validation 3h 续检 / Deployment 40% 提速 |
附录 B·附：能力来源分层图（Hyper-V / Azure Local 责任划分）
很多读者会问：GPU-P、DDA 这些技术是 2604 发明的吗？
不是。这些技术是 Windows Hyper-V 已经具备的，2604 是Azure Local 开始正式支持。
架构师笔记：2604 的"架构跃迁"并不是发明新技术——而是在 Azure Local 平台上正式支持已有技术 +新增基础设施编排能力。这是公开文章里容易被读者误读的一点。
附录 C · 关键技术能力引入时间线
下一篇（下篇）预告：升级路径与实战清单——从 2602 / 23H2 升到 2606 的步骤、已知问题的修复史、OEM Solution Builder Extension 的影响、备份与回滚策略、推荐升级窗口。
文档维护：本文以微软 Learn 当前版本（azloc-2606）为准。请以官方页面为最终事实。
