第1章课程导论

课程导论：为什么需要跨数据中心RoCE？

大家好，我是你们这门课的老朋友。今天咱们聊聊一个很现实的问题——为什么要把RoCE拉到跨数据中心这个场景里？

说实话，我刚开始接触这个课题时，也觉得有点多此一举。RoCE在单个数据中心里跑得好好的，干嘛非要折腾到几百公里之外？但后来我发现，这其实是业务倒逼出来的需求。

核心观点：跨数据中心RoCE不是技术炫技，而是分布式存储、AI训练、实时容灾等场景的刚需。

先说说我遇到的一个真实案例。前几年帮一家金融客户做两地三中心方案，他们要求A中心到B中心的存储同步延迟必须低于1毫秒。传统TCP/IP方案根本做不到，因为TCP的拥塞控制、重传机制在长距离下太慢了。最后我们上了RoCE over WAN，才勉强达标。

你想想看，现在很多业务都是跨DC部署的：

这些场景的共同点是什么？低延迟、高吞吐、零丢包。传统TCP/IP在跨DC场景下，延迟动不动就几十毫秒，吞吐还受限于窗口大小。RoCE的RDMA特性正好能解决这个问题——它绕过了内核协议栈，数据直接从应用内存到网卡，延迟能降低一个数量级。

个人经验：我曾在某云厂商的跨DC存储项目中做过对比测试。同样100G链路，TCP延迟约800μs，RoCE v2只有120μs。差距就是这么明显。

嗯，这里有必要快速回顾一下RoCE的版本演进。毕竟后面讲跨DC方案时，很多细节都跟协议版本有关。

最早的版本，说白了就是把RDMA封装在以太网帧里。它依赖链路层的流控机制（PFC）来保证无损。但有个致命问题——它只能在同一个二层网络里跑，不能跨VLAN，更不能跨IP网络。所以跨DC基本没戏。

这个版本做了关键改进：把RDMA封装到了UDP/IP里。这样一来，RoCE流量就能像普通IP包一样路由了。跨DC的核心基础就是RoCE v2。

我画了一张图，帮你理清这两个版本的区别：

从图上你能看到，RoCE v2最大的变化就是在IB Transport下面插入了UDP和IP层。这个改动看似简单，但意义重大——它让RoCE流量能穿越路由器、防火墙，甚至公网。

注意：RoCE v2虽然能路由，但UDP封装也带来了新问题。比如NAT穿越、MTU分片、安全过滤等。这些在跨DC场景下都是坑，后面章节我会详细讲。

好了，既然RoCE v2能路由，那是不是直接拉根光纤就能跑？当然不是。我踩过的坑比你们想象的多得多。下面这三个挑战，是跨DC RoCE方案里绕不开的坎。

光速在光纤里大约是200,000km/s。北京到上海1000公里，单程延迟就是5ms。RDMA的RC模式要求端到端确认，这个RTT（往返时间）直接决定了吞吐上限。

举个例子：100Gbps链路，RTT=10ms时，理论上最大吞吐只有约1.25GB。但实际因为拥塞控制、重传等因素，能跑到60%就不错了。

我曾在某项目里遇到过：跨DC的RoCE链路，RTT从100μs飙升到8ms，结果存储集群直接报超时。后来发现是中间路由器的buffer不够，导致PFC反压扩散。

避坑指南：跨DC RoCE设计时，一定要算好带宽-延迟积（BDP）。建议预留20%的余量，别把链路跑满。

PFC（优先级流控）是RoCE无损网络的基础。它的原理是：接收端buffer快满时，发送PAUSE帧让对端暂停发送。但在跨DC场景下，这个机制会出大问题。

为什么？因为PFC的响应时间跟链路延迟成正比。假设RTT=10ms，一个PAUSE帧发出去，对端要5ms后才能收到。这5ms里，发送端可能又发了大量数据，导致接收端buffer溢出丢包。

我见过最夸张的情况：某客户跨DC RoCE链路，PFC触发频率高达每秒几千次，导致有效吞吐不到30%。整个网络都在"刹车-加速-再刹车"的死循环里。

这是最头疼的问题，没有之一。PFC死锁说白了就是：多个交换机互相发PAUSE帧，结果谁都不发数据了，整个网络卡死。

跨DC场景下，因为链路延迟大、buffer深度有限，PFC死锁的概率比单DC高得多。我曾在实验室复现过：三个交换机组成环路，RTT=2ms，跑满负载后不到30秒就死锁了。

解决思路有几个方向：

我的建议：跨DC RoCE方案里，尽量别依赖PFC。用DCQCN + ECN的组合，虽然配置复杂点，但稳定性好得多。我最近两个项目都是这么干的，效果不错。

好了，这一章的内容就到这里。核心就是三件事：为什么需要跨DC RoCE、RoCE v2为什么能跨DC、以及跨DC时最头疼的三个挑战。后面我们会逐一深入每个挑战的解决方案。

课后思考：如果你现在要设计一个跨DC RoCE网络，你会优先解决哪个挑战？我个人觉得PFC死锁是最致命的，因为一旦发生，整个业务就断了。