GCP 网络系统Andromeda --- 控制面

2020-07-01 00:00:00 虚拟 网络 主机 转发 交换机

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

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

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

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

Andromeda的控制面由三层组成：

  • Cluster Management层：这是用户接口层，接收用户请求来创建网络，存储，计算资源。这一层是整个GCP通用，并非网络专有。
  • Fabric Management层：这一层向Cluster Management暴露API，通过接收用户或者管理员的请求，来完成虚拟网络的配置。
  • Switch 层：这一层与数据面（dataplane）有一定的重合，由两类软件交换机组成。类是每个虚机所在的主机都有的，基于Open vSwitch的，虚拟交换机。这一类软件交换机用来处理当前主机上虚机的网络数据。第二类是运行在Hoverboard上的虚拟交换机，这一类软件交换机作为所有网络流量的默认路由器，如前一章所述，用来处理idle和long-tail流量。

如前一篇所述，GCP由多个Cluster组成，每个Cluster有一套独立的Fabric Management层和Switch层。Cluster Management层统一管理多个Cluster。Cluster Management层其实没什么好说的，接下来具体看看下面两层。下图包括了这两层的具体组成部分。

Fabric Management层

从上图可以看出，Fabric Management层有三部分：

  • Fabric Management API对接了Cluster Management，通过API保持了Cluster Management和Fabric Management这两层的数据同步。API层根据不同的Controller暴露不同的API。目前的Controller有控制虚机所在主机和Hoverboard的VM Controller（VMC）和控制Load Balancer的Load Balancing Controller。谷歌发布的文章只介绍了VMC。
  • VMC将从Cluster Management同步过来的数据，转译成OpenFlow能理解的数据，通过RPC发送给OpenFlow Front End（OFE）。为了确保不同虚拟网络的变更不相互影响，VMC为每个虚拟网络都维护了独立的队列，来处理相应的更新消息。
  • OFE将这些数据终翻译成OpenFlow规则，下发到Switch中。

OFE负责连接VMC和虚拟交换机。举个例子，当一个虚拟交换机连接到OFE，OFE会将这个消息上报给VMC。VMC进而通过OFE比较虚拟交换机当前的额状态，下发相应的更新操作，完成虚拟交换机和VMC之间的数据同步。VMC+OFE这样的架构，可以将SDN controller（VMC）与交换机解耦。从而使得VMC的变更，例如升级或者重分区（后面介绍）这些操作，不会影响到交换机的转发。

Switch层

尽管Switch Layer有两类软件交换机，分别运行在虚拟机所在的主机和Hoverboard上，但是这两类软件交换机底层使用了同一套高性能的包处理架构（谷歌自己开发，在第三篇介绍）。主机上软件交换机的控制层部分，采用的是一个修改版本的Open vSwitch。虽然是修改版本，但是并没有改变Open vSwitch的基本工作方式。Open vSwitch有一个用户态进程vswitchd，负责接收从OFE发来的OpenFlow规则。当数据面不能完成转发的时候，会将网络packet发送给vswitchd。vswitchd通过查找自身的OpenFlow规则；生成数据面的cache数据；向dataplane下发cache数据，终将网络packet重新注入到数据面。因为这时以及之后的时间里，数据面已经具备了转发的cache，因此可以完成packet的转发。

Switch层还包括另一个管理进程：Host Agent。它负责监听虚拟机的生命周期，例如创建，删除，迁移。当一个虚拟机创建时，Host Agent会在Open vSwitch中为虚拟机的每一块网卡创建一个virtual port，并把这个virtual port连接到虚机交换机。Host Agent同样会上层程序中，虚拟机和virtual port的对应关系。

分区管理

为了支撑大规模和高可用，在每个cluster中，所有的主机根据一致性hash的结果分成多个分区，每个分区总共三VMC，通过Chubby-elect方式选出一主两备。当一个软件交换机连接到OFE，OFE会将这个事件广播到所有的VMC分区。根据hash结果对应的VMC分区，会保持与该软件交换机的数据同步，包括接收交换机的事件，下发转发信息等。

下图是一个带有3个VMC分区的cluster架构示意图：

控制面数据下发

