verbs FreeFlow:基于软件的虚拟RDMA容器云网络（下）

编制:严美美、王、、张春海

抽象的

为了实现资源的高效利用和轻量级隔离，许多流行的大规模云应用正在逐步使用容器化。同时，许多数据密集型应用(如数据分析和深度学习框架)正在采用RDMA来提高网络性能。行业趋势表明，这两种情景不可避免地会发生冲突。在本文中，我们介绍了FreeFlow，这是一个基于软件的RDMA虚拟化框架，是为容器云设计的。FreeFlow使用纯粹基于软件的方法，通过使用商业RDMA网卡来实现虚拟RDMA网络。与现有的RDMA虚拟化解决方案不同，FreeFlow完全满足云环境的要求，如多租户隔离、容器迁移的可移植性以及控制和数据平面策略的可控性。FreeFlow对应用程序也是透明的，并且以较小的CPU开销提供接近裸机RDMA的网络性能。在我们对TensorFlow和Spark的评估中，FreeFlow提供了与裸机RDMA几乎相同的应用性能。

第五章FFL和FFR之间的沟通渠道

由于自由流通过自由流网络库(FFL)拦截每个动词调用，并通过自由流软件路由器(FFR)将其解释和转发到物理网卡，因此在FFL和FFR之间建立有效的通道以提供高RDMA性能同时最大限度地减少系统资源消耗非常重要。在本章中，我们提出了两种这样的通信信道设计，根据应用要求，这两种设计允许用RDMA性能来交换资源消耗，反之亦然。

5.1由文件描述符转发的动词

图11:扩展容器对数量时的总吞吐量。

吞吐量:我们在两个测试平台上测量了单线程RDMA发送/写入的吞吐量，并在图9中显示了RDMA发送的结果。每次运行传输1GB的数据，不同大小的消息从2KB到1MB不等。FreeFlow RDMA WRITE的结果实际上比SEND稍微好一点，为简洁起见省略了SEND。我们可以看到，当消息大小等于或大于8KB时，FreeFlow将获得作为裸机RDMA的全吞吐量(InfiniBand为46.9Gbps，RoCE为34.5Gbps)。此外，当我们将并发容器对(流)的数量增加到512个时，所有流的总吞吐量仍然接近最佳值(图11)。我们还通过计算贾恩的公平指数[31](平均为0.97)，验证了带宽在不同流量之间的公平分布。

通常，需要大量带宽的应用程序倾向于使用大于几千字节的消息大小。例如，在我们使用RDMA的内部存储集群中，典型的消息大小为1MB或更大。在这种情况下，自由流不会有吞吐量损失(关于CPU开销，请参见8.1.2)。

即使消息很小，比如2KB，FreeFlow仍然可以达到总吞吐量的一半以上。在这种情况下，我们验证吞吐量受到单个FFR快速路径线程的限制(第5.2节)。通过将一个CPU内核分配给FFR并在两个内核之间平衡RDMA请求负载，可以轻松消除这一瓶颈。虽然我们保留这个选项，但是开发人员通常不希望使用小消息来满足整个带宽。相反，对于小消息，开发者通常关心的是延迟。

延迟:我们分别测量发送64B、256B、1KB和4KB消息的延迟。与吞吐量基准测试一样，这两个容器运行在通过同一个ToR交换机连接的不同主机上。对于每个消息大小，我们测量延迟1000次。我们绘制了中间值、第10和第99百分位潜伏期值。

图12:用1MB报文测量吞吐量时，ib发送bw和FFR的CPU利用率。100%CPU意味着CPU核心得到充分利用。

图13:自由流可以精确控制容器中的通信流

我们演示了6中提到的速率限制器的性能。在图13中，我们在InfiniBand测试平台上的不同主机上的两个容器之间启动一个单独的流。我们限制流量，并设置不同的带宽上限，从1Gbps到40Gbps。我们看到受控带宽(y轴)接近我们设置的带宽上限(x轴)。FreeFlow只需要6%的CPU开销就可以实现这个目标。

自由流可以使用速率限制器来隔离不同容器的性能(即吞吐量)。为了证明这一点，我们在容器对之间运行10个并发流，并对每个流应用不同的速率限制(从1到10Gbps)。我们确认每个流量的吞吐量是一个准确的上限。

8 . 1 . 4 RDMA的传输控制协议套接字

启用虚拟RDMA还可以提高基于套接字的应用程序的性能。下面说明FreeFlow在rsocket(现有socket to-动词翻译层)的帮助下，提供了比传统TCP/IP虚拟网络更好的性能。

实验在InfiniBand和RoCE集群上进行。通过在运行时动态链接rsocket，应用程序套接字调用被透明地转换成RDMA动词调用。我们运行iperf [10]来测量tcp吞吐量，NPtcp [14]用于TCP延迟，无需对这些工具进行任何修改。我们将其与运行在虚拟和主机模式网络上的相同工具进行比较。

图14:不同主机上的一对容器之间的TCP吞吐量和延迟。我们将本机TCP与freeflow+r套接字(套接字到动词的转换)进行比较。

如图14所示，FreeFlow总是比Weave好。特别是对于小消息延迟，FreeFlow始终低于主机TCP/IP，高达98%。对于吞吐量，由于套接字到动词转换的开销，FreeFlow有时比主机TCP更差，并且它不能像最初的RDMA那样实现完全吞吐量。不过还是比使用大消息的Weave大6.8到13.4倍。

