ArchSummit干货分享：通向企业级的OpenStack网络服务

写在前面的话

在周六落幕的ArchSummit深圳站上，Unitedstack有云的网络工程师王为进行了关于OpenStack网络的主题演讲《通向高可用与分布式的OpenStack网络服务》，对OpenStack的网络发展做了一个综合性的总结和比较，也解答了对于OpenStack网络复杂、Neutron难维护、Overlay网络性能低下的疑问。

前言

当我们提到 OpenStack 的网络，很多人会望而生畏，说OpenStack网络好复杂、Neutron难以维护、Overlay网络性能低下…… 这样的印象阻碍了OpenStack特别是Neutron在企业的部署脚步，事实上从OpenStack诞生起，其网络的模型和设计就一直在进化并且保持着高效、快速的迭代，特别是从Neutron诞生Legacy网络、Provider网络、L3 HA、L2 Population、DVR、DragonFlow相继提出，我们看到Neutron在其每一个Cycle都在向企业级的生产软件靠近，该篇文章将尝试对OpeStack的网络发展做一个综合性的总结和比较。

从Nova-network说起

我们知道最初OpenStack只有Nova和Swift两个组件，所以Nova除了提供基础的计算服务，包括调度、块设备和网络也一并由 Nova 提供，当时的网络是什么样呢？为什么现在还有很多Superuser还在使用Nova-network？

最开始，大家期望中的OpenStack网络是什么样的？

• 1.能给虚拟机提供 IP 地址；
• 2.虚拟机在需要时可以连通外网；
• 3.相同网络下的虚拟机之间允许内部通信；
• 4.一些虚拟机还希望能获得一个外网 IP 来对外提供服务。

最后特别对于公有云，租户间还需要保证网络隔离。

基于以上需求，Nova-network 提供了这样的参考模型（VlanManager+MultiHost）：

首先，dnsmasq 进程绑定在租户的网桥上，用于提供DHCP服务，提供IP地址；然后，计算节点上配置默认路由并将一个网口连接至公网，这样虚拟机按默认路由发送的报文将被网桥以节点的默认路由送出，发往公网的接入层；同一租户的网络处于同于 Vlan，通过网桥广播允许其互相通信；不同租户的虚拟机如果则通过节点上的路由表路由到对应网桥并转发（见上图）；如果虚拟机需要公网IP，则可以在计算节点上直接起 NAT 规则对应到相应内网IP。

整个模型很简单明了，全部使用Linux中较为成熟的网络技术， 所有路由选择由本地决定，不依赖某个单点，这个在Nova-network中被称为MultiHost，是Nova-network的重要特性，所以其一出世就获得了很多人的青睐。

但是Nova-network的缺点也是很明显的：

• 1.因为Vlan技术固有缺陷，一个Region下无法服务太多租户；
• 2.路由实现粗糙，路由决策和NAT依赖IP地址，所以很难实现Overlap IP，用户的IP管理不自由；
• 3.前面说不同租户（其实是不同网络）之间似乎可以在没有公网IP的情况下互香通讯，但这是有条件的，再看前面的图，我们看到如果想在计算节点下做路由决策，让数据包成功封装另一个租户的Vlan，我们需要这个计算节点拥有另一个租户的网桥，而且因为这个链路的非对称性，对方节点也需要相同的要求。因为Nova-network的网桥是按需建立的（不然太多），所以其实这种通信是无法保障的。

最后，Nova-network提供的网络高级功能很有限，只有基本的安全组，很难满足用户需求，而且将网络紧耦合在计算服务中也不符合云计算的架构，所以社区最终成立了Neutron项目。

Neutron的艰难前行

Neutron的诞生承载着大家对面向大型云基础设施的网络服务的期望，它在一开始就着手设计了基于Overlay网络的网络模型，通过先进的VxLan和NVGRE协议，Neutron克服了很多在Nova-network中无法解决的网络问题。Overlay网络是什么的，简单的说，它是一个逻辑网，运行在物理网之上，一般要求物理网IP可达，然后通过UDP等三层传输协议承载二层，形成L2 over L3的模型，这样我们就可以实现突破物理拓扑的任意自定义网络拓扑、Overlap IP等。

