微软未来ISCSI会不会支持iSER+iWARP（RDMA）？

微软的Azure Local在支持外部连接iSCSI存储，说明微软还没有放弃iSCSI，只选择SMB，既然选择了iSCSI，微软是否就应该加强对iSCSI技术的支持，而不仅仅是NVME Over TCP，RDMA+ISCSI应该是一个好的发展方向，在存储介质相同的情况下，RDMA+ISCSI与NVME Over TCP谁的性能更有优势？

我认为你的观察是准确的，而且你提出的是一个值得深入讨论的架构问题。不过，我会把它分成微软产品战略 和纯技术性能两个层面来看，因为这两者的答案并不完全相同。

第一，Azure Local 支持外部 iSCSI，说明微软并没有放弃 iSCSI

这一点我同意，近两年的 Azure Local（原 Azure Stack HCI）文档已经明确支持：

外部 iSCSI SAN
FC SAN（部分厂商）
NVMe/TCP Storage
Storage Spaces Direct（本地盘）

这说明微软已经形成了比较清晰的定位：

存储类型	Azure Local 是否支持	定位
S2D 本地存储	✅	首选
外部 iSCSI SAN	✅	兼容企业现有 SAN
外部 FC SAN	✅	大型企业
NVMe/TCP	✅	新一代 SAN

也就是说：微软没有放弃 iSCSI。

但是：微软对 iSCSI 的定位已经变成：

兼容 Existing Infrastructure

而不是：

Future Storage Architecture

这是两个完全不同的定位。

第二，如果微软继续投入 iSCSI，那么 iSER+iWARP 是不是最合理？

从纯技术角度，我认为答案是：是的。

原因有几个。

iWARP 天生就是 TCP

iWARP 的协议栈：

复制代码

SCSI
   │
iSER
   │
RDMA
   │
TCP
   │
Ethernet

它最大的优点：

不需要 PFC
不需要 ETS
不需要 DCB
不需要 Lossless Ethernet

而 Azure 最大特点就是：

规模：规模越大

越怕：配置复杂。

RoCE 最大的问题就是网络

RoCE v2：理论很好。

现实里面：运维最怕：

PFC Storm
HOL Blocking
Buffer 调优
ECN
RED
ETS

微软在 Azure 的很多论文里面其实一直强调：

Lossless Ethernet 是很难维护的。

所以：后来微软越来越强调TCP。

第三，那么为什么微软没有做 iSER？

这里我认为主要不是技术问题。

而是：市场问题。

例如：2016 年支持 iSER Target 的厂商其实并不多。

支持 Windows Initiator 的几乎没有。

Linux：支持很好。

Windows：没有。

如果微软自己做：

意味着整个：

复制代码

Windows Initiator
+
Windows Driver
+
Certification
+
Storage Vendor

全部要重做，投入巨大。

而NVMe 已经来了。

微软自然不会继续投资SCSI。

第四，从性能角度比较

假设，完全一样：

复制代码

100Gb Ethernet

同样 SSD

同样 CPU

同样网卡

比较：

A：

复制代码

iSER+iWARP

B：

复制代码

NVMe/TCP

很多人会认为：

NVMe 一定快。

其实：未必。

数据路径

iSER

复制代码

Application

↓

SCSI

↓

iSER

↓

RDMA

↓

NIC DMA

↓

Memory

整个过程：Zero Copy。

CPU几乎不参与。

NVMe/TCP

复制代码

Application

↓

NVMe

↓

TCP

↓

Kernel

↓

NIC

TCP仍然存在。

所以仍然需要：

Socket
Copy
ACK
TCP Window

CPU一定比RDMA高。

Latency

一般来说，如果都是优秀实现：

RDMA：

复制代码

10~20 μs

NVMe/TCP：

复制代码

40~80 μs

不同厂商略有差异，但 RDMA 往往仍具有更低的网络协议开销。

CPU

RDMA的CPU开销最低。

NVMe/TCP的CPU大约比RDMA高20~40%。

带宽

100Gb：两者几乎都能跑满。

真正差异，主要是CPU。

第五，那么为什么大家都在发展 NVMe/TCP？

这是一个：工程问题。

不是性能问题。

例如：10000 台服务器。

采用：RoCE：

需要：

DCB
PFC
ETS
ECN
Buffer

全部配置正确。

否则RDMA性能下降。

而NVMe/TCP：

复制代码

普通交换机

普通 TCP

普通 VLAN

即可。

因此：微软、Dell、Pure Storage、NetApp、HPE越来越支持NVMe/TCP。

不是因为：最快，而是因为部署成本最低。

我的判断：未来微软可能会出现第三条路线

结合 Azure Local 2025/2026 的发展方向，我认为微软未来更可能形成这样的存储策略：

场景	主要协议	原因
Azure Local（S2D）	SMB Direct + RDMA	节点间复制、CSV、Live Migration 等深度依赖 SMB 生态
外部 SAN（新部署）	NVMe/TCP	简化网络、兼容现代全闪阵列
外部 SAN（存量环境）	iSCSI	保护客户已有投资
高性能 HPC/AI	NVMe/RDMA（如果生态成熟）	追求极低延迟和 CPU 占用

至于 iSER+iWARP ，我认为它技术上仍然是一种非常优秀的设计。如果只看协议效率，它在网络延迟和 CPU 开销方面通常仍优于 NVMe/TCP。然而，它面临两个现实问题：

产业生态 ：目前几乎所有主流 NVMe 存储厂商都把研发重点放在 NVMe/TCP 和 NVMe/RDMA（主要是 RoCE），而不是 iSER。
长期演进方向 ：整个存储行业正在逐步从 SCSI 迁移到 NVMe。因此，厂商更愿意把研发资源投入到 NVMe over Fabrics，而不是继续扩展基于 SCSI 的 iSER。

因此，如果单纯比较协议效率，在相同硬件条件下，RDMA+iSER 通常可以获得比 NVMe/TCP 更低的 CPU 占用和更低的网络延迟 ；但如果综合考虑产业支持、设备兼容性、未来演进和运维复杂度，NVMe/TCP 已经成为主流厂商共同推进的方向。这也是微软目前在 Azure Local 中保留 iSCSI 兼容能力，同时重点投入 NVMe/TCP，而没有重新投入 iSER 的主要原因。