前言 NSDI 2019 里有两篇容器网络相关的话题，这篇还是比较有意思的，the morning paper 也谈到了这篇文章：https://blog.acolyer.org/2019/03/22/slim-os-kernel-support-for-a-low-overhead-container-overlay-network/。原版的视频、Slides、文章在 NSDI 官网都可以看：https://www.usenix.org/conference/nsdi19/presentation/zhuo。同时作者在 Github 上开源了实现：https://github.com/danyangz/Slim 大致思路是容器里的应用的流量送到另一个容器里的应用需要经过四次协议栈。 除了底层物理机的协议栈之外，主要是有一层 network namespace： 因此主要思路就是绕过这一层 stack，其效果还是不错的： memcached 吞吐提高 71%，延迟降低 42%，CPU 占用减少 56% Nginx CPU 占用减少 22-24% PostgreSQL CPU 占用介绍 22% Kafka CPU 占用减少 10% 介绍 容器网络往往使用 overlay 网络，但是 overlay 网络会带来显著地性能影响。测试显示 overlay 网络和 host 网络相比的吞吐会下降 23~48%，每个报文的延迟会增长 34~85%，CPU 占用会提高 93%，现有的加速技术往往是针对虚拟化的，对容器支持不够。 这里的核心问题就是一个包要在一个物理机上穿越两次协议栈，来回就是四次。这种设计显示受虚拟化的影响，因为虚拟机是有自己的协议栈的，宿主机不知道任何 Guest 的协议栈知识，但是容器不然，宿主机知道每个网络连接的完整信息。 因此作者设计了一种容器网络，核心思想就是让一个物理机上报文只经过一次协议栈。 这个设计有几个挑战： 网络虚拟化不能要求应用作出修改 […]

这篇文章是 MIT 6.824 课程安排的一篇阅读材料。 我 Fork 了别人整理的 MIT 6.824 的课程材料，关于这篇文章的内容可以在这里找到：https://github.com/MatheMatrix/MIT-6.824-Distributed-Systems/tree/master/Lectures/LEC04 下面是笔记。 摘要 VMware 在 2010 年发布了这篇文章，主要描述它们在 vShpere 4.0 上实现的虚拟机高可用方案，这是一个商用的、企业级的方案，虚拟机性能下降在 10% 以内，虚拟机同步需要 20M 左右带宽。文章提到让这样一个系统支撑企业应用除了复制虚拟机的指令外，还有很多其他问题。 介绍 实现高可用的基本思路是主备，主备最简单的想法就是复制主的所有状态，包括 CPU、内存、IO。但是这个方案无疑需要非常大的带宽。 另一种方法是复制状态机思路，简单的说，这个思路就是把虚拟机当作一个确定状态机，两边先保持一个一致的初始状态，然后保证它们能够一样的顺序接收一样的指令。因为总有一些操作造成的结果不是确定性的，因此还需要额外的工作来保持同步（主要是内存）。 这个思路在物理机上无疑很难实现，但是在虚拟机上就好做很多，因为虚拟机就是一个定义的很完善的状态机，其所有操作、设备都是虚拟化的。但是相比物理机，虚拟机自己也有一些非确定性操作，例如读取时间和发送中断，这就是为什么我们刚才说需要额外操作来保持同步。 VMware vSphere FT 基于确定性重放（deterministic replay），但是增加了必要的额外协议和功能来保证系统功能完整。到写这篇文章时，FT 生产版本还只能支持单 CPU 虚拟机，因为对多 CPU 来说，几乎每次读写共享内存都是非确定性操作，由此带来巨大的性能损失。 这个系统的设计目标只处理 fail-stop 错误，也就是系统一旦出错则立即 stop，而且正确的服务器立刻知道它 stop 了。（分布式系统中的各种错误可以参考：http://alvaro-videla.com/2013/12/failure-modes-in-distributed-systems.html, fail-stop 几乎是最简单的错误类型) FT 设计 首先我们将备份虚拟机运行在一个和主虚拟机不同的物理机上，备份虚拟机与主虚拟机保持同步和一致但有一个很小的时间差，这时我们称这两个虚拟机处于 virtual lockstep。 两个虚拟机的虚拟磁盘位于共享存储上（例如 FC 或 iSCSI，后面会讨论非共享存储的场景），只有主虚拟机会在网络上对外通告，所以所有网络输入只会进入主 […]