文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

在这篇文章中,我将回顾下Docker多主机网络的性能。

在之前的文章中,我测试了下Docker网络MySQL服务器团队提供他们自己的测试结果,它与我的观察一致。

对于这组测试,我想更多的关注Docker网络在多主机环境上的情况。因为大多数情况下我们会建立一个高可用(HA)环境(例如使用Percona XtraDB集群)并期望所有实例运行在不同的主机上。

测试的另一个原因是Docker最近发布的1.12版本,它支持原生的Swarm模式。原生Swarm模式本身是相当有意思的—在这个版本中,Docker的目的是在更深入业务流程部署领域里与Kubernetes和Apache Mesos竞争。我不得不说Swarm模式当前比较粗糙(首次发布发布的原因),但我相信Docker将会在接下来的几个版本里打磨这个功能。Swarm模式也期望你的服务可以运行在不同的物理主机上,并且服务

第 1 段(可获 2.05 积分)

Swarm 模式也期望能够使你的服务运行在不同的物理主机上,并且服务之间通过Docker网络通信。

网络性能对于集群是相当重要的比如Percona XtraDB集群和 MySQL组复制(它是另一个项目的实验室版本)。

下面是我的配置,我使用了两台物理服务器并且通过一个10GB的网络相连。两台服务器使用总共有56个核心的英特尔CPU。

到内存,并且我只使用主键查找。通过测试在最坏的情况下的网络通信,同时也在良好情况下的性能作为参考对比。

第 2 段(可获 1.53 积分)

以下是Docker网络选项:

  • 不使用docker容器 (在后面的结果中标记为 “direct”)
  • Docker 容器使用 “host” 网络 (标记为 “host”)
  • Docker 容器使用 “bridge” 网络, 通过端口转发暴露服务端口(标记为 “bridge”)
  • Docker 容器使用 “overlay” 网络, 客户端和服务器都是在容器启动并通过覆盖网络连接 (在结果中标记为 “overlay”)。对于“overlay” 网络它有可能使用第三方插件,它们有不同的网络实现,最为人所知的是:

对于多主机的网络设置,只有“overlay”(和其插件实现)是可行的。我使用“direct”, “host” 和“bridge” 只是用来做参照,作为比较法来测量overlay实现的开销。

我观察到的结果如下:

第 3 段(可获 1.68 积分)

观察发现

  • “Bridge” 网络增加了开销, 大约有12%, 这符合我之前的检测。然而,我想知道这到底是Docker的开销还是桥接网络的Linux实现的开销。Docker 应当使用的是我在 同台主机上使用Linux网络命名空间运行Percona XtraDB 集群节点文章中描述的配置,并且我怀疑是Linux网络命名空间和桥接增加了开销。我需要做更多的测试来验证这点。
  • 原生的“Overlay” Docker网络还在性能问题中挣扎。我观察到了一个ksoftirq在一个单核cpu占用100%的问题,并且我看到过类似的报告。看起来是因为不能合理的分配多个cpu而导致的Docker “overlay”中的网络中断。这种情况在“direct” 和“bridge”配置下不发生。我相信这是一个 Docker “overlay” 网络的问题(希望它最终将解决)。
  • Weave 网络的表现非常的糟糕。我看到很多的CPU分配给了“weave” 的容器,因此我认为在他们的实现中有严重的可扩展性问题问题。
  • Calico插件在多主机容器上表现的最好,甚至要好于“bridge-bridge” 的网络设置
第 4 段(可获 2.29 积分)

结论

如果你需要用到Docker “overlay” 网络模式—当你在多主机环境部署或是使用Docker Swarm模式时它是硬性需求—我建议你考虑使用docker下的Calico网络插件来代替。 原生Docker “overlay” 网络模式可以用在原型或是快速测试用例中,但是当前它在高端硬件上还有些性能上的问题。

第 5 段(可获 0.78 积分)

文章评论