RDMA-03-业务实践
概述
大概在2018-2020年左右，做过一些基于 Kubernetes 的云原生 AI 的工作，其中在大规模的高性能计算中，涉及到一些 RDMA 的框架和应用，简单介绍一下。
基础架构
TCP_RR(次/秒): 测试同一个TCP连接中的多次TCP request和response的响应效率
传统的 Bridge+VLAN 的方式相对 NAT 来说是有很大的提升，但是对于当时一些对网络质量要求非常高的业务和场景，比如游戏以及 MySQL Proxy 这样的组件，传统的网络方案无法达到业务的需求。以上是当时使用的 SR-IOV 模式，这种模式在 zen/kvm 虚拟化上用的比较多，游戏也需要这种高性能的网络方案，因此我们把这种网络方案也结合到 Docker 容器里面。
这里需要硬件的支持，结合 SR-IOV 技术的网卡，在 Docker 容器内就可以直接通过驱动来加载虚拟的网卡并使用。使用的方式就如同在一台物理机上使用一个真实的物理网卡一样，这个虚拟网卡也拥有驱动程序，也拥有 PCI BUS ID，因此所有的虚拟机网络操作都如同操作普通网卡一般，从而在性能上得到提升。
为了进一步发挥 SR-IOV 的网络性能，还需要对容器的相关网络参数进行配置，主要包括以下几个方面，VF 中断 CPU 绑定；关闭物理机的 irqbalance，容器内设置 RPS（软中断均衡）网卡不能中断均衡，对高性能的网络形成了阻碍。为了解决这个问题，需要设置容器内的软中断均衡。通过上述的调整，性能得到了大幅度提升。
上图是当时测试的一个结果，物理机/Bridge/SR-IOV，SR-IOV 在网络性能方面基本上已经接近了物理机，所以这个对于游戏大包量、大流量的应用是非常适合的，现在我们把 SR-IOV 网络作为传统游戏里默认的网络模式，所以在做离线计算的时候，针对有高性能计算需求的业务和框架，我们自然就考虑到用 RDMA 来加速，随着业务的发展，慢慢这些业务容器都迁移到了 Kubernetes 上进行调度，所以后来就有了基于 Kubernetes 的这些内部项目的开源 sriov-cni，k8s-rdma-device-plugin，这些架构的应用都得到了当时大量业务的应用、验证和实践。
RDMA
因为有了专用硬件（RDMA网卡/IB交换机）和基础架构的支持的，所以可以进行大量的业务的尝试和应用，其中在离线计算上应用的最为广泛，最典型的就是 Spark 和 Tensorflow 的工作负载。
Spark RDMA
SparkRDMA 是一个 Spark 的高性能的 ShuffleManager 插件，由 Mellanox 开发。关于 SparkRDMA 作为插件或者内置的选项合并进入 Spark 里，有一个 JIRA 在讨论。当然了，最后讨论是没有结论的，但是 SparkRDMA 确实值得一试。但是使用的话需要主机硬件支持 RDMA。Kubernetes 集群的机器可以通过给设备打上合适的网卡的标签，可以促使 Shuffle 阶段放入这些机器中执行。当时的业务还主要在使用比较早起的 Spark 2.2，以及刚刚原生支持 Spark on Kubernetes 的 Spark 2.3 以及还没有 Release 的 Spark 3.0 版本，当时我们是将这些依赖打入到 Spark 的依赖中（针对高版本的Spark当时还需要在源码上适配），给用户提供了 SparkRDMA Shuffle Manager 的选项，让一些离线计算的业务应用得到了很大的性能提升。
Tensorflow/Horovod
当时业务应用 Tensorflow 一般是应用在模型的训练上，Horovod 则是一个分布式训练框架，其中通过 MPI 可以实现 All Reduce 这样的网络通信架构，MPI 又是可以直接调用 RDMA 的库，从而可以实现训练的网络加速，早起在没有 tf-operator/mpi-operator 的条件下，我们是通过一个 submit Pod 将计算任务的执行脚本封装在一个 Pod 内向 kube-api-server 提交创建和运行任务的资源请求，并且自行维护计算任务和 Pod 之间的生命周期，但是一般来说 Kubernetes Infras 和 AI infras 是会有技术栈的 GAP 的，所以在早起对于任务以及 Pod 之间的状态转移是比较困难的，在 Kubeflow 开始流行之后，这一套框架就自然升级到 Operator 来运行了。
总结
在有专有硬件和网络架构的支持下，RDMA 在大规模的计算和训练中，是可以大大提升了网络传输的效率的，是非常有应用价值的。