Azure Local 2602→2606 演进全景：2604 为什么是架构转折点（2602→2606 演进与升级价值·中篇）

未经同意，请勿转载！

适用版本：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 Disaggregated

4.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）为准。请以官方页面为最终事实。