这是FreeFlow性能好的两个原因。起初，RDMA栈和FreeFlow架构只能在用户空之间工作，避免了内核TCP栈中的上下文切换。这个优势不是唯一的；自定义用户之间的网络栈空也可以达到这个目的。FreeFlow优于Weave的第二个原因是根本。现有的TCP/IP虚拟网络解决方案执行从虚拟网络到主机网络的逐包地址转换。然而，FreeFlow执行从虚拟连接到物理连接的基于消息的转换。因此，FreeFlow总是优于Weave，尽管rsocket引入了一些套接字到动词的转换开销。

8.2真实世界应用

在这一节中，我们将演示TensorFlow和Spark的性能，这两个是在容器中运行的具有代表性的机器学习和数据分析框架。将FreeFlow的应用性能与主机RDMA、主机TCP和Weave进行了比较。

TensorFlow需要我们的RoCE集群没有的GPU，所以我们在InfiniBand集群上运行所有的实验。基于微基准测试，我们相信如果配备GPU，RoCE集群也会有类似的趋势。

8.2.1张量流

我们在InfiniBand集群中的三个服务器上运行支持RDMA的TensorFlow(1 . 3 . 0版)。我们修改了TensorFlow的一行源代码，并用我们定制的内存分配器替换了原来的内存分配函数(第4.3节)。每台服务器有8个NVIDIA gtx1080ti GPUs。其中一个服务器是主节点和参数服务器，另外两个服务器是工作服务器。我们为深度学习运行两种主要类型的训练工作量，即基于卷积神经网络的图像识别(CNN)和基于递归神经网络的语音识别(RNN)。

图15:自由流上的张量流性能。

对于图像识别，我们运行三个特定的模型，ResNet-50 [29]，initiation-v3 [42]和AlexNet [33]。我们使用合成图像网络数据作为训练数据。图15(a)显示了具有10百分位和99百分位值的每秒训练速度中值。根据三种不同模型的结果，我们得出结论:首先，网络性能确实是分布式训练的瓶颈。主机RDMA与主机TCP相比，主机RDMA在训练速度上的表现提高了1.8到3.0倍。容器盖上的FreeFlow和Weave之间的间隙较大。比如在AlexNet上FreeFlow的运行速度提高了14.6倍。其次，FreeFlow的表现非常接近东道主RDMA。差别不到4.9%，FreeFlow有时候甚至更快。我们推测这是由测量噪声引起的。

对于语音识别，我们运行一个私有的语音RNN模型，它由一个双向编码器和一个完全连接的解码器层组成，隐藏层维数为1024，词汇量为100k。数据集大小为4GB，包括1860万个样本。在每个训练步骤中，GPU从一个小块中“学习”，并相互通信以实现同步。图15(b)示出了在每个训练步骤中花费的时间的CDF，包括GPU时间和网络时间。同样，FreeFlow离主机RDMA很近。中值训练时间比Weave快8.7倍。

8.2.2火花

我们在两台服务器上运行Spark(v2.1.0)。一台服务器运行一个主容器，用于在从容器上调度作业。两台服务器都在运行依赖容器。Spark [18]的RDMA扩展是由闭源实现的。我们从他们的官网下载了二进制文件，没有任何修改。

图16:自由流动时的火花性能。

我们演示了Spark发行版中包含的基本基准——group by和SortBy。每个基准测试运行262，144个键值对，值为2 KB。我们将火花映射器和减速器的数量设置为8个，每个都是一个线程。图16显示了结果。我们总结了类似于运行张量流的观察结果。网络性能确实会显著影响应用程序的端到端性能。用FreeFlow运行，性能非常接近在主机RDMA上运行，优于主机TCP，比用Weave运行容器高1.8倍。

第九章相关工作

容器中的RDMA虚拟化:Mellanox试图在Linux内核中扩展网络命名空间和cgroup，以适应RDMA的网络隔离[34，35]。使用MACVLAN将物理接口分成多个虚拟接口，在每个容器中插入一个或多个接口，并依靠VLAN路由将流量传递到正确的虚拟接口。显然，它在云环境下会有可移植性问题，因为移动IP意味着在硬件上更新VLAN路由。此外，它不能提供灵活的可控性，因为它允许容器直接访问物理网卡。

另一种方法是使用可编程硬件来处理容器的RDMA虚拟化，如智能网卡[26]或现场可编程门阵列[38]。与基于硬件的解决方案相比，FreeFlow具有使用商用硬件降低成本和更灵活地定制网络功能的优势。

虚拟机的RDMA虚拟化:HyV [39]是最接近FreeFlow的解决方案。它还拦截应用程序和网卡驱动程序之间的通信，并提供地址转换、QP/CQ映射和内存映射。HyV和FreeFlow的主要区别在于，HyV在私有集群中不控制数据路径提供裸机性能，而FreeFlow适合云环境。这给FreeFlow带来了更多挑战，例如在保持数据路径中应用程序透明的同时，保持性能接近裸机质量。VMM旁路输入/输出[37]的设计和问题与HyV相似。VMware一直致力于对名为vRDMA的RDMA设备进行半虚拟化[40]。VRDMA是为VMware的虚拟机管理程序和虚拟机设计的，所以它本身不适合容器。

第十章结论

本文介绍了一种虚拟RDMA网络解决方案——自由流，它可以提供容器云所需的隔离性、可移植性和可控性。自由流对应用程序是透明的，可接受的开销实现了接近裸机的RDMA性能。使用实际应用和微基准测试的评估表明，FreeFlow能够支持与裸机RDMA相当的性能，优于现有的TCP/IP虚拟网络解决方案。我们开源了FreeFlow的原型。

如需参考，请查看原始链接，原始地址:https://www.usenix.org/conference/nsdi19/presentation/kim

-完毕-

更精彩的，请关注微信Clustar2018，谢谢。