问题
传统通信导致的业务瓶颈【TCP通信相比】
Embedding Table巨大的存储需求使得这些系统通常采用CPU和GPU异构部署的方式构建. 随着模型参数量剧增, 特别是模型需要捕获用户更长期更丰富的行为, 同时物料Embedding也快速增长时, Embedding Table这些存储节点和GPU推理服务器之间的通信还在使用TCP导致CPU占用率占用高、延迟高、吞吐低等劣势, 严重制约了服务响应时间,限制了模型预估机器的ScaleOut规模.
RDMA部署难点【CPU架构混部】
通常CPU集群和GPU集群部署时, 通常放在不同的Pod, 异构节点之间的通信会存在大量约束.
首先对于通用计算节点, 部分老的服务器并没有RDMA网络, 构建独立的RDMA网络成本也很高. 因此通常需要实现超大规模RDMA和TCP混跑的能力, 两种流量的拥塞控制算法有着很大的区别, 混跑时的公平调度也是非常困难的.
另一方面是由于部署时, 通常不同类型的服务器放置在不同的Pod中, 通常数据需要跨越Pod甚至跨越AZ传输.
当需要大规模组网时, 并且需要和TCP混跑, 给RDMA的拥塞控制带来了极大的挑战.
《快手DHPS：国内首个实现基于RDMA 通信的可负载均衡高性能服务架构！》：https://mp.weixin.qq.com/s/rrwzlQIG0XbMvApHZilAkg
快手通过在MLNX网卡上使用自研的拥塞控制算法, 利用 RTT + ECN + TX_Event这些精细化的信号构建了Rate-Based结合Window的拥塞控制. 然后实现了Lossy RoCE的支持, 避免了PFC带来的影响. 同时一定程度上支持了多路径转发. 最后构建了TCP和RDMA双栈混跑的能力. 总体来看整个系统架构如下:
根据快手的消息来看, 跨越4层网络后的带宽利用率为90%, 很不错的工作. POD内P99延迟比DCQCN好30%, POD间比TCP好30%. 同时整个协议栈也保持了兼容性.
基于eRDMA的方案【PFC在Overlay云网络挑战】
在云网络中有大量的租户, 各种业务的流量混跑在一起, 对于开展RDMA业务带来了极大的挑战. 传统的基于Lossless网络无法满足云的大规模部署需求, PFC在Overlay网络中也无法构建, 即便是更改一些协议也会导致多个租户之间的流量干扰影响性能.
在提供这些RDMA服务时, 期望能够和用户生态相兼容, 显然就是线下的基于MLNX的RDMA应用能够不修改任何代码直接在线上环境运行. 那么我们仅能选择采用RDMA RC Verbs兼容的接口. 另一方面我们还期望能够对原有的TCP应用进行加速, 并且也需要维持原有的软件生态不改变.
PFC:
PFC（Priority-based Flow Control，基于优先级的流量控制）在 Overlay 网络中主要用于实现无损流量传输，但由于 Overlay 网络的特性，其应用存在一些挑战与相应解决方法
RC Verbs接口:
RC Verbs 接口是远程直接内存访问（RDMA）技术中的一种编程接口，与 RDMA 的可靠连接（RC）服务类型相关，主要用于管理和操作 RDMA 中的队列对（QP）等资源，以实现高效的数据传输
RDMA和TCP混跑的难题
对于业务系统通常客户已经发展了很多年, 并且期望能够以应用不感知, 同时以平滑升级的方式升级. 这是这几点业务上的需求, 使得我们需要TCP和RDMA混跑. 相反如果采用独立组网, 带来的网络成本上升还不如多购买一些CPU服务器, 因此我们需要一种零成本的方式来实现性能30%的提升.
当混跑时, 我们发现在RDMA重载流量时, CX6 TCP和RDMA业务流量的平均延迟和长尾延迟都有数倍的上升, 显然这种情况下部署RDMA是得不偿失的.
QP：
DMA 有多种 QP 类型，根据可靠性可分为可靠（Reliable）和不可靠（Unreliable），根据连接性可分为连接（Connected）和非连接（Unconnected）。
TCP 则是基于连接的协议，通过三次握手建立连接，虽然也有类似连接的概念，但与 RDMA 的 QP 连接方式和特性不同，它是基于端口号和 IP 地址来建立端到端的连接，在连接建立后进行数据传输，保证数据的有序性和可靠性。
在 RDMA 中，若采用 RC 方式，假设 N 个节点，每个节点有 M 个进程，需要使用 M²*N 个 QP，资源占用较多。而 TCP 是基于套接字（Socket）进行通信，每个连接由源 IP 地址、源端口号、目的 IP 地址和目的端口号唯一标识，其连接管理和资源占用方式与 RDMA 的 QP 不同，通常不会像 RDMA 的 RC 那样产生大量的连接资源需求。
flow：
CP 的 Flow 具有流突发特性，数据包通常以突发（Burst）方式发送。Flowlet 就是利用这一特性，将 TCP Flow 细分为多个 Flowlet，以实现负载均衡。而 RDMA 流量不符合 TCP 的这种突发特性，它使用基于硬件的连接级数据包调度（即速率整形），导致连续的数据包流并且具有较小的时间间隔。在 RDMA 中，Flow 可以通过一对 RDMA QP 来标识，其 Flow 的概念更多与 QP 相关联，和 TCP 中基于应用层数据特征及传输特性定义的 Flow 有所不同。
方案
eRDMA生态相兼容【云网络解决办法】
在eRDMA的基础上提供了SMC-R和NetACC的技术. 最后我们的技术选择如下:
我们选择了在VPC上支持RDMA, 并提供原生的多路径能力, 兼容标准的RC Verbs接口. 同时考虑到运维的复杂性, 我们并没有采用端网融合的技术,而是简单的在端侧构建拥塞控制和可靠传输机制, 降低对已有的DCN的影响. 同时我们在流量公平调度上, 采用了TCP和RDMA相对独立的令牌桶, 使得eRDMA和TCP公平共享带宽. 最后在系统层面, 我们还实现了RDMA的虚拟化, 并支持RDMA热升级和热迁移的能力, 提高了系统的稳定性.
DCN：
DCN 通常指数据通信网络（Data Communication Network）是最常见且核心的含义之一。它特指用于传输数据、实现设备间信息交互的网络系统，广泛应用于企业、数据中心、运营商网络等场景，承担着数据、指令、控制信号等的传递功能。
eRDMA和TCP混跑调度【解决混跑难题】
当RDMA和TCP采用不同QP和不同Flow数量混跑时, 如何保证带宽公平性. 这里商卡也需要很多复杂的调整. 而eRDMA设计时就是按照业务类别均分. 当只存在TCP或者RDMA时, 单个业务能够打满带宽. 而两者共存争抢带宽时, 我们保证两者之间与QP/TCP-Flow数量无关.
正是因为我们解决了eRDMA和TCP混跑的难题, 特别是无需用户任何配置, 完全自服务的方式解决干净后. 用户就可以大量开展相关的工作了.
《基于eRDMA部署高网络性能的bRPC应用》：https://help.aliyun.com/zh/ecs/use-cases/deploy-brpc-applications-with-high-network-performance-based-on-erdma
基于eRDMA的TCP透明加速
能不能不改应用, 在应用无感知的情况下获得eRDMA的高质量网络性能? 和操作系统团队一起借助于IBM在大型机种的SMC-R技术构建了一个透明转换的传输方式
《共享内存通信（SMC）使用说明》：https://help.aliyun.com/zh/ecs/user-guide/smc-instructions
收益
阿里SMC参考
例如使用Nvidia开源的WideAndDeep[5]进行测试, ps采用 ecs.c8i.24xlarge 第8代CPU实力, worker: ecs.ebmgn8is.32xlarge 即采用8卡L20.
当使用SMC-R技术, 在用户完全无感知的情况下, 多种PS/Worker数量配比下, 整体吞吐提升接近30%, 延迟下降30%.
PCC：
PCC 通常指可编程计算机控制器（Programmable Computer Controller）。PCC 上的开发涉及硬件配置与软件编程等多个方面
基于网络相关思考
一般SDN设备都采用YANG Model来定义，或者是一系列在转发层面上抽像出来的Object Tree模型，一个设备的运行状态和物理拓扑路由表等大量的状态都可以构成一个图结构
通过对故障时和正常时的图同构算法对比，其实很容对故障归因。
另一方面，假设我们需要对一个数据包经过了哪些网络设备遇到了哪些问题进行归因分析，通常会对Netflow等日志进行搜索，但是网络中又存在NAT等地址转换信息，导致查询时需要分段索引，或者实时的基于Flow做分布式Join等 当然很多公司都借助于云上的大数据平台来构建了一套分析系统，
例如阿里云的vTrace或者思科的vAnalytics，但是对于一些私有云部署的设备又存在网络安全和隐私相关的担忧需要对这些数据离线处理。
设计了一套基于Clickhouse+Neo4j的算法，搜索上利用网络物理拓扑和一些概率模型构建类似的HNSW搜索机制，避免了分布式Join的方式，同时数据可以采用Clickhouse分Region存放，并行搜索的处理方式。整个查询速度提升了1000x