首先针对Nova-network面临的几个问题，VxLan、NVGRE等都支持上千万的租户数量，远远满足一般需求；其次通过L2 over L3，用户完全实现了自定网络拓扑，没有IP地址的限制；不同网络间拥有不用的VxLan tag，当需要在不同网络下互相通信时，可以通过路由器路由转换VxLan tag，不再有种种限制。

针对Nova-network的高级功能匮乏的问题，借助灵活的网络模型和虚拟路由器的实现，Neutron拥有自定义路由、VPNaaS、FWaaS和LBaaS等多种高级功能。此外，由于Neutron 定义良好的北向接口和Plugin-extension架构，它可以支持大量厂商的设备，用户拥有彻底的自主选择权，厂商拥有高度的自主开发空间。

既然我们说的这么好，为什么很多人对其都不满意呢？原因也很多：

• 1.Neutron 使用了Namespace、Open vSwitch、网桥、veth、iptables等技术，其中有些内容，特别是OVS对很多人都是比较陌生的，而且在一开始，其稳定性也受人质疑，这让人们有了充分的质疑理由；
• 2.南北向通讯和跨网络通讯都依赖于网络节点，而这个节点在默认的模型下是单点。
• 3.Overlay网络的默认性能并不能让人满意，需要专业工程师或厂商设计方案和调优。

软件的复杂度随着软件功能的丰富和接口的复杂性的上升几乎是必然的，Open vSwitch的稳定性和性能也一直在提升，所以社区决定要发动力量主要解决第二个问题。

首先是HA，企业IT系统首先关心的，莫过于系统的稳定性，一个可靠的HA方案是社区首先考虑的。很多网络服务的高可用都是借助VRRP协议的，Neutron也不例外，通过 Keepalived + conntrackd，实现Master和Slave共同维护VIP，一旦Master挂掉了，VIP将自动飘到Slave节点上，因为conntrackd始终在自动拷贝session信息，所以理论上可以实现用户的无感知自动切换。

L3 HA确实实现了高可用，但是东西流量还是没有优化啊，这里面一大原因是VxLan本来支持组播的，但是OVS目前支持有限，我们总是不得把一些无效的ARP广播发送出去。比如说下图中，A的广播包其实只对3和4有用，但是2和5也收到了：

如何优化，这里的问题是虚拟机不知道通信对方的位置，可是 Neutron 知道啊，Neutron 数据库中保存着每一个 Port 联接的虚拟机信息、其 IP、MAC 地址、其宿主机信息等等，所以如果有新的虚拟机建立起来，连接了网络，那么 Neutron 就往所有 Agent 发送消息，告诉他们新的 Port 的所有信息，大家就低头检查看看自己是不是也有这个网络的虚拟机，如果有就更新流表规则，将来要请求这个 IP 的 ARP 可以直接回应，如果没有就忽略。这就是 L2 Population 和 ARP responder。

OK，更加优化了一步，但是他也有问题啊，就是

• 1.因为消息是广播的,很耗费资源；
• 2.跨网络的通讯还要依赖于路由器；
• 3.它目前没办法和L3 HA共同工作！

为什么它无法和L3 HA共同工作呢，因为 L2 Pop 假定了每个 Port 都工作在一个固定的节点上，这样L2 Pop才能将ARP 和Tunnel引过去，然而L3 HA破坏了这个假设……Bug的report见Launchpad上的#1365476，目前尚未解决……

新的架构

这么说来，Neutron在企业化道路上真实困难重重啊，怎么办，社区决定不能在旧的架构上修修补补了，让我们真正实现一个分布式虚拟路由（Distributed Virtual Routing简称DVR）吧！

由于过去的集中化的虚拟路由L3 Agent实现的很完整了，社区决定方案就是将其从单独部署在网络节点转为分布式的部署在所有计算节点上，每个计算节点都有自己的Router Namespace，就像之前Nova-network在各个节点上都有自己的Gateway一样。