传统物理网络极度依赖IP地址与物理位置绑定，以及IP地址聚合来提升控制面的规模和性能。而Andromeda（以及其他大部分的SDN方案），解耦了物理网络和虚拟网络。这带来了很多的好处，例如为虚拟网络灵活的分配地址，在物理设备中任意迁移虚拟机，但是却不能应用传统物理网络提升控制面规模和性能的方式。

通常来说，一个SDN系统的控制面数据下发有以下三种方式：

  • Preprogrammed Model：控制面向所有的交换机下发所有虚机的转发信息，构建所有虚拟机之间的full-mesh转发信息。这种模式提供了一致的和可预测的性能，但是缺点是：
    • 控制面的负担随着虚拟网络规模呈平方增长
    • 虚拟网络中的任何变化都需要通知到在这个网络中的每一个节点。
  • On Demand Model：每一个网络数据流的个packet送到SDN controller，controller收到packet后下发所需要的转发信息。这种方式比Preprogrammed性能更好，但缺点是：
    • 每个网络流的个packet的时延会明显增大。
    • 这种模式极度依赖控制面，一旦控制面出现故障，新的网络连接将不再能建立。
    • 增加了控制面的不安全因素，因为无意的或者恶意的大量报文上送controller会使得控制器负担过重甚至crash。可以通过上送的限速来缓解这个问题，但是同时多个租户间的隔离和公平性也很复杂。
  • Gateway Model：虚机将所有的网络报文发送给专门的gateway设备，gateway设备被设计用来做高速的包处理。这种模式提供了可预测的性能，同时对控制面要求也较低，因为虚拟网络的转发信息和变化只需要通知少量的gateway设备。但这种模式也有缺点：
    • gateway数量与虚拟网络的规模正相关，因为更大的虚拟网络，对应更多的流量，需要更多的gateway。
    • gateway需要为峰值流量做好准备，而峰值流量可能是平时流量的100倍。因此，很难有效的利用gateway。

如何合理的下发控制层信息一直是SDN做到大规模的一个难点，可以看出，上面的三种方式没有一种是完美的。而GCP/Andromeda要面临的问题是在一个数百万虚拟机规模的虚拟网络中，维护转发信息的正确性。新的Andromeda使用的是一种结合了Gateway Model和 On Demand Model的方式，它被命名为 Hoverboard Model。

首先与Gateway Model一样，Hoverboard作为Andromeda的gateway节点，具有所有虚拟网络的转发信息。虚拟机的packet，如果在主机上没有找到转发信息，主机会将packet发送给Hoverboard节点。因为有所有的转发信息，Hoverboard可以完成转发。到此为止，与Gateway Model是一样的。

同时，Andromeda的控制面程序会动态探测虚拟机的网络流量，一旦超过特定的阈值，例如20kpps，控制面会向主机上的虚拟交换机下发转发信息。之后的该网络流的packet，将直接从源虚拟机所在的主机发向目的虚拟机所在的主机，绕开Hoverboard（从Hoverboard offload）。Andromeda将主机之间直接转发的规则称为offload 规则。如下所示。

从上面可以看出，Hoverboard Model中，重要的部分是虚拟机网络流量的探测。从健壮性考虑，Andromeda并没有使用来自Hoverboard的流量报告，因为当Hoverboard负担过重的时候，它不一定能发出相应的报告，控制面也就不能下发offload规则以减轻Hoverboard的负担。Andromeda使用的是主机上的流量报告，来评估是否下发offload 规则。

可以说，这种方式有点tricky，我还从专利库中搜到了Google为此方法申请的专利。www2.soopat.com/Patent/

这种方式具有优势的前提是：虚拟网络中只有少量的虚拟机之间会有大量网络通信，比如说A，B，C，D都在虚拟网络中，A只与B之间有大的网络流量，C只与D之间有大的网络流量。这样，只需要在主机上下发A到B，C到D的转发规则即可。

