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

Question

VM-1 on host-1 <[cable]> network router <[cable]> host-2 with VM-2

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

• 读取到内存缓冲区的VM-1应用程序文件
  • 与编程语言相关的调用
  • 操作系统级调用
  • 分段/器件逻辑
  • 文件系统权限逻辑
  • 操作系统文件处理和缓冲区

• 发送到网络套接字缓冲区的VM-1应用程序数据
  • 操作系统调用
  • 分段/器件逻辑

• VM-1操作系统网络栈
  • 路由表
  • 防火墙逻辑

• 主机-1虚拟机监控程序虚拟网络堆栈
  • 虚拟开关
  • 路由表

• 主机-1操作系统网络栈
  • 路由表
  • 防火墙逻辑

• 主机-1物理网卡缓冲区
• 网络路由器
• 对于主机-2上的VM-2，镜像的内容几乎相同。

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

，但是如果虚拟机之间通信频繁，消息小到可以容纳1-2 tcp数据包，那么

就有问题了。

每个调用和逻辑处理都需要几百个CPU标记，所描述的堆栈将给CPU带来很大的负载，并在延迟中发挥作用。

• 根据测试码头多主机网络性能[2016年8月]，它的性能至少是-13%。
• 在VMware vSphere 5上的网络I/O延迟中，我们发现在空闲系统上，每个VM的往返延迟开销大约为15-20微秒。随着vSphere上的资源争用增加，这个数目会增加，这是预料中的。只要系统没有过度提交，抖动就很低。
• 此外，熔毁和幽灵英特尔修复将导致更多的性能下降。

问题

1. VMs之间的预开放通信套接字会在描述列表中隐藏任何步骤吗？
2. SDN是否在某种程度上减轻了这些问题，或者它是否为数据包添加了更多的覆盖和额外的头？
3. 我真的需要描述一下VM-1和VM-2之间的通信过程，还是有一个特殊的linux "less-secure-more-performance-use-on-your-own-risk“构建？
4. 我必须坚持使用linux吗？有任何更快的*BSD类系统与码头支持？
5. 有什么最佳实践可以缓解这个瓶颈，从而使更多VM与同一主机上的微服务相匹配呢？
6. 像项目Calico这样的解决方案会有帮助吗?或者更多的是低层次的解决方案？

Answer 1

Will在VM之间预先打开的通信套接字可以忽略所描述列表中的任何步骤？

由于TCP握手开销，VMs/容器之间预打开的套接字将起作用；如果存在TLS，则更多。

虽然人们普遍认为握手开销很小，但是当我们谈到频繁的交流时，它就开始发挥重要的作用。

在类似网格的容器网络情况下，具有M开放连接的边界状态是不明智的。基于您自己的容器通信统计信息的TTL简单的保持活力解决方案将更好。

请记住，保持TCP连接活动的线程过多将导致另一种开销，因此请确保使用epoll。

Does SDN在某种程度上减轻了这些问题，还是给数据包添加了更多的覆盖和额外的头？

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

我真的需要描述一下VM-1和VM-2之间的通信过程，或者有一个特殊的linux "less-secure-more-performance-use-on-your-own-risk“构建？Do >

我没有找到“特殊”的linux构建与社区和更新支持，但缓慢的linux TCP堆栈的问题并不是新的，还有许多可以绕过内核的选项。Cloudflare就是这么做的。

在我找到的文章中，慢速linux栈是众所周知的，没有任何选项可以插入linux服务器并获胜:每次您都必须微调Torvald的孩子来解决您自己的问题。

<#>Do我必须坚持使用linux吗？有任何更快的*BSD类系统的码头支持？

没有发现任何证据表明，与最新的linux相比，Windows、MacOS或*BSD类系统具有更好的联网能力，其缓慢的TCP堆栈采用了内核旁路。

What是缓解瓶颈的最佳实践，从而使更多VM能够在同一个主机上安装更多的微服务？

因此，有两个瓶颈:来宾linux和主机linux。

对于主机linux，如果它不仅用于容器托管，则有一种内核旁路策略，从Cloudflare博客和“为什么我们要使用Linux内核的堆栈？”文章中的反编译到编写自己的以应用程序为重点的TCP堆栈，都有各种各样的选项。

对于来宾linux，可以使用麦克夫兰绕过第3层，并使用自己的MAC地址直接将对接器容器连接到NIC。它是比桥牌好得多，因为它缓解了许多来宾和主机linux网络瓶颈，但确保您已经准备好用另外100或1000条记录爆炸您的路由器mac地址表--很可能您将不得不分割您的网络。

另外，根据虚拟交换技术与Linux桥接表示，有一个SR选项，这比Macvlan更好。它是适用于Mellanox以太网适配器的坞式1.9+ as plugin，包括在管道工程SDN中的一种模式，它有专门的来自透明容器的SRIOV插件 --足够开始挖掘面向应用程序的解决方案了。

像Calico这样的Do解决方案，或者更多的是关于更低级别的？

这完全是另一个层次，与SRIOV和Macvlan相比不会产生重大影响，但它们有助于简化网络管理，几乎不需要额外开销，您将选择旁路解决方案。

And是的……

密切监视你的码头工人，因为它可能会做一些意想不到的事情。例如，它对nf_nat和xt_conntrack进行了探测，在没有理由打开Macvlan的情况下，它会导致额外的CPU开销。