全面解析Google Cloud的云网络设计

小提示：您能找到这篇{全面解析Google Cloud的云网络设计}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的全面解析Google Cloud的云网络设计内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

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

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

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

< font-size: 16px;">设计目标

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

< font-size: 16px;">1、控制平面的可扩展性和隔离性：

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

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

< font-size: 16px;">2. 数据平面的高性能和隔离：

< font-size: 16px;">数据平面的高吞吐和低延迟，同时要考虑多租户的场景避免一个租户抢占其他租户的网络带宽和其他资源。

< font-size: 16px;">3. 可高速迭代：

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

< font-size: 16px;">下面将介绍控制平面和数据平面分别是如何设计来满足这些目标的。

< font-size: 16px;">控制平面

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

< font-size: 16px;">1、Preprogrammed Model：

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

< font-size: 16px;">2、On Demand Model:

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

< font-size: 16px;">3、Gateway Model：

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

< font-size: 16px;">可以说这三种模式都有各自的问题，GCP 采用了一种结合 Gateway 和 On Demand 的动态路由楼盘宣传片卸载模式，并称其为 Hoverboard 模式。这种动态路由卸载模式是基于网络流量模式几个统计学的发现：

< font-size: 16px;">83% 的 VM 之间从来没有网络通信；

< font-size: 16px;">98% 的 VM 之间的网络吞吐量峰值小于 20kbps；

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

< font-size: 16px;">

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

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

< font-size: 16px;">数据平面

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

< font-size: 16px;">数据平面的很多工作和 OVS-DPDK 做的类似，例如 Userspace Datapath，Busy Polling，无锁队列，无系统调用，Hugepage，Batch Processing 等等。比较有特点的是在 HOST Datapath 中，依然采用了冷热分离的两个 Datapa如何危机公关th 进行数据处理。

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

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

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

< font-size: 16px;">

< font-size: 16px;">Fast Path 和 Coprocessor 之间的交互类似流表和 ovn-controller 之间的交互。对于特定的数据包在 Fast Path 中插入一条上传给 Coprocessor 的规则，Coprocessor 处理完后再交还给 Fast Path 进行处理。

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

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

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

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

< font-size: 16px;">参考资料：

< font-size: 16px;">https://www.usenix.org/conference/nsdi18/presentation/dalton

< font-size: 16px;">https://www.usenix.org/conference/nsdi18/presentation/firestone

< font-size: 16px;">GCP网络系统Andromeda https://zhuanlan.zhihu.com/p/102951479