网上有个说法挺有意思:"NVMe-oF嘛,随便拿张万兆网卡就能跑,反正都是走网络。"
这话只说对了一半。NVMe-oF确实走网络,但走什么样的网络,差别大了去了。用一张不带RDMA的普通万兆网卡去跑NVMe-oF,就像拿家用轿车去跑拉力赛——理论上是四个轮子都能转,真上了场地就知道差距了。
这个说法也不是完全没道理。NVMe-oF协议在设计上兼容TCP传输,也就是说,哪怕你手头只有一张最普通的千兆电口网卡,理论上也能搭建起NVMe over TCP的环境,把远程NVMe SSD挂载到本地。配置好Linux内核的nvme_tcp模块之后,nvme list确实能看到远端设备。
问题出在性能上。用过NVMe SSD的人都知道,单块NVMe盘的顺序读写轻松跑到3GB/s以上,延迟在几十微秒级别。而一张普通万兆网卡在TCP传输模式下,经过内核网络协议栈的层层拷贝,延迟直接跳到几百微秒甚至毫秒级,吞吐量也缩水到几百MB/s。
打个比方:你都买了超跑发动机(NVMe SSD),结果给配了个自行车链条(普通网卡+TCP协议栈),传动效率完全跟不上。
NVMe-oF真正的性能核心不在网络协议本身,而在RDMA(Remote Direct Memory Access)。
RDMA允许数据直接从一台服务器的内存传输到另一台服务器的内存,完全绕过CPU、缓存和操作系统内核。这意味着零拷贝、低延迟、低CPU负载——这三项正是存储系统最在意的指标。
NVMe-oF原生支持两种RDMA传输层:RoCE(RDMA over Converged Ethernet,基于以太网)和InfiniBand(专用网络)。对于绝大多数数据中心来说,RoCE v2是最务实的选择——它跑在标准以太网上,不需要额外的专用交换机硬件。从运维角度看,运维团队不需要学习两套网络管理工具,一套以太网命令搞定所有。从成本角度看,RoCE方案的交换机端口单价远低于InfiniBand。
以LR-LINK的 LRES1026PF-2SFP28 为例,这是一张25G双光口RDMA智能网卡,支持RoCE v2协议。它的RDMA引擎在硬件层面完成数据的封装、校验和传输,CPU只需要下发任务指令即可。实际测试中,25G RDMA模式下NVMe-oF的CPU占用率不到5%,而同等带宽的TCP模式CPU占用率在50%以上。25G的带宽也足够喂饱大部分NVMe SSD的读写能力。
如果存储节点需要更高的端口密度,LRES1021PF-2SFP28 同样是25G双光口方案,在虚拟化环境中的SR-IOV性能表现稳定,适合VMware vSAN等超融合场景。
不是所有标了"万兆"或"25G"的网卡都能胜任NVMe-oF场景。选型时要看的核心指标有三个:
RoCE v2支持是前提。 判断一张网卡是否适合NVMe-oF,最简单的办法就是查规格表里有没有"RDMA"或"RoCE v2"字样。网卡必须在硬件层面支持RDMA引擎,把数据的封装、校验、传输卸载到网卡上。一张普通网卡和一张RDMA网卡在相同速率下的NVMe-oF性能差距,可能达到3-5倍。区别在于,普通网卡的每个数据包都要经过内核协议栈处理,而RDMA网卡在硬件层面就完成了数据搬移。
带宽要能跟上SSD的爆发力。 NVMe SSD的爆发性写入对网络带宽要求很高。以单块NVMe盘3GB/s算,跑满需要约24Gbps的网络带宽。如果同时接入4块NVMe盘,带宽需求就接近100Gbps。所以25G是NVMe-oF的入门起点,16块盘以上的存储节点至少需要100G上行。LB(负载均衡)和链路聚合虽然能叠加带宽,但对NVMe-oF这种延迟敏感场景来说,单条链路跑满比多条链路聚合效果更好——因为链路聚合的哈希分发可能导致某个数据流排队,增加延迟抖动。
长期可靠比短期省钱更重要。 NVMe-oF对网络的丢包率极其敏感——RoCE v2要求端到端无损网络。千分之一的丢包率就可能让RoCE吞吐量腰斩。选择有完整兼容性验证的网卡方案,能避免很多莫名其妙的问题。
NVMe-oF网卡选型三要素:第一,确认支持RDMA/RoCE v2;第二,根据NVMe SSD数量和读写负载选择25G或100G速率;第三,优先选择有充分兼容性验证的品牌方案,避免丢包敏感导致的性能断崖下跌。
拿一张普通25G网卡(不带RDMA)去跑NVMe-oF会怎样?
CPU占用率直接飙到60%-80%,因为数据每经过一次内核协议栈就要拷贝一次。NVMe SSD的延迟优势被完全浪费——本地NVMe盘延迟约20微秒,走NVMe-oF TCP模式后跳到300微秒以上,翻了十几倍。
而一张支持RDMA的25G网卡,比如 LRES1054PF-2SFP28,通过RoCE v2能把延迟控制在50微秒以内,CPU占用率降到5%以下,这才是NVMe-oF该有的水平。
对存储后端来说,100G RDMA网卡才是理想方案。LRES1046PF-2QSFP28 这张100G双光口RDMA智能网卡,能轻松应对多路NVMe SSD同时写入的带宽需求。对于大规模存储集群,LRES1080PF-2QSFP56 提供了更强的100G线速转发能力。
对于采用OCP形态的服务器,也可以考虑 LRES3040PF-OCP,它是OCP 3.0规格的25G双光口RDMA智能网卡,适合华为、浪潮等主流服务器品牌的计算节点。
这里给一个务实的分级参考:
| 场景 | 推荐速率 | 推荐网卡 | RDMA支持 |
|---|---|---|---|
| 小型NVMe-oF集群 | 25G | LRES1026PF-2SFP28 | RoCE v2 |
| 中型存储后端 | 25G/100G | LRES1054PF-2SFP28 / LRES1014PF-2QSFP28 | RoCE v2 |
| 大型全闪存集群 | 100G | LRES1046PF-2QSFP28 / LRES1080PF-2QSFP56 | RoCE v2 |
| OCP形态计算节点 | 25G | LRES3040PF-OCP | RoCE v2 |
NVMe-oF选型中还有一个常见误区:"RDMA必须用专用交换机。"
RoCE v2跑在标准以太网上,只要交换机支持DCQCN(数据中心量化拥塞通知)和PFC(优先级流控),就能构建无损RoCE网络。绝大多数中高端数据中心交换机都具备这些能力。
另一个误区:"NVMe-oF延迟绝对比本地NVMe高很多。"其实在100G RoCE v2环境下,端到端延迟能做到20-30微秒,跟本地NVMe的差距已经很小了。对于分布式存储系统来说,这个级别的延迟完全可以接受。
技术选型的目标不是选"最贵的",也不是选"最熟悉的",而是选"最匹配的"。NVMe-oF的网卡选型说到底就一句话:认准RDMA,选对速率,别让网卡成为存储性能的瓶颈。
| 型号 | 速率 | 接口类型 | 端口数 | 特性 |
|---|---|---|---|---|
| LRES1026PF-2SFP28 | 25G | SFP28 | 双口 | RDMA RoCE v2 / PCIe 3.0 x8 |
| LRES1054PF-2SFP28 | 25G | SFP28 | 双口 | RDMA智能网卡 / PCIe 3.0 x8 |
| LRES1046PF-2QSFP28 | 100G | QSFP28 | 双口 | RDMA智能网卡 / PCIe 4.0 x16 |
| LRES1014PF-2QSFP28 | 100G | QSFP28 | 双口 | PCIe 4.0 x16 |
| LRES1080PF-2QSFP56 | 100G | QSFP56 | 双口 | RDMA智能网卡 / PCIe 4.0 x16 |
| LRES1160PF-2QSFP56 | 200G | QSFP56 | 双口 | RDMA智能网卡 / PCIe 4.0 x16 |
| LRES1021PF-2SFP28 | 25G | SFP28 | 双口 | PCIe 4.0 x8 |
| LRES3040PF-OCP | 25G | SFP28 | 双口 | OCP 3.0 / RDMA智能网卡 |
如果用NVMe over TCP模式,普通网卡确实也能用,但性能损失很大。NVMe-oF设计上就是为了发挥NVMe SSD的低延迟高吞吐特性,不用RDMA相当于买椟还珠。建议至少选择25G RDMA网卡,比如 LRES1026PF-2SFP28。
RoCE v2跑在标准以太网上,不需要专用交换机和线缆,成本低、运维简单。InfiniBand延迟更低但生态封闭。绝大多数数据中心存储场景选RoCE v2就够了,兼容性更好、升级路径更清晰。
取决于NVMe SSD的数量和读写负载。2-4块NVMe盘选25G够用,8块以上推荐100G。需要注意的是25G网卡价格约为100G的三分之一到五分之一,预算紧张时可以先用25G起步,后续通过链路聚合或升级到100G平滑扩展。
RoCE v2需要交换机支持DCQCN和PFC功能,目前主流数据中心交换机基本都支持。如果交换机比较老旧,也可以启用软件的ECN(显式拥塞通知)配合网卡侧流控,但效果不如硬件PFC好。
LR-LINK的RDMA网卡在Linux内核4.15以上版本中,主流发行版(Ubuntu、CentOS/RHEL、Debian)均可原生驱动,支持rdma-core用户态库。Windows Server 2019/2022也提供官方驱动,兼容性覆盖常见超融合平台。