未经同意请勿转载适用版本Azure Local 12.2602.1002.5012602 → 12.2606.1003.2052606文档来源Whats 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;DR2604 不是普通的月度 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 HCIHCI / FC SAN / Disaggregated 三选GPU 模式仅 DDADDA Blackwell 引入DDA GPU-PGA Blackwell身份模式Microsoft Entra ID 必须Microsoft Entra ID 必须Microsoft Entra ID / Local Identity KV 二选更新编排微软默认微软默认客户可自定义部署自动化手动加入集群Simplified ProvisioningDomain Join 预部署 全自动产品定位HCI Appliance超融合一体机HCI Appliance 增强基础设施平台详见作者声明一·附为什么 2606 没有新的平台能力很多读者会问2606 是不是没东西事实上 2606 是稳定性版本Quality Release微软 release cadence 通常遵循Feature Release → Quality Release → Feature Release → ...2604Feature Release——一次性 GA 一批能力2606Quality Release——质量修复、稳定性提升、安全补丁为主2606 体现的是平台成熟而不是产品形态再次变化。这也是为什么 2606 看起来没有新 Feature——它本来就不是 Feature Release。二、为什么 2604 集中推出这些能力理解 2604 的产品定位先回答一个问题为什么微软会在 2604 集中推出这批 GA 能力可以归纳为 5 个相互交织的原因2.1 原因 1Azure Stack HCI 时代定位过窄Azure Stack HCI 的产品定位是HCI Appliance——超融合一体机所有能力都围绕本地 集中假设设计。随着客户场景多样化边缘、混合云、AI单一 HCI 形态已经无法覆盖。2.2 原因 2AI 工作负载推动 GPU 能力GPU 从少数客户的可选外设变成主流 AI 推理 / 微调 / RAG 的必需资源。Azure Local 必须把 GPU 从少数高端客户的可选提升到Azure Local 官方支持的基础资源类型之一。2.3 原因 3SAN 客户无法迁移大量企业数据中心有现成的 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 → OrchestrationLocal Identity 是 Domain Join 预部署OS 阶段加入域的信任前提Orchestration → 其他三支柱Update orchestration configuration 让三大支柱的能力可被客户自定义节奏部署四、支柱 1存储解耦——从耦合到独立扩展4.1 跃迁前2602 时代Azure Local 2602 的存储模型只有一种耦合每节点的 CPU 与本地盘必须共生死——加存储必须加节点加计算也必须带盘扩展上限HCI 集群 1~16 节点运维负担故障盘 → 整机风险扩存储 → 加整机 → 重新平衡 S2D 池4.2 跃迁后26042604 GA 的 FC SAN Disaggregated 部署打破了这个绑定解耦存储资源池与计算节点独立采购、独立扩展、独立故障域扩展选项HCI1~16/ Disaggregated独立上限以 Disaggregated 文档 为准新运维模型存储故障不再绑架计算计算扩容不再绑架存储4.3 跃迁带来 4 项 GA 能力能力性质跃迁意义SAN 存储FCGA与 S2D 并存引入外部存储路线Disaggregated 部署 GA集群只走 SAN解耦形态正式 GARack-aware Local Identity 组合2604 才完整支持多机架场景下的解耦部署Azure Migrate 支持 SAN 目标含 NTFS 卷2605数据中心迁移可走 SAN4.4 选型决策树你需要的存储容量/性能 是否经常超过本地盘的扩展能力 ├─ 否 → 保持 HCI2602 也够用 └─ 是 → 进一步评估 ├─ 已有 FC SAN 投资 → Disaggregated2604 ├─ 没 FC 交换机 → iSCSI 预览2605仅评估 └─ 完全新建 → 视总拥有成本决定 HCI vs Disaggregated4.5 重要约束SAN 与 S2D 是并存关系不是替代关系——文档明示 SAN 与 S2D alongsideDisaggregated ≠ 无限扩容——核心价值是扩展部署拓扑选择不是绕过任何硬性的集群规模上限SAN 设备仍需符合 Azure Local 支持矩阵——具体哪些 SAN 厂商 / 型号可用参考 Azure Local Catalog 与 External Storage 文档iSCSI 是 preview2605——生产请等 GAAzure Local 并不会把 FC SAN 纳入 Storage Spaces 管理——SAN 存储仍由外部阵列自身负责数据服务快照 / 复制 / 容灾与生命周期管理。Azure Local 只是消费 LUN把 SAN 当作 VM 数据卷的物理载体使用。读者不应误以为Azure Local 接 SAN Storage Spaces 接 SAN两者是完全不同的管理模型。五、支柱 2异构计算——从 x86 到 GPU 基础资源5.1 跃迁前2602 时代DDADiscrete Device Assignment整卡通过 PCIe passthrough 独占分配给单 VM较早期即 GAGPU-PGPU PartitioningAzure Local不支持直到 2604 GA澄清一个常见误解GPU-P技术本身在 Windows Server / Hyper-V 上一直存在Azure Local从 2604 起才正式支持这种能力。5.2 跃迁后26042604 把 GPU-P 升级为正式支持能力GA与 DDA 并存模式隔离机制调度方式适用DDAPCIe 硬件级独占无调度高端 AI 训练 / 推理、对隔离有严格要求的负载GPU-P单卡切多 partitionWindows 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 正式支持GA2604partition 模式正式可用NVIDIA RTX PRO 6000 Blackwell2603新一代数据中心 GPU 支持GPU-P Azure Monitor 指标2605partition 级监控容量规划、热点识别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 的 GPUGPU-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-optional6.1 跃迁前2602 时代Azure Local 部署必须接入 Microsoft Entra ID 才能完成注册——这对气隙air-gapped/ 弱连接客户是硬约束。6.2 跃迁后26042604 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 GA2604自带身份正式可用Rack-aware Local Identity 组合2604多机架 自带身份的部署组合Rack-aware clustering 增强2604多机架场景下的扩展能力6.4 选型决策场景推荐标准企业内网、稳定 Microsoft Entra ID 联通Microsoft Entra ID默认——简单、运维成本低政府 / 军工 / 严格合规 / 弱连接Local Identity with Key Vault2604 GA6.5 不要过度承诺Local identity with Azure Key Vault是 GA 能力不是万能解药。客户仍需自管 Key Vault 的访问策略、网络联通、轮换策略。微软未声明启用 Local Identity 后所有 Azure 管理功能均可用——具体服务依赖请查 Generally available or supported services。七、支柱 4自助编排——从 vendor-controlled 到 customer-orchestrated7.1 跃迁前2602 时代Azure Local 更新节奏由微软默认编排客户不能自定义 maintenance window / cadence / orchestration behavior节点加入集群必须集群已就绪后逐台手动配置7.2 跃迁后26042604 开放了两类客户编排能力术语澄清Domain Join 预部署不是完全独立的新 Feature而是 Simplified Machine Provisioning 的组成能力之一2603 起引入该 Provisioning 流程2604 起支持 Domain Join 在 OS 安装阶段完成。7.3 跃迁带来 4 项 GA 能力能力性质跃迁意义Update orchestration configuration2604客户可自定义更新时段、节奏、编排行为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 Appliance2602基础设施平台2606存储只能 S2D HCIS2D / FC SAN / Disaggregated 任选计算x86 DDA GPU少数x86 DDA GPU-P Blackwell多种身份必须 Microsoft Entra IDMicrosoft 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 监控 Blackwell2603~2605政府 / 军工客户Microsoft Entra ID 依赖、气隙部署困难Local Identity KV2604 GA多站点零售 / 分支机构客户集中存储扩展难Disaggregated 部署2604 GA大型企业运维更新窗口固定、不能自定义Update orchestration2604 GA数据中心整合迁移 SAN 目标复杂Azure Migrate SAN 目标2605AKS Arc 客户WS2019 node pool EOL升至 2604KMS v2 / 新 node pool OS十、本篇核心 takeaway2604 是 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 外部存储GA2604 起与 S2D 并存Disaggregated解耦部署GA2604 起GPU-PGPU PartitioningGA2604 起支持矩阵需查 OEMDDADiscrete Device AssignmentGA较早期即 GALocal identity with Key VaultGA2604 起Rack-aware Local Identity 组合GA2604 起NVIDIA RTX PRO 6000 BlackwellGA2603 起支持GPU-P Azure Monitor 指标GA2605 起iSCSI SAN 外部存储预览Preview2605 起生产请等 GAAzure Migrate CLI 复制 / 迁移预览Preview2604 起生产请等 GAUpdate orchestration configurationGA2604 起Domain Join 预部署GA2604 起Simplified Provisioning 组成能力Validation 3 小时续检GA2604 起Drift DetectionGA2602 起Secure Boot 2023 证书编排GA2603 起22H2 ESU / Subscription 销售已终止2602 起架构师笔记FC SAN / GPU-P / Disaggregated 都是 GA 能力但部署前仍需核对 Azure Local 支持矩阵——OEM SKU / SAN 厂商 / GPU 型号 / vGPU License 模式均需符合认证。附录 B · 4 个跃迁支柱与 GA 能力对照表跃迁支柱关键问题跃迁前跃迁后26042604 GA 能力支柱 1 · 存储解耦存储与计算能否独立扩展仅 S2D HCIS2D / FC SAN / DisaggregatedSAN FC GA / Disaggregated GA / Rack-aware Local Identity / Azure Migrate SAN 目标支柱 2 · 异构计算GPU 是一等公民吗仅 DDA少数外设DDA GPU-P BlackwellGPU-P GA / RTX PRO 6000 / GPU-P 监控 / Day-2 热操作支柱 3 · 自带身份能否脱 Microsoft Entra ID 部署必须 Microsoft Entra IDMicrosoft Entra ID / Local Identity KVLocal 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为准。请以官方页面为最终事实。