Google Cloud 的网络设计,googlecloud的网络设计-ESG跨境

Google Cloud 的网络设计,googlecloud的网络设计

Google Cloud 的网络设计

最近看了18年Google在NSDI上一篇介绍Google Compute Platform中整体网络设计的论文。这篇论文从GCP面临的大规模且变化频繁的网络挑战讲起，介绍了控制平面和数据平面的设计和改造。最终做到控制平面可以支撑单个网络100000 VM，数据平面以纯软件的方式做到接近物理网络的性能，吞吐量做到30Gb/s，单核pps做到了三百万。并做到了网络在线迁移，数据平面可以每周在线升级的高速灵活迭代。

相比于AWS所有网络功能下沉到专门的硬件卡，Azure使用专门的FPGA做网络加速，GCP只使用了Intel芯片的一些通用offload能力（encryption，checksums，memory copies）。流表查询，数据包转发，ACL,LB，NAT等功能都是纯软件实现的，基本可以认为是当前最大规模纯软件SDN实践了，当下容器大规模网络设计也可以从中借鉴很多思路。

由于GCP在主机的数据平面使用的是OVS，编程模型也用到了OpenFlow（当然都魔改了不少），阅读的时候免不了会和OVN做一下对比。下面会从GCP网络的设计目标，控制平面和数据平面分别进行介绍。

设计目标

该网络方案在Google的项目名为Andromeda，是仙女座星系的英文。仙女座星系是一个比银河系还要大的星系，可见这个项目的野心。Andromeda的主要设计目标有下面几个：

1.控制平面的可扩展性和隔离性：由于GCP是公有云，控制平面的稳定性和可扩展性是重中之重。包括支持单个网络100k VM，单个的网络变更需要在极短时间内同步到整个集群。目前OVN在这方面做得就不是很好，当VM超过10k，变更的延迟就到了接近分钟级别的水平。而Andromeda在100k规模的变更延迟是186ms。

控制平面的隔离性指的是对多租户的支持，避免单个租户的异常行为对其他租户的扰动。例如在某些机器学习场景下单个网络可能会瞬时provision 10k VM，其他租户的网络操作不能因为这个租户的突发请求而受到影响。

2.数据平面的高性能和隔离：数据平面的高吞吐和低延迟，同时要考虑多租户的场景避免一个租户抢占其他租户的网络带宽和其他资源。

3.可高速迭代：控制平面的可扩展性，数据平面的高性能以及多租户的隔离这几方面的需求是比较显而易见的。不过可高速迭代这个目标却是我读论文之前没想到的一个点。一般认为网络组建作为基础设施迭代周期会比较长，升级复杂度也会比较高。但是在GCP里数据平面可以做到每周进行线上更新，这样开发者可以告诉的迭代功能和性能优化，充分发挥了SDN的优势。作者在presentation上也提到不采用更多硬件加速方案的主要原因就是硬件无法做到纯软件网络的高速迭代。

下面将介绍控制平面和数据平面分别是如何设计来满足这些目标的。

控制平面

控制平面最重要的工作是把整个虚拟网络的拓扑规则下发给集群里的机器，可以理解为给每个机器一个地址簿，告知每一个VM的对应物理机是哪个，应该通过哪条路径找到对应的VM。传统的控制平面数据下发有Preprogrammed，On Demand和Gateway三种方式。

1.Preprogrammed Model：这种模型在我的概念中对应的是fullmesh模型。即每个宿主机节点都需要保存完整的集群网络拓扑，构建完整的转发地址簿。OVN目前采用的就是这种方式，集群中的每个节点之间都需要相互建立隧道，所有跨主机VM的数据包都是直接通过对应隧道发国际快递对端机器。这种方式的好处就是逻辑清晰明了，实现也相对简单。所有数据包都是分布式处理的，集群中的节点角色也很单纯。由于数据包直接发国际快递目标机器，没有额外的中转，理论上数据平面的性能也最好。缺点就是任何一个网络变更都需要更新所有节点的流表，更新的延迟会随着规模变大而迅速上升。此外每台机器都要维护全局的路由信息，额外的资源消耗也会随着规模变大而增加。

2.On Demand Model:这种模式下本机不保存全局信息，每个flow的第一个包要上传到控制器，控制器返回对应的路由信息。这种模式的扩展性比第一种要好，但是首包的延迟时间会显著上升。并且控制器成为了网络的一个瓶颈，控制器的故障可能会导致整个网络的中断。此外恶意的租户可能会利用这个机制生成大量的随机访问，对控制器进行DDOS攻击来影响其他租户的网络质量。

3.Gateway Model：只是一种在OpenStack中比较常见的网络模式，即使用专门的网络节点来处理数据包的路由。这种模式下宿主机端的逻辑大幅简化了，只需要知道关联的Gateway节点把所有数据包都转给Gateway节点就可以了。Gateway专门用来处理相应的路由更新逻辑。但是缺点是要消耗额外的资源，在不超售的情况下需要额外付出一倍的网络资源来处理网络数据。即使是进行了超卖，由于网络流量的变化会十分剧烈可能会有上百倍的波动，如何动态调度Gateway节点保证带宽也是很困难的事情。

可以说这三种模式都有各自的问题，GCP采用了一种结合Gateway和On Demand的动态路由卸载模式，并称其为Hoverboard模式。这种动态路由卸载模式是基于网络流量模式几个统计学的发现：