首先我们看虚拟机绑定公网 IP 情况下的公网流量：

当一个外部的报文需要和虚拟机通信时，首先会发到网桥br-ex，然后FIP Namespace的fg设备响应其ARP，再被路由到fpr 上，进入DVR Namespace，这里再通过iptables将公网IP DNAT为内网地址，发往虚拟机。内部网外部通信也是类似的道理。

对很多用户来说，南北流量不是他们最关心的问题，他们最关心的是东西流量：

因为现在路由器就在计算节点上，所以我们只需要在Namespace内完成路由就行了，这和以前在网络节点上是一样的。但是会出现多个计算节点上会存在同一子网的网关，怎么办？解决方案是为每一个计算节点生成唯一的DVR MAC地址，在对外发出数据包之前，将原有MAC替换成DVR MAC，保证双向通信的正常进行。

OK，我们解决了问题，但也引入了新的问题：

• 1.因为现在ARP应答无法跨计算节点，像Allowed address pair这样的扩展也无法工作了（回应非Port自己本身绑定的IP的 ARP请求）。
• 2.IO路径比较复杂，且充斥着大量虚假ARP应答，增加了运维难度。

针对DVR的这些问题，社区另一拨人提出一种新的架构，他们称之为SDN way。那就是我们看到所有流表都是Neutron主动下发的，而不是像OpenFlow那样首包上送，我们能不能实现一个基于首包上送的反应式控制器呢？

于是DragonFlow被提了出来，其特点是未知流量首包上送到控制器，控制器知道一切，下发流表规则，这样东西向通信的其余流量就都可以都直接走到对方计算节点了。

比较有特点去谈的就是这个流表了：

但是这样控制器的性能会成为瓶颈吗？DragonFlow团队声称的性能提高真的可靠吗？恐怕无论DVR还是DragonFlow都还是需要真正生产环境的考验。

第三方的发展
前面说到因为Neutron的Plugin-extension架构，给了厂商良好的自定义空间，所以Neutron的第三方解决方案也是层出不穷，这里简单谈谈NSX与Midonet。

NSX改造自原Nicira的NVP，据VMware宣称其应用在了多家云计算系统中，但我们外界所知资料并不是很丰富，下面的图介绍了NSX对东西流量的处理，可见与DVR有相似之处：

其优点是拥有良好的商业公司支持，缺点是价格高昂、无法自主可控。

再说一个新秀Midonet，是Midokura公司提出的网络解决方案，与今年年中宣布开源，实现了很多企业级的特性，比如BGP的支持、Tunnel Zone、DoS抵御隔离的支持等等，但是对我们来说最吸引人的，是其基于Java重新设计的全新的软件架构。

Midonet 有几个组件，分别是

• Cluster：保存集群状态，同步信息，检查外部设备等，依赖于 Zookeeper 和 Cassandra；
• midonet-util：一些其它模块用到的工具类；
• midolman：类似于 Neutron 中的 Agent，
• midonet-api：实现 API；
• netlink：与内核通信用模块，基于 Linux netlink；
• odp：于内核的 Open Datapath 通信用模块。

Midonet 充分借助了已有成熟的分布式软件降低自己本身的复杂性，而且只使用了 Open vSwitch 的 Datapath 模块，使转发和控制更加灵活，不失为一个好的设计。但是其企业级服务还需要定制，对社区的部分高级功能也支持有限，这也是它的缺点。

总结

最后我们以一个表格做总结：

注1: NSX 价格还需要额外购买 SNS 支持服务，数据来自http://technodrone.blogspot.com/2015/02/vmware-integrated-openstack-cost.html

注2:“ *”表示支持有限，非全部支持，或数据可能不明确。

作者：王为，UnitedStack有云SDN 工程师，专注于虚拟网络和 SDN 方向，OpenStack 等多个开源社区的活跃贡献者。
转载自：UnitedStack有云