微软为什么建议Azure Local全NVME场景选择RoCE RDMA

在微软的 Azure Local和 Storage Spaces Direct (S2D) 官方架构指南中针对全 NVMeAll-NVMe的极高性能场景微软确实强烈建议使用 RoCE v2 (RDMA over Converged Ethernet) 来替代 iWARP。虽然微软在过去的技术推广中如万兆 10GbE 或混合存储时代因为“易部署性”而频繁推荐过 iWARP但在进入全 NVMe 时代后天平明显向 RoCE v2 倾斜。主要原因有以下几点1. 极致的吞吐与延迟表现匹配 NVMe 的性能全 NVMe 阵列的单盘 IOPS 和带宽极其恐怖这时候网络成为了第一瓶颈。RoCE v2是基于内核旁路Kernel Bypass并直接封装在 UDP/IP 上的由网卡硬件层直接处理时延通常在1-5微秒级别。iWARP运行在标准的 TCP/IP 协议栈上。为了保证数据包顺序和可靠性它的架构包含了 DDP、MPA 等较复杂的层级。这使得其延迟通常在10-15微秒。 在全 NVMe 场景下iWARP 较高的网络延迟会直接“拖累” NVMe 的极速响应优势。2. 硬件卸载与 CPU 开销公有云如微软 Azure 自身的大规模实践表明RoCE v2 的硬件卸载Offload更彻底。RoCE v2能够实现近乎零的 CPU 占用率。iWARP由于要在网卡上维护复杂的 TCP 状态机State Machine在大规模高并发吞吐时网卡自身的处理芯片很容易遇到瓶颈或者对主机 CPU 的释放不如 RoCE v2 彻底。微软在自家 Azure 存储后端的 RDMA 流量中绝大多数也都是基于 RoCE 架构。3. 生态系统与高带宽25G / 100G支持随着 HCI 步入 25GbE、50GbE 甚至 100GbE 时代主流的高性能网卡厂商如 NVIDIA/Mellanox ConnectX 系列以及 Intel 最新的高性能网卡都将 RoCE v2 作为其主打的超高性能传输协议。在全 NVMe 的超高带宽需求下RoCE v2 的硬件选择和成熟度都更具优势。⚠️ 微软全 NVMe 选 RoCE v2 的硬性前提虽然 RoCE v2 性能无敌但它对网络环境极其挑剔。 如果你决定听从微软的建议在全 NVMe HCI 中采用 RoCE v2你的物理交换机必须配置并支持DCB数据中心桥接、PFC优先流量控制和ECN显式拥塞通知。必须保证整个存储网络是**无损Lossless**的。如果交换机配置不当导致丢包RoCE v2 的性能会发生断崖式下跌。如果你的团队有足够强的网络运维能力、交换机支持 DCB全 NVMe HCI 选择RoCE v2能够压榨出硬件的最大潜能如果网络是普通传统交换机且完全不想折腾网络配置才退而求其次选择免交换机配置的 iWARP但会牺牲一部分全 NVMe 的极致性能。