这个系列总共有三篇，分别在：

肖宏辉：GCP 网络系统Andromeda --- 概述篇

肖宏辉：GCP 网络系统Andromeda --- 控制面

肖宏辉：GCP 网络系统Andromeda --- 数据面

最近看了Google在2018年的一篇NSDI文章，介绍他们的数据中心SDN方案Andromeda，原文在[1]。最近计划用三篇，分别从概述，控制面和数据面，再结合一些自己的理解，介绍一下这个系统。这是第一篇：概述。

GCP（Google Cloud Platform）眼中虚拟网络

云计算的兴起给网络技术带来了新的机遇和挑战。对于Cloud中的常规三大服务，计算，存储，网络。对应网络部分，需要在具备高性能大规模能力的同时，也支持一系列的功能，例如LB，FW，VPN，QoS，Dos protection，隔离，NAT等等。更具体的来看，云环境中的虚拟网络，应该具备以下能力：

• 作为最基本的需求，需要为独立的用户提供隔离的虚拟网络。每个虚拟网络中的虚拟机运行在独立的私有IP网络中。对于这个虚拟网络，其中的虚拟机之间应该能相互通信；虚拟机与云环境中的公共服务（DNS，软件源等）能通信；虚拟机与外部第三方服务商能通信；虚拟机与互联网能通信。所有这些通信要受用户策略的控制，同时不同的用户可以使用不同的策略，达到不同的控制效果。另外，理想情况下，虚拟网络应该提供与underlay物理网相同的吞吐量和时延。
• 除了最基本的连通性，还需要支持持续的功能演进。随着时间的推移，一些新的功能会不停的添加进来，例如计费，DoS防护，性能监控，防火墙等，甚至架构也可能面临重大的调整，例如Andromeda就经历过从早期的OS kernel datapath迁移到了现在的OS kernel bypass的datapath。持续的功能演进不是难点，难点是演进的过程中，要使得虚拟机不受到影响。
• 云计算的一个好处就是相比普通的部署具备了更高的可用性，因为一整套的软件可控系统，可以很方便的provision，scale，migrate服务。所以虚拟网络的可用性，稳定性及其重要，在设计上也要小心考虑，尽量缩小系统的出错域（错误的影响范围）
• 为了满足上面两点，虚拟机的Live-Migration（热迁移）成为了必要条件。为了支持Live-Migration，虚拟网络需要确保迁移过程中packet仍然能传输，并且尽量较少网络性能下降的时间（迁移过程中网络性能下降在所难免，但是持续时间应尽量减少）
• GCP（Google Cloud Platform）成长的很快，表现在两个维度：GCP内虚拟网络的个数；每个虚拟网络中的虚机的个数，因此，网络控制面的性能变得非常重要。超大的云平台中，虚拟网络控制面主要有三个挑战：首先转发表更大（单个虚拟网络中虚机更多）；转发表需要被发布的范围更广（虚拟网分布在更多的主机上）；变化的频率更高

虚拟网络和SDN的研究和内容已经很多，比如高速的dataplane，分布式控制平面，各种虚拟网络功能，但是似乎并没有对于一整套端到端可用系统的研究。Andromeda，作为GCP的网络虚拟化系统，就是这么一个端到端的系统。

Andromeda架构

GCP有一套完整的管理系统，可以配置存储，计算，网络，权限等，而Andromeda是作为GCP管理系统中的网络部分存在。另一方面，GCP由多个cluster组成，一个cluster就是一批位置相近的物理服务器，它们具有相同的物理网络连通性，同时也有相同的物理网络错误域。Andromeda在每个cluster中都有一套独立的程序，这个在后面介绍。

本质上来说，Andromeda是一个SDN系统。所以，与其他的SDN系统一样，它包含了控制面和数据面。Andromeda的核心设计思想也很简单通俗：就是分层，包括了分层的控制平面和分层的数据平面。

控制面

Andromeda的控制面可以支持超过10W VM的虚拟网络，变更生效时间的中位数在184ms。并且操作一个用户虚拟网络，不会对其他虚拟网络造成影响。有关控制面的实现细节在下一篇详细介绍。

数据面

Andromeda的数据面由多层的datapath组成，根据所需要的功能和性能，网络流量被分配到其中一条路径。

• Host Fast Path：顾名思义，这个datapath运行在虚拟机所在的主机上。这是所有虚机packet看到的第一个datapath。它以牺牲灵活性为前提，提供了高性能的转发，目前可以实现300ns/packet的转发速度。为了达到这个数字，Host Fast Path被设计的只能简单的处理有限种类的packets。其他的packets被送到其他的datapath来处理。
• Host Coprocessor path：这个datapath也运行在虚机所在的主机上。Host Fast Path处理不了的packet被送到了Coprocessor path。这个datapath用来处理对CPU消耗较高，且对时延无要求的网络流量。同时也被用来实现网络功能，例如Stateful 防火墙，LB等。所有功能性的东西被放到Coprocessor path，这样可以让Fast path专心做高性能转发。
• Hoverboard datapath。Hoverboard是专门的gateway节点，这个datapath就是运行在这些节点上。理论上Coprocessor + Fast path应该处理所有的网络流量，但是为了提升控制面的性能和规模，不是所有的转发信息都会下发到主机。大部分的idle和long-tail流量，被送到Hoverboard节点，被Hoverboard datapath转发。

此外，Andromeda采用的是高性能、基于软件的底层方案，而不是类似于SR-IOV这种基于硬件的方案。使用硬件方案，可以很容易的得到与underlay物理网络一样的性能。但是相比之下，软件方案更加灵活，能支持更快速的功能迭代，能更容易的支持Live-Migration，因为SR-IOV需要考虑迁移前后不同的物理网卡的配置问题。除此之外，SR-IOV因为依赖硬件网络，会受到硬件表项的限制。对于一些网络功能，可能会引入额外的专用设备，进而增加网络转发的overhead。

最后，一个Cluster中，Andromeda所有的组件如下图所示，其中有一些已经提到过，有一些还没有提到，我们会在接下来的两篇具体的分析每一个组件。

[1] https://www.usenix.org/system/files/conference/nsdi18/nsdi18-dalton.pdf