☰

多主机 VM/Docker 网络通信很慢，有什么最佳实践吗？

tag-icon • tag-icon linux networking virtual-machines docker latency
多主机 VM/Docker 网络通信很慢，有什么最佳实践吗？ 
VM-1 on host-1 <[cable]> network router <[cable]> host-2 with VM-2

如果我理解正确的话，在文件从 VM-1 上的应用程序传输到 VM-2 上的相同应用程序时，数据将经历以下过程：

  • VM-1 应用程序文件读取到内存缓冲区
    • 编程语言相关的调用
    • 操作系统级调用
    • seccomp/apparmor 逻辑
    • 文件系统权限逻辑
    • 操作系统文件处理和缓冲区
  • VM-1 应用程序数据发送到网络套接字缓冲区
    • 操作系统调用
    • seccomp/apparmor 逻辑
  • VM-1 操作系统网络堆栈
    • 路由表
    • 防火墙逻辑
  • Host-1 虚拟机管理程序虚拟网络堆栈
    • 虚拟交换机
    • 路由表
  • Host-1 操作系统网络堆栈
    • 路由表
    • 防火墙逻辑
  • Host-1 物理网卡缓冲区
  • 网络路由器
  • 主机 2 上的 VM-2 镜像的堆栈几乎相同

假设文件很大，那么对于已打开和传输的文件，与 seccomp/apparmor、路由和防火墙相关的步骤将被缓存/省略。

但如果虚拟机之间频繁通信，且消息短到可以装入 1-2 个 TCP 数据包中，我们就会遇到问题

每次调用和逻辑处理都需要几百个 CPU 滴答，而所述的过度堆栈将对 CPU 造成很大的负担并导致延迟。

问题

  1. 虚拟机之间预先打开的通信套接字是否会省略所描述列表中的任何步骤？
  2. 做南达科他州如何以某种方式缓解此类问题，或者是否会在数据包中添加更多覆盖和额外的标头？
  3. 我是否真的需要描述在 VM-1 和 VM-2 之间进行通信的过程，或者是否存在一个特殊的 Linux“不太安全、更高性能、使用风险自负”的构建？
  4. 我是否必须坚持使用 Linux？有没有更快的 *BSD 类系统支持 docker？
  5. 有哪些最佳实践可以缓解该瓶颈，从而在同一主机上安装更多具有微服务的虚拟机？
  6. 解决方案如下Calico 项目有帮助还是更多是关于较低级别的？

答案1

虚拟机之间预先打开的通信套接字是否会省略所描述列表中的任何步骤？

由于 TCP 握手开销，虚拟机/容器之间预先打开的套接字将会发挥作用；如果有 TLS，效果会更好。

尽管人们普遍认为握手开销可以忽略不计，但当我们谈到频繁通信时，它就开始发挥重要作用。

对于网状容器网络，拥有 M x N 个打开连接的边界状态并不是很明智。基于您自己的容器通信统计数据的 TTL 简单保持活动解决方案会更好。

请记住，过多的线程保持 TCP 连接处于活动状态会导致另一个开销，因此请确保使用 epoll。

SDN 是否可以以某种方式缓解此类问题，或者它是否会在数据包中添加更多的覆盖和额外的报头？

它确实增加了更多的覆盖，许多是供应商锁定的，但至少有一个管道 SDN下面介绍有关Docker环境的相关解决方案。

我是否真的需要描述在 VM-1 和 VM-2 之间进行通信的过程，或者是否存在一个特殊的 Linux“不太安全、更高性能、使用风险自负”的构建？

我没有找到具有足够值得信赖的社区和更新支持的“特殊”Linux 版本，但 Linux TCP 堆栈速度慢的问题并不是什么新鲜事，而且有很多内核旁路选项。Cloudflare 就是这样做的。

从我找到的文章，慢速的 Linux TCP 堆栈是众所周知的，并且没有选项可以放入 Linux 服务器并获胜：您必须每次都对 Torvald 的孩子进行微调以这样或那样的方式解决您自己的问题。

我是否必须坚持使用 Linux？有没有更快的 *BSD 类系统支持 docker？

没有发现任何证据表明 Windows、MacOS 或 *BSD 类系统的网络性能比最新的 Linux（采用慢速 TCP 堆栈并应用内核旁路）更好。

有哪些最佳实践可以缓解该瓶颈，从而在同一主机上安装更多具有微服务的虚拟机？

因此，存在两个瓶颈：Guest Linux 和 Host Linux。

对于主机 Linux，如果它不仅用于容器托管，则有一个内核旁路策略，其中包含多种选项，如Cloudflare 博客和“为什么我们使用 Linux 内核的 TCP 堆栈？”文章编写您自己的以应用程序为中心的 TCP 堆栈。

对于客户 Linux麦克维伦可用于绕过第 3 层，并将 Docker 容器直接连接到具有其自己的 MAC 地址的 NIC。比桥好多了，因为它可以缓解很多客户机和主机 Linux 网络瓶颈，但请确保您已准备好用另外一百或一千条记录来扩展您的路由器 MAC 地址表 - 很可能您必须对网络进行分段。

也按照虚拟交换技术及Linux网桥介绍有一个 SR-IOV 选项比 Macvlan 更好。它是适用于 Mellanox 以太网适配器的 docker 1.9+作为插件，作为模式包含在管道 SDN，专门Clear Containers 的 SRIOV 插件- 足以开始挖掘以应用为中心的解决方案。

像 Project Calico 这样的解决方案有帮助吗？还是它更适用于较低级别？

这完全是另一个层次，与 SRIOV 和 Macvlan 相比不会产生显著影响，但它们有助于简化网络管理，并且几乎没有您选择的旁路解决方案的开销。

是的...

密切监视您的 Docker，因为它可能会做出意想不到的事情。例如，它会在无缘无故打开 Macvlan 的情况下执行modprobesnf_nat和，这会导致额外的 CPU 时钟开销。xt_conntrack

相关内容