实际中，Andromeda团队在一个GCP的生产环境中，观察了一个有40K虚拟机的虚拟网络30分钟内的网络流量。84%的虚拟机之间没有通信，这部分虚机之间的转发信息完全没有必要下发到主机。再把条件放宽一些，98%的网络流量的峰值吞吐小于20kbps，因此offload 阈值设置为20kbps。这样只需要下发相比Preprogrammed Model下 2%的转发规则到主机即可，控制面的性能和规模提升了50倍。

Andromeda 1.0使用的Preprogrammed Model，多支持一个虚拟网络2k 虚机。之后版本的Andromeda使用了Hoverboard Model可以支持一个虚拟网络100k虚拟机。在Hoverboard Model下，一个新的虚机只需要在其所在的主机和Hoverboard节点完成转发信息的更新，就具备整个网络的连通性。而在Preprogrammed Model下，需要在虚拟网络所在的所有主机完成更新。相比Preprogrammed Model，Hoverboard Model的更新耗时中位数从551ms下降到184ms，PCT99从3.7s下降到576ms。

在一个1万台主机规模的cluster中，测试下发一个40k虚拟机规模的虚拟网络。Hoverboard Model下，VMC需要下发总计1.5M条转发信息，耗时1.9秒，单个VMC分区高消耗513MB内存。而Preprogrammed Model下，VMC需要下发总计487M条转发规则，耗时74秒，单个分区峰值内存消耗10GB。下图是虚拟网络规模和下发转发信息需要时间的对应关系：

当使用Hoverboard模式时，转发信息的下发时间与虚拟网络尺寸成正比O(n)。当使用Preprogrammed模式时，时间是O(n*h)，其中n是虚拟网络尺寸（虚拟机数量），h是虚机分布在的主机的数量。当h 到达机器总数时，Preprogrammed Model需要的时间与虚拟网络尺寸也成正比。当虚拟网络尺寸超过40k之后，Preprogrammed Model因为大量的转发规则，导致OFE和vswitchd的连接出现稳定性问题。

Hoverboard Model之所以能带来提升，是因为它将大部分的idle和long-tail流量通过Hoverboard节点转发。在一个生产环境，Hoverboard的throughput与offload规则的数量如下图所示：

通过将50k的转发规则下到主机（offload规则），Hoverboard gateway的峰值吞吐可以控制在集群总吞吐量的1%以内。

从数据上来看，Hoverboard Model优势很明显。并且这是一种基于实际经验数据得出的优化。

虚机Live Migration

因为Andromeda为虚拟机采用的是软件虚拟网卡，所以相比SR-IOV方案，在迁移上的阻力就小很多。虚拟机在Live-Migration过程中，会现在Pause住，之后再目标主机恢复执行，这个时间在GCP上的中位数是65ms，PCT99是388ms。除了这个时间，还有就是转发信息的更新时间。Andromeda早期专注在一个物理L2网络内迁移，这样可以减少转发信息更新的延时，在一个GCP全局做Live-Migration，挑战在于全局的转发表更新会比较慢。因此在迁移的过程中，Andromeda会在迁移的源主机打开hair-pin。源主机会将所有发往需要迁移的虚机的入方向流量复制一份转发给迁移的目的主机。这样，就算全局的转发表没有更新，目的主机仍然能收到相应的流量。全局的转发表更新之后，虚机主机和Hoverboard都更新了相应的转发表，相应的packet可以直接发送到目的主机。相应的，迁移源主机上的hair-pin规则会被删除。

限定错误域

为了构建全局的控制面，限定错误域非常重要。Andromeda控制了GCP全局的虚拟网络，所以一个cluster的控制面会收到来自其他所有cluster的事件。所以一个region的错误消息可能会影响到其他的region。为了解决这个问题，Andromeda将控制平面分成了RACP（Regionally Aware Control Plane）和GACP（Globally Aware Control Plane）。RACP负责region内的网络连通性，只接收本region的消息。GACP负责region间的网络连通性，它接收来自本region和其他region的消息。这样可以确保每个region的网络是一个独立的错误域。

另一方面，每一层控制面都被设计成允许出错的且不会相互影响。例如当所有的VMC不可用时，主机上的虚拟交换机可以继续使用残留的转发信息完成转发。甚至主机重启都会保留转发信息，这样就算VMC都不可用，且主机重启了，也不会造成断网。

相关文章