论文阅读 Docker Based Overlay Network Performance Evaluation in Large Scale Streaming

摘要

用docker在以spark为基础的流程序上使用了两种network modes进行实验。为了获取更好的成果，我们为了从host和overlay网络模式测试不同的方面的表现，设计了一个实验系统。通过我们的工作，我们发现host模式比overlay模式快了大约8%，同时，overlay模式更加稳定。我们引入变化系数来看每个包的传输等待时间的不同，发现overlay模式比host模式好了50%。因此overlay模式更适用于高质量的网络需求，比如说视频会议。在另一方面，我们要求更快的传输时间，最好选择host模式。

介绍

docker能保证每次运行的code， runtime， 系统工具，系统库都相同。Virtual eXtensible Local Area Network (VXLAN)被用来解决overlay network在虚拟数据中心里创建多租户的需求。这个体系和相关协议能用于云服务提供商和企业数据中心的网络方案中。
本论文在大数据场景下，讨论运行大数据主要组件Spakdocker服务下的网络链接情况。发现host模式和overlay网络模式都能从功能上解决这些网络连接问题。然后设计一系列实验比较他们的优点和缺点。在最后，通过分析实验数据，我们总结适用于host和overlay的场景。

背景

我们创建了一个典型的大数据场景去研究不同的配置下的spark对整个流计算系统下的性能的影响。整个系统的架构如下图。

在使用docker部署spark服务的时候，spark服务之间的不能正确的连接，原因是桥连接的网络模式无法正确的发现各自的私有的容器Ip地址，于是改成host网络模式。这种模式解决了spark在docker里面无法连接的问题。


然后发现了第二个问题，使用overlay网络模式。他们能在私有的虚拟网络里面发现对方。

根据overlay的本意，性能尤其是传输性能应该很糟糕，为了量化并且找到其他特性，我们设计以了一个比较host模式和overlay模式性能的实验。

为了不必要的损耗，用了每个组件都是单节点，并且仅仅是传输一个时间戳的数据。如图5

比较运行时间删除了第一段的时间。

使用变异系数来评判网络情况。 公式如下：

x就是公式1中的值。网络抖动是网络性能的关键特征，它反映了各个包之间传输延迟的差异，这对于视频会议等业务非常重要。最后给出了基于spark流引擎的流计算。为了更全面的观察，我们选择了spark中四个不同批次大小的窗口作为控制实验。

实验评估

实验平台

使用阿里云服务器，配置如下

由于评估的重点是主机模式和覆盖网络模式之间的差异，所以所有关键组件都部署在独立模式下。只有一个Kafka代理来转发生产者生成的消息。Spark集群由一个master和一个worker组成。而Redis没有复制功能，简化了系统，消除了同步带来的干扰。

结果

在实践中，我们选取了4个批次大小分别为50 ms、200 ms、600 ms和1000 ms作为研究案例。在每个批大小中，我们对主机模式和覆盖模式都做了三次。每次我们向流媒体系统推送100万条数据记录，并为每个记录标记三个时间戳。然后取公式1和2，就可以知道每次平均传输延迟和网络抖动程度。最后，我们使用三次实验的平均值作为最终分析数据，如表2所示。

首先比较传输延迟从表6可以得出host模式比overlay模式平均快7.88%，最高达到11.19%。由于覆盖协议的复杂性，该数据是合理的。同时不管是host模式还是overlay模式，用大的窗口表现更好，图6还显示了两种网络模式下传输延迟的差值比，当50ms的窗口大小时比例相对较低，到200ms时差值最大。增加到600ms以上窗口大小时，差异相对稳定。

然后分析网络抖动情况，从图7中，很明显，overlay的变异系数小于host模式50%以上。变异系数与批处理大小如传输延迟关系不大。

讨论

在Spark流中，数据是小批量处理的。批处理大小决定同时处理的数据量和响应时间。随着批处理规模的增大，可以隐藏传输延迟，更有效地处理数据。更大的批处理规模也会导致慢响应，这在实时数据处理系统中是至关重要的。因此，在批量大小的选择上总是要进行权衡。上述评价可作为确定合适批次大小的依据。在图6中，随着批处理大小从50 ms增加到600 ms，传输延迟可以显著降低。因此，对于没有严格要求响应时间的系统，可以将批处理大小设置为500 ms左右。
稳定性或可预测性在大数据系统中也非常重要。如图7所示，overlay网络可以帮助降低传输延迟的方差。在这样一个常规的系统中，可以更快地发现故障。在这样一个准时系统中也可以进行一些高级的优化。在大数据计算中非常常见的大规模系统中，使用overlay网络可以更有效地管理连接，减少外部干扰。

相关工作

容器在云计算中变得越来越流行。关于Docker的性能评价，特别是docker的研究已经有了很多。在[9]中，比较了虚拟机和linux容器的性能。结果表明，在几乎所有情况下，容器的性能都优于vm。在特定的计算场景中进行了一些性能比较。在[lO]中评估了docker和kvm等几种轻量级虚拟化技术的性能。这项工作的重点是基于云的PaaS的性能和隔离。在[11]中分析了基于容器的高性能计算虚拟化的性能。实验结果表明，所有基于容器的系统在CPU、内存、磁盘和网络等方面都具有接近于本机的性能。在[12]中，分析了110绑定应用程序在基于容器的虚拟化集群上的性能。与非虚拟化环境相比，评估显示虚拟化集群的命中率提高了6%，响应时间降低了21.4%，吞吐量降低了3.88%。
前面的工作重点是比较基于容器的虚拟化和非虚拟化。一些研究分析了各种虚拟化技术之间的差异。但是它们缺乏对基于容器的虚拟化的不同模式的深入分析。本文在大数据场景下，分析了主机网络模式和覆盖网络模式的性能。由于网络在分布式计算中起着至关重要的作用，本文的评估可以指导大规模数据处理系统的设计和部署。

总结

实验数据表明，覆盖网络虽然降低了10%的性能损失，但提高了网络传输的稳定性。因此，当处理延迟敏感的工作时，主机模式是首选。然而，当我们需要像在线视频服务这样更稳定的网络时，覆盖效果更好，可以将服务质量提高50%以上。下一步，我们将扩展研究工作负载，以查看Docker中的主机模式和覆盖模式之间的更多差异。