通向企业级的 OPENSTACK 网络服务

前言

当我们提到 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:“ ✔*”表示支持有限，非全部支持，或数据可能不明确。

注3:MidoNet建议使用某厂家的交换机，但并非绑定。