1. 概念边界概念微软官方说法易混淆点术语Rack aware clusterazloc-2606 官方原文不是 multi-rack deployment也没有 stretched cluster 说法与 HCI 22H2 stretched cluster 的关系Stretched clusters are not supported in Azure Localazloc-2504 已归档文档原文Azure Local 抛弃了 HCI 22H2 时代的跨数据中心 SR 方案物理范围2 个机柜同一建筑两个房间或相邻建筑不是跨数据中心跨城市跨房间延迟硬要求≤ 1 ms 往返RTTazloc-2606 官方原文这是 S2D 同步复制的最低门槛违反即不被官方支持与 External SAN 关系Rack aware clustering doesnt support configurations with External Storage Area Networksazloc-2606 官方原文FC SAN 路径与 rack aware 互斥二选一节点规模22 → 33 → 44 扩展azloc-2606 官方原文不允许 23、24 等非对称配置单实例最大节点1 to 64 machinesazloc-2606 system-requirements-23h2 官方原文rack aware 是其子集2. 与传统理解的差异多机架在 Azure Local 中不是新形态。它沿用单实例 S2D cluster 的所有底线约束直连盘、无 RAID 卡、同型同构、64 节点上限只是把节点人为划分到两个本地可用区local availability zone。它的业务价值不是容量叠加而是rack-level fault domain——一个机柜整柜掉电/掉线/维护时另一个机柜维持数据可用性。这点与传统 N1 容错的区别在于故障域跨物理机柜而非仅跨单台服务器。它不是 DR 方案。RTT 1 ms 的约束决定了它不能跨数据中心。要做 DR需要另接 ASR 或 Storage Replica 跨长距离实例且这已经不再是多机架语义。2.1 为什么 Azure Local 引入 Rack Awarefault domain 演进Azure Local 并没有重新设计 Storage Spaces Direct。它在原有 fault domain 体系上新增了一层 RackRegion └── Availability Zone └── Rack ← 新增 └── Node └── Disk对比之前的 fault domain 体系层级HCI 22H2 / Windows Server S2DAzure Local Rack AwareRegion—Azure Local 是单 Region 实例无此层Availability Zone—支持跨 Rack 聚合的逻辑层Rack不支持支持azloc-2606 新增Node支持支持Disk支持支持备注Windows Server 2025 S2D是支持RAC上面Windows Server S2D不包括Windows Server 2025Windows Server 2025数据中心版RAC参考本博客其它文章。Rack 这一层在 Azure Local 中通过以下路径体现Cluster Fault DomainCluster Service 在编排 quorum、failover、Repair Workflow 时会结合 Rack Fault Domain 进行修复策略计算避免修复过程中进一步降低 Fault Domain 冗余Storage Fault DomainStorage Spaces Direct 在创建 Fault Domain 时支持 Rack 作为独立粒度从而让 RLNM 等机制按 Rack 分布副本VM PlacementVM Placement 会结合 Rack Fault Domain尽量保持工作负载分布在不同 Rack 中提高 Rack 级故障后的可用性WitnessAzure Local Rack Aware 部署流程默认采用 Cloud Witness双节点场景则必须配置 WitnessCSV Redirect、Repair 等集群行为最终受 Cluster Fault Domain 影响从而体现 Rack Aware 的拓扑感知这就是 rack aware 的本质——不是简单节点跨两个机柜部署而是从 cluster 服务到存储栈全栈感知 Rack fault domain。这也是它和手工把 4 台机器分成两组的根本区别。3. 四个设计模式Topology A/B/C/Dazloc-2606 reference-architecture 给出四种机房内 TOR 互联方式。这是设计选项不是替代演进。共同点都是两个房间各房间有自己的 TOR跨房间走 RDMA storage。3.1 共同前提2 个机柜room A / room B各房间有 12 台 TOR2 根 spine横跨两房间承载 management compute intentStorage intent 走 TOR 层不上 spine每个节点至少4 端口2 个 management/computeSET teamed、2 个 storageVLAN 711 / 712 各一同一机柜内 MLAGMulti-Chassis Link Aggregation用于 management/computeMTU 9216 仅 iWARP 必需RoCEv2 不需要 jumbo frameDCBPFC ETS LLDP TLV MSTP 全部必需3.2 拓扑对比维度A: 独立 storage 链路B: 聚合 storage 链路C: 单 TOR/房间D: 跨房间直连房间内 TOR 数2211Storage 跨房间2 条独立绑定链路VLAN 711: TOR1↔TOR3VLAN 712: TOR2↔TOR4vPC 端口通道TOR1/TOR2 ↔ TOR3/TOR4跨房间 port-channel 700/701单房间单 TOR 绑定链路节点直连两房间 TOR不需要房间间 RDMA 链路RDMA 跳数最少直接跨房间可能因 hash 多一跳直接不走房间间 RDMA 链路TOR 内冗余有有无single point of failure per zone单 TOR 但跨房间互联适用场景工厂、机房空间充裕想要链路聚合 跨房间冗余极简小型边缘节点机柜与 TOR 不在同一房间关键风险链路数量多vPC 配置复杂度高hash 不均时延迟飘移维护时整区停机额外光纤 跨房间布线运维成本最高3.3 各拓扑特有的陷阱拓扑 A 风险每一条跨房间物理链路本身都是单点组件因此建议采用双物理路径布线不同桥架 / 竖井Storage Intent 依靠 SMB Multichannel 提供链路级冗余单一物理链路中断不会立即导致数据不可用。MLAG 千万不能承载 storage 流量azloc-2606 原文Storage traffic bypasses MLAG to minimize RDMA session hops——很多工程师会下意识想MLAG 更稳但对 RDMA 反而是负优化。拓扑 B 风险跨房间 port-channelvPC ID 700/701依赖两端 hash 一致。如果 TOR firmware 升级导致 hash 算法变更整个 SMB session 重连。需要固化 firmware 版本。TOR1↔TOR4↔TOR3 这种绕路 hash是真实存在的azloc-2606 原文明示。在极端路径选择情况下数据流可能经过额外交换机转发因此建议实际测量所有路径 RTT而不仅验证最优路径。拓扑 C 风险单房间单 TOR 维护时整区停机。azloc-2606 原文明确指出creates a single point of failure per zone during maintenance or device failure。生产环境慎用。不要被简化骗到——22 节点整柜维护时 cluster 还剩 2 节点quorum edge任何重启都可能导致 quorum 丢失。拓扑 D 风险每根光纤跨房间布线量翻倍。机柜搬迁或房间改造时成本极高。Cross-room cabling for every node interface 是 azloc-2606 原文要求提前与机房承建方对清楚。3.4 拓扑 D 的核心价值azloc-2606 reference-architecture 原文明示拓扑 D 看上去绕——每个节点都拉一根跨房间光纤到对面 TOR——但它的核心价值不在减少交换机而在解决一类节点机柜无法与本房间 TOR 共址的场景TOR 集中部署所有 TOR 集中在一个网络汇聚机柜节点分散在多个房间网络汇聚机柜TOR 物理位置与计算节点不在同一区域HPC 房间节点本身就在被测试的 HPC 房间TOR 在数据中心主区Edge Room / 边缘机房每个边缘房间只放节点TOR 集中托管在这些场景下拓扑 A/B/C 都不可行A/B/C 都要求每个房间有自己的 TOR 与节点共址。拓扑 D 是为节点与 TOR 必须分离的物理现实而设计的拓扑不是为了省交换机。3.5 Rack Aware Fault Domain 架构图下面是 rack aware cluster 在 cluster service 视角下的 fault domain 表达物理部署 ══════════════════════════════════════════════════════════════ Room A Room B ┌─────────────────────────┐ ┌─────────────────────────┐ │ TOR-A1, TOR-A2 │ │ TOR-B1, TOR-B2 │ │ ├── Node1 (mgmtcomp) │ │ ├── Node3 (mgmtcomp) │ │ ├── Node2 (mgmtcomp) │ │ ├── Node4 (mgmtcomp) │ │ └── storage: NIC↔NIC │ ←──→ │ └── storage: NIC↔NIC │ └─────────────────────────┘ └─────────────────────────┘ Cluster Fault Domain 视角azloc-2606 reference-architecture 原文 ══════════════════════════════════════════════════════════════ Cluster ├── RackA (Availability Zone 1) │ ├── Node1 │ │ ├── Disk1 │ │ ├── Disk2 │ │ └── ... │ └── Node2 │ ├── Disk1 │ └── ... └── RackB (Availability Zone 2) ├── Node3 │ ├── Disk1 │ └── ... └── Node4 └── ...这个视图后续在部署篇volume 的 RLNM 验证、运维篇repair-server 流程、排错篇CSV 重定向分析都会被反复引用。4. 容量与扩展规则azloc-2606 官方原文只能成对加节点22 → 33 → 44。不允许非对称比如 23、34、45 都违反官方拓扑约束。文档原文The 22 configuration can be expanded to 33, and 33 to 44.最大 44 8 节点azloc-2606 官方原文up to 44 nodes。单实例总节点上限 64 来自 system-requirements-23h2 文档与 rack aware 是不同层级的概念。容易踩的坑以为 55、66 也行。azloc-2606 reference-architecture 明确写的是 up to 44 nodes55、66 都不在官方拓扑支持范围。4.1 关于 44 上限的层级说明重要澄清很多读者会把最大 44误读成Azure Local 集群最大只能 8 节点。这是两个不同层级的概念层级上限来源Azure Local 单实例1 ~ 64 节点azloc-2606 system-requirements-23h2 原文1 to 64 machines are supportedRack Aware Reference Architecture22 → 33 → 44最大 8 节点azloc-2606 rack-aware-cluster-reference-architecture 原文up to 44 nodes含义44 是 Rack Aware Reference Architecture 当前公开的参考拓扑上限并不意味着Azure Local Cluster 最大只能 8 个节点。55、66 等更大对称拓扑目前不在官方参考架构文档内。azloc-2606 没有明示未来是否会扩展但读者不应自行推断Rack Aware 8 节点上限。同样53、46 等非对称配置azloc-2606 rack-aware-cluster-overview 明确写symmetrical目前不在参考架构里。规划阶段建议如果要超过 44 容量评估是否需要拆分多个 Azure Local 实例而非强行扩展 rack aware 拓扑。5. 网络意图Network Intent规划azloc-2606 host-network-requirements 明确网络流量分三类management / compute / storage。在 rack aware 场景下Management intentVLAN 7 示例vPC/MLAG 跨两房间 spine 延伸必须是 L2 域否则 cluster heartbeat / VM live migration 会断Compute intentVLAN 8 示例同上跨 spine L2 延伸Storage intentVLAN 711/712只走 TOR不经过 spineL2 broadcast 域不配 IP5.1 VLAN 选号推荐角色建议 VLAN备注Management7azloc-2606 文档示例Compute8azloc-2606 文档示例SMB1Storage intent 1711文档示例azloc-2606 原文 SMB1 VLAN 711SMB2Storage intent 2712文档示例azloc-2606 原文 SMB2 VLAN 712Nativeblackhole99防止 untagged 流量泄漏预留 SDN PA / VIP视规模不要与上述重叠5.2 IP 与 RDMA 的关系azloc-2606 官方原文 协议层原理这是全文最容易引起误解的一节必须先理清协议栈5.2.1 协议栈现实先纠正一个常见误解协议传输层RDMA over IPSMB DirectTCP445是TCP/IP 之上的 SMB over RDMARoCE v2UDP/IP是UDP 4791iWARPTCP是TCP/IP 之上的 MPA/DDP/RDMAP所以RDMA 不需要 IP是个错误说法。RDMA 三种主流实现iWARP / RoCE v2 / RoCE全部基于 IP。真正的官方说法是RDMA 流量不跨越 spine、不需要跨三层路由。5.2.2 微软官方表述azloc-2606 原文azloc-2606 host-network-requirements 与 reference-architecture 真正表达的是Storage Intent 网络由 Network ATC 自动配置不建议人为规划三层路由Storage 网络保持同一二层广播域同一 VLAN 内 L2 可达RDMA 流量不会跨 Spineazloc-2606 原文RDMA traffic doesnt traverse to the spine switch layer部署后的事实# 在已经部署好的 Azure Local 节点上跑 Get-NetIPAddress -InterfaceAlias Storage* # 仍然能看到 storage NIC 上有 IP 地址 # 但这些 IP 是 Network ATC 自动生成的不是人工规划的正确的口径✅无需人工规划 Storage VLAN 地址由 Azure Local / Network ATC 自动完成❌Storage VLAN 是纯 L2 broadcast不配置 IP这是错的会让人误以为 RDMA 不用 IP❌RDMA 不上 spine这是对的但与配不配 IP是两回事5.2.3 为什么 Azure Local 不建议跨三层部署 RDMA虽然 RoCEv2 在协议上可以跨三层网络UDP 路由可达即可但 Azure Local Rack Aware Cluster 官方参考架构要求Storage RDMA 保持在同一二层网络同一 VLAN 内 L2 可达不经过 Spine不建议跨 L3 部署原因azloc-2606 reference-architecture 未明示全部细节但工程上共识S2D SMB Multichannel 设计依赖 L2 多路径NIC teaming 多 VLAN跨 L3 会破坏 Multichannel 的路径选择DCB/PFC 在 L3 路径上难保证端到端跨 L3 后各跳的 PFC 配置一致性难校验延迟不可控每多一跳路由 0.1~0.3 msOEO/路由处理跨 L3 路径上 1 ms RTT 阈值容易被突破官方参考架构未验证跨 L3 拓扑azloc-2606 reference-architecture 给的 4 种拓扑全部是同 L2 域5.2.4 总结Storage 网络三层关系层状态L2 broadcast domain必须同 L2 域azloc-2606 原文要求L3 IP 地址存在ATC 自动配置无需人工规划L3 路由不存在不跨子网、不跨 VLAN、不跨 L3 设备跨 Spine 转发不允许azloc-2606 原文RDMA traffic doesnt traverse to the spine switch layer6. 带宽与延迟基线azloc-2606 官方原文指标硬要求来源跨房间 RTT≤ 1 msrack-aware-cluster-overview 原文Storage 端口最小速率10 GbEreference-architecture 原文Storage 端口推荐速率25 GbEreference-architecture 原文DCB / PFC / ETS必选reference-architecture 原文MTUiWARP9216reference-architecture 原文MTURoCEv2默认即可reference-architecture 原文RDMA 协议一致性iWARP ↔ iWARPRoCE ↔ RoCE不可混host-network-requirements 原文跨实例最低带宽10 Mbithyperconverged 系统需求system-requirements-23h2 原文关键澄清1 ms是 RTT往返不是单向。1 ms RTT 折算单向 0.5 ms。跨房间如果是直接光纤100 米内完全可达成 1 ms RTT。如果是经过光电转换 / 再生器每加一跳增加 0.10.3 ms要在 BOM 阶段算清楚。不要相信10 GbE 也行。10 GbE 跑 S2D 同步复制在 44 配置下会直接打满接口。azloc-2606 写minimum 10-GbE25 GbE recommended for optimal performance——这是下限不是推荐。6.1 跨房间光纤路径设计OEM 工程共识非 azloc-2606 强制微软官方未明示跨房间光纤的具体布线要求但几乎所有主流 OEMDell、Lenovo、HPE、Cisco 等在 Rack Aware 部署建议中都提出跨房间光纤采用双路径Diverse Path设计避免单条光纤或单根桥架故障导致整个 Rack 间存储通信中断虽然 azloc-2606 未将其列为强制要求但这是多数 OEM 与数据中心布线规范的推荐实践。规划阶段建议每个跨房间 storage 链路至少有两条物理路径不同桥架、不同竖井跨房间的 OEO / 再生器 / DWDM 设备也走双路径与机房承建方在施工前明确书面确认 Diverse Path 设计6.2 交换机缓冲Buffer要求RoCEv2 场景工程共识微软 azloc-2606 physical-network-requirements 文档对 TOR 的核心要求是支持 PFC ETS LLDP。但对共享缓冲区Shared Buffer容量未做硬性规定。然而对于采用RoCEv2的场景RoCE 对交换机 buffer 高度依赖——这是 NVIDIA / Cisco / Arista / Dell 网络设计指南都会强调的内容Head-of-Line BlockingPFC pause 帧触发后如果下游 buffer 不够HOL blocking 会沿链路向上游扩散ECN 调优依赖足够 buffer 来承载拥塞标记前的突发流量突发流量场景S2D rebuild、VM 冷启动批量读盘时单端口瞬时吞吐可超出稳态数倍规划建议选 TOR 时确认其shared buffer 容量一般数据中心级 TOR 应 ≥ 16 MBRoCE 优化型号 ≥ 32 MB查阅 TOR 厂商针对 RoCE 网络的 buffer 调优白皮书微软官方未规定 Buffer 容量因此采购时应参考交换机厂商针对 RoCE 网络发布的最佳实践azloc-2606 未给权威数字iWARP 场景对 buffer 的要求远低于RoCEv2iWARP 在 TCP 层做流控硬件 buffer 不是瓶颈。这也是 iWARP vs RoCE 选型的另一个考量点。7. 节点与硬件选型azloc-2606 system-requirements-23h2 原文7.1 同型同构硬要求每台机器同型号、同厂商、同 CPU、同网卡、同盘数同盘型且制造时间接近azloc-2606 system-requirements-23h2 原文Manufactured within approximately the same timeframe这条对 rack aware 而言是致命的——22 起步就要 4 台同配机器22 → 33 扩容时新增的 2 台必须与现网 4 台完全同型。如果原 OEM 停产该型号扩展就会卡死。实际经验选型时一次性规划 44 容量分阶段采购。宁可前两年 22 跑不满也别等要扩时发现机器买不到。7.2 存储盘azloc-2606 system-requirements-23h2 原文维度要求类型SATA / SAS / NVMeM.2、U.2、add-in card格式512n / 512e / 4K native多节点推荐全闪单一类型NVMe 或 SSD性能一致Hybrid 限制仅 HDD Flash 混合才允许cache ≥ 32 GB、cache:capacity ≥ 15%、cache endurance ≥ 3 DWPD 或 ≥ 4 TBW/day、capacity 盘数必须为 cache 盘数的整数倍闪存要求必有 power-loss protectionHBA必须支持 simple pass-through 模式NVMe 驱动stornvme.sysMicrosoft inbox不支持 Windows Server 新版 StorNVMe直连必须直连到单台机器S2D 要求不允许共享 SAS enclosureRAID 卡不允许跨机器 MPIO不允许7.3 NIC 与 RDMA 选型必须在 Windows Server Catalog 找到带 Management Compute Storage 三种 qualification 的 NICiWARP vs RoCE 选型azloc-2606 host-network-requirements 给出明确决策树iWARP 适合没 DCB 经验、不会配 ToR、运维外包RoCE 适合已有 RoCE 经验、运维成熟、要更高吞吐InfiniBand 不支持azloc-2606 原文Guest RDMA 在 Azure Local 上不支持azloc-2606 原文——Azure Local 当前不支持 Hyper-V Guest RDMAvRDMA不要与 Windows Server 独立 Hyper-V 场景混淆7.4 Switch 选型azloc-2606 physical-network-requirements 列出了大量经过验证的 TOR 厂商型号Arista、Cisco Nexus 9300 系列、HPE Aruba CX、Dell S52xx/S54xx、Allied Telesis x560/x980、Alcatel-Lucent OmniSwitch 6900/6920 等。关键约束必须支持 DCBPFC ETS必须支持 MSTP用于 storage / non-storage VLAN 分离必须支持 LLDP DCB TLVazloc-2606 原文要求选购时让厂商出示对应 firmware 版本——azloc-2606 文档里每个型号都标了最低 firmware如 Arista EOS 4.26.2FHPE CX 10.16.1020 等8. 配额、PowerShell 与 Network ATC 计划8.1 Node 配额分配每个节点的 RDMA NIC 必须在两房间内对称分布azloc-2606 拓扑 A 原文each nodes storage interface supports only one storage intent per interface22 配置room A 节点 1、2room B 节点 3、4。每个节点 NIC 1 VLAN 711NIC 2 VLAN 712不能节点 1 用 711712节点 2 用 712711——会造成 SMB Multichannel 路径不对齐8.2 Network ATC intent 建议Intent 类型VLAN适配器备注Management7SET 1mgmtcompute 共享可与 compute 共用 SETCompute8SET 1mgmtcompute 共享Storage 1711独立 NIC不走 SETRDMAStorage 2712独立 NIC不走 SETRDMAazloc-2606 host-network-requirements 原文明确storage intent 必须独立we recommend using multiple subnets and VLANs to separate storage traffic。all-in-one NIC team 会让 SMB Multichannel 流量打满单一接口。8.3 部署模式选择azloc-2606 给出两种部署入口Azure portal 部署参考deploy/deploy-via-portal—— 适合 22 / 33ARM template 部署参考deploy/deployment-azure-resource-manager-template—— 适合 44 或批量复制建议第一次部署用 portal可视化、可追溯后续扩容/批量复制用 ARM template幂等、可审计建议一个 Cluster 生命周期尽量保持一致的部署方式以减少配置漂移——不同入口portal / ARM template对 cluster state 的建模不完全一致8.4 部署前验证工具集建议在部署前跑一遍这是规划阶段常被遗漏的验证窗口。下面这些工具应在布线完成、OS 装好、Arc register 完成后、部署 cluster 前跑8.4.1 Windows 节点侧验证工具验证内容期望输出Test-NetConnection -ComputerName peer -Port 445跨房间 SMB TCP 连通TcpTestSucceeded TruePingReplyDetails.RTT 接近线缆理论值Get-NetAdapterRdmaRDMA 状态2 块 storage NIC 都报RdmaEnabled 1OperationalSpeed≥ 25 GbpsGet-SmbClientNetworkInterfaceSMB Multichannel 配置列出所有可用 NIC含 RDMA 能力Get-SmbMultichannelConnection当前 SMB 多通道会话应能看到 RDMA 路径Test-ClusterCluster validation全部 OKstorage / network 类目重点看Get-NetQosPolicyDCB / PFC / ETS 策略应有 storage intent 关联的 priorityGet-NetAdapterQos网卡级 DCB 状态PFC、ETS 状态符合 Network ATC 配置Get-NetAdapterAdvancedProperty驱动版本与固件DriverVersion 与 OEM 验证列表一致非 inbox8.4.2 网络层验证工具验证内容lldp/lldptoolLLDP neighbor 是否可见、DCB TLV 是否通告TOR 命令厂商私有PFC/ETS/Buffer 配置是否符合 azloc-2606 reference-architecture 模板iperf3跨房间 TCP/UDP 带宽 延迟ntttcp多线程 RDMA 吞吐更适合 Azure Local 场景ethtool从 Linux 工具机NIC ring buffer / 中断合并 / 固件版本8.4.3 必须 GREEN 的清单跨房间 RTT ≤ 1 msTest-NetConnection多次取平均RDMA 在所有 storage NIC 启用DCB/PFC/ETS 在所有路径一致MSTP 不阻塞 storage VLANLLDP neighbor 全部可见网卡驱动非 inboxTest-Cluster全部通过这个清单的输出物 部署前 Checklist 的实测证据可以存档到知识库下次部署复用。9. 区域与合规azloc-2606 system-requirements-23h2 官方原文云支持的 regionAzure publicEast US、West Europe、Australia East、Southeast Asia、India Central、Canada Central、Japan East、South Central USAzure GovernmentUS Gov Virginia中国由 21Vianet 合作伙伴提供Az Stack HCI Catalog 是准入门槛azloc-2606 system-requirements-23h2 原文Microsoft Support may only be provided for Azure Local running on hardware listed in the Azure Local catalog。不在 Catalog 的硬件不被官方支持。上架前先核对 Azure Local Catalog。10. 规划阶段常见误区清单把 rack aware 当 DR 用——延迟 1 ms 限制决定它不能跨城以为能 55 / 66——azloc-2606 明示up to 44用 LBFO 替代 SET——azloc-2606 明示LBFO isnt supported用 inbox 驱动——azloc-2606 host-network-requirements 明示Inbox drivers are not supported用 RAID 卡或共享 SAS——azloc-2606 明示RAID controller cards ... shared SAS enclosures ... are not supported手工规划 Storage 网络 IP 或人为修改 Network ATC 自动生成的 Storage 网络配置——不推荐。Storage 网络 IP 应由 Network ATC 自动生成与管理MLAG 承载 storage 流量——azloc-2606 明示 storage 跳过 MLAG用 RoCE 却不配 PFC/ETS——RDMA 会丢包S2D 性能崩塌用 Guest RDMA——azloc-2606 明示不支持用 InfiniBand——azloc-2606 明示不支持11. 规划阶段交付物清单规划完成后应该输出以下文档供部署阶段执行节点 BOMCPU/内存/盘/NIC/Switch 型号及 firmware 版本机房布线图机柜位置、跨房间光纤、spine 连接VLAN/IP 分配表management/compute/storage VLAN 选号、subnet、gatewayNetwork ATC intent 矩阵intent 名称 ↔ VLAN ↔ 适配器部署模式决定portal vs ARM template区域与订阅选择含合规与 Azure 连接要求容量规划OS 盘 200 GB数据盘数、cache:capacity 比备份与回退策略azloc-2606 部署前的prepare to deploy清单跨房间延迟测量方案部署前用 ping / iperf3 / RDMA latency 工具实测两房间 RTT确认 ≤ 1 ms12. 第三方工程最佳实践非微软官方强制要求本节内容不是 azloc-2606 官方支持矩阵的一部分而是规划阶段可以参考的主流 OEM / 网络厂商工程建议。请在采用前自行评估与自身环境的契合度。厂商 / 来源工程建议非 azloc-2606 强制Dell Technologies跨机柜双路径光纤统一 NIC 固件版本部署前进行 RDMA 与交换机一致性验证BIOS/BMC firmware 与 OEM compatibility matrix 对齐HPE扩容时保持 BIOS、BMC、NIC 固件一致使用经过验证的交换机配置模板iLO / OneView 集中管理LenovoXClarity 统一管理ThinkSystem 机型 firmware baselineRDMA NIC 验证在 SUSE / Windows 双平台Cisco Systems启用 RoCE 无损网络配置关注交换机缓冲区与 ECN 参数调优Nexus Dashboard 集中策略下发Arista Networks统一 EOS 版本验证 MLAG 与 VLAN 配置一致性升级前完成 RDMA 连通性测试EOS 4.x 系列有专门 RoCE buffer 调优文档NVIDIAMellanox根据流量模型调整 PFC、ECN、Buffer 与 QoS 参数减少拥塞扩散和 Head-of-Line BlockingSpectrum-X 系列专门面向 RoCE 优化重要边界上述内容不在 azloc-2606 官方文档内它们不替代azloc-2606 的官方支持矩阵Catalog、firmware 最低版本、Driver 要求等写在这里的目的是让规划阶段多一份视角避免遗漏工程上已被验证的做法任何与 azloc-2606 冲突的内容以 azloc-2606 为准。