1.83%的VM之间从来没有网络通信

2.98%的VM之间的网络吞吐量峰值小于20kbps

也就是说网络的流量分布存在着明显的冷热不均，绝大多数的流量只出现在极少数的VM之间。经过计算可以得出2%的VM之间网络通信占据了99.5%的网络带宽。也就是说和full mesh模式相比，只需要本机保留五十分之一的路由地址簿就可以处理绝大多数的请求。而我们要做的就是找出那些热点的flow将规则加载到宿主机实现直接转发，而将那些长尾的基本没有流量的flow放在Gateway上来处理，减小宿主机的规则条数。

具体的处理流程如上图所示，vm x到z的流量最初都是通过hoverboard这个特殊的Gateway进行转发。在这个过程中宿主机会定期向VM Controller上报流量统计信息，Controller以20kbps作为阈值，考虑是否将对应路径的流表下发到主机。一旦x到z的流表下发到主机，x和z就可以直接通信而不经过hoverboard。

这种模式很巧妙的解决了之前提到三种模式的问题。相比fullmesh模式大幅降低了主机流表的规模，可扩展性得到了提升。相比On Demand模式降低了首包的延迟和控制器的压力。相比Gateway模式降低了额外的网络资源开销也提升了Gateway的处理能力。

数据平面

论文里主要介绍的是On HOST Datapath，也就是基于OVS的性能优化，其实我比较感兴趣的是hoverboard里怎么对长尾流量进行优化的，但是论文中没有介绍。

数据平面的很多工作和OVSDPDK做的类似，例如Userspace Datapath，Busy Polling，无锁队列，无系统调用，Hugepage，Batch Processing等等。比较有特点的是在HOST Datapath中，依然采用了冷热分离的两个Datapath进行数据处理。

在OVN中所有的数据处理逻辑包括转发，acl，nat，lb，arp reply，dns，dhcp都是通过一套流表组成的pipeline来完成的，好处是逻辑统一，缺点就是很难针对性的进行优化。这其中转发是最常见也是最关键的处理操作，而和其他功能混在一起来实现会拖慢转发的性能。

GCP中的做法是分成Fast Path和Coprocessor Path。Fast Path中只处理转发的操作，用到了上面所说的和OVSDPDK类似的所有比较极端的优化手段，做到了一个数据包平均只需要300ns进行处理就可以完成从VM网卡到物理网卡的操作。同时由于功能极为简单，flow table的查询更新也变得简单，无需像开源的ovs那样需要考虑遍历所有元组才能查询到规则。

而Coprocessor Path则没有这么高的性能要求可以做一些更复杂的功能和逻辑，这样可以将复杂的网络功能和简单的转发功能解耦，利于复杂网络功能的迭代，同时避免对整体性能产生大的影响。

Fast Path和Coprocessor之间的交互类似流表和ovncontroller之间的交互。对于特定的数据包在Fast Path中插入一条上传给Coprocessor的规则，Coprocessor处理完后再交还给Fast Path进行处理。

论文中还介绍到了数据平面的在线迁移，由于是纯软件的实现，可以做到在升级过程中同时运行新旧两个数据平面，旧的数据不断的往新的迁移，然后在某个时间点进行切换，这中间暂停服务的时间大约有270ms。通过这种方式他们做到了数据平面每周更新的高速迭代。

听说阿里云的网络部分现在也已经是硬件实现的了，这么大规模集群的纯软实现已经很少见了。看样子Google工程师对软实现在工程方面高速迭代的能力还是十分热衷的。不过这个论文在presentation的同期Azure也展示了他们用FPGA实现的数据平面，也可以通过编程的方式实现网络功能的快速迭代。此外Azure还很心机的做了个和GCP的性能测试比较来展示Azure在性能上的优势。不知道GCP的纯软线路还能坚持需要多长时间，毕竟从规模效应上来看，硬件方案性能好还能省CPU整体的性价比还是不错的。

再回过头来和OVN做个整体对比。GCP最大的特点就是在控制平面和数据平面各个层次都做了冷热分离，尽可能的优化常用路径的性能。而这种做法在实现上就会导致不同的情况下要用不同的方案，整体的实现会比较分散，但是针对单个公司的场景下能榨取尽可能多的性能。

而OVN为了保证整体架构的一致和逻辑的统一，没有这么碎的冷热分离和On Demand方案，通用性会更好，但是在大规模场景下会碰到性能瓶颈问题。当然OVN社区目前也在控制平面做了大量的性能优化，包括各种缓存和增量式更新，降低单个网络变更的消耗，目测20.03后的下一个版本还会有很大改善。而数据平面看上去在一些技术使用上和OVSDPDK的技术是一致的，不过GCP这种冷热分离，在线迁移的灵活性设计，在工程上还是很值得借鉴的。当然这两年又出现了更多的新方案，例如FPGA加速，各种智能网卡和eBPF的Kernel Bypass方案，都给数据平面的加速提供了更多的选择方案。

参考资料：

https://www.usenix.org/conference/nsdi18/presentation/dalton

https://www.usenix.org/conference/nsdi18/presentation/firestone

GCP网络系统Andromeda https://zhuanlan.zhihu.com/p/102951479

特别声明：以上文章内容仅代表作者本人观点，不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。