SDN & OpenStack 漫谈（下）

之后 1 年的时间，其实也就是业界各类开源 SDN 解决方案陆续出现的阶段，OpenContrail、Calico、OpenDayLight、ONOS、Midonet、OVN、Neutron DVR、Dragonflow 等。之后我的更多的精力就放在了真正能处理生产环境问题的 SDN 解决方案上。

1. OpenContrail

当时，OpenContrail 的横空出世，确实是 SDN 业界的一颗重磅炸弹。记得该项目刚开源，就开始评估和测试。OpenContrail 确实是一个非常专业的 SDN 解决方案，其架构并无 SPOF，用 MPLS VPN 实现了隔离，包括在那个时候率先设计并实现了基于 Policy 的服务链定义，非常值得学习。不过最终还是放弃跟进，原因如下：

（1）其软件框架纯粹是 Juniper 设计并实现了，没有任何指导开发的文档（门槛确实较高）。

（2）其转发面模块 vRouter 是 Juniper 设计并实现的 Linux 内核模块，虽然只是简单的查询和转发数据包，但当时在 Mailing List 上也有公司测试出有 crash 的现象。当时我特地发消息给社区，建议社区尽量把内核态模块提交给 Linux Upstream，保证代码质量。毕竟 datapath crash 的后果可想而知，没有稳定性，谈何性能。

（3）开源社区并不开放，这个是大多厂商主导的开源社区的通病。

（4）毕竟在创业公司，很难依靠个人之力去维护一套庞大的没有文档的开源系统。

（5）听说当时国内 Juniper 并无对应的技术支持团队，就算企业愿意购买商业版本，也需国外远程支持，说明 Juniper 并没有很好去建设针对企业的服务体系，连企业级支持都没，风险挺大。

这些都是很早之前的评估了，之后 OpenContrail 这个产品发展越来越好，包括也看到其和 Mirantis 合作落地了一些项目，不过还都是以 Contrail 商业版本为主。

2. Calico

这个开源项目是比较有趣的针对 Neutron SDN 的方案，当时投入了一些精力在其开源代码上，受到了很大的启发。Calico 设计的思路其实非常简单直白，它在每台计算节点上安装了一个 BGP Speaker，通过软件实现了 Virtualized L3 Fabric。然后在架构上又引入了 BGP Reflector 解决 full mesh 的问题。虽然 API 是用的 Neutron，但是大多 Neutron extension 都没有实现，也不好实现，它是 Flat Network 的解决方案，当前还不支持 Overlapping-IP，最多实现个安全组、但是完美支持了 IPv6，其架构和 Nova-network multihost 模式更为接近，而且由于其控制平面基于 BGP，计算开销小并且运行可靠，运维成本低，所以在我眼里，他是 Neutron 版本的 L3-based multihost 模式。这个项目设计更多是考虑数据中心网络架构，把 Neutron 的虚拟网络与现实世界的 DCN 实现了整合，是大规模企业级私有云的一个可靠的解决方案。

3. OpenDayLight

OpenDayLight 是一直在跟踪的项目，它是基于动态模块系统构建的插件式网络操作系统（SDN-OS），是我见过的功能最为强大的 SDN 平台（没有之一）。从架构角度，它是纯粹地利用了 Java OSGI 框架实现了一个动态模块系统，各个网络服务模块（无论是南向 plugin 还是北向 plugin）都可以进行热部署，这对于生产环境运维是极大的帮助，因为整个 OSGI 框架不变的基础上，每个网络服务都能做到独立升级和修改，并且动态生效，不影响平台稳定性。而且它设计并实现了南北向交互的服务抽象层（AD-SAL 和 MD-SAL），大大方便了定制开发。唯一的问题在于 AD-SAL 和 MD-SAL 本身，OpenDayLight 项目最早是实现了 AD-SAL，其很多成熟的模块都是基于 AD-SAL 开发的，但是之后，发现设计的 AD-SAL 存在扩展性和代码重用的问题，就重新借助 Yang 模型设计了 MD-SAL，然后希望逐步把 AD-SAL 实现的模块重写变成 MD-SAL 的，费时费力，当前应该还是存在两个不同的 SAL 框架，建议新的插件都以 MD-SAL 为主开发。OpenDayLight 还初步实现了集群功能，基于 Akka 框架实现集群，并且也设计了支持分布式内存数据库，但是其扩展性我没有评估过，不妄下判断。从社区发展角度讲，其代码核心是 Cisco 实现的，之前确实担心 Cisco 独裁，但是目前整个项目全部由独立的基金会操控，包括代码贡献上，Ericsson、Intel、Brocade、Huawei、ETRI 等公司和组织都在持续贡献，而且该开源项目已经纳入了 Linux 基金会的合作项目。从功能实现的角度讲，OpenDayLight 是我用过的第一个纯粹的网络操作系统，兼容并包各类网络技术，包括 OpenFlow1.0 和 1.3、OVSDB、BGP、LISP、Netconf、PCEP、SNMP、OpenDove 等，可以做到统管整个 DCN（数据中心网络基础架构），从上层服务上，提供了包括虚拟多租户、服务链、有线电缆通信服务（DOCSIS）、OpenStack Neutron 服务接口等模块。与 OpenStack 的对接仅仅是其众多应用中的一个，相信其在数据中心网络领域、NFV 领域，乃至三网融合领域，都会取得良好的发展。

最新版本是 Lithium，在这个版本中，第一次看到了完整的使用文档和开发文档，这也是我评价一个开源项目是否值得跟进的一个重要指标（本人痛恨开源社区耍流氓）。目前其案例更多来自 DCN 领域，包括华为和 Brocade 都有基于 OpenDayLight 的数据中心解决方案产品对外在销售，而腾讯的数据中心网络优化，也在使用 OpenDayLight，说明其生产化已经成为可能，但从我的角度讲，确实需要一个专业的网络技术团队作为服务支撑才行。OpenDayLight 生产环境运维，以及基于 OSGI 模型的二次研发，都是需要投入一定的成本的。 当前 OpenDayLight 与 OpenStack 的整合，也在按部就班的进行，并且完全跟随着 OpenStack 社区的研发脚步，完整提供了 ML2 Plugin 和一部分 Service Plugin。话说，Neutron 前 PTL Kile 就是 OpenDayLight 粉，并且在多个公共场合极力推广整合解决方案。

4. ONOS

ONOS 是另一个庞大的开源网络操作系统，它的设计的目标和实现的功能几乎和 OpenDayLight 完全相同，得到了 ONF 组织的大力支持（OpenFlow 标准制定者），是 OpenDayLight 唯一的市场竞争对手（目前两个项目都在试探性地开展技术合作，竞合关系值得期待）。其发展滞后于 OpenDayLight，代码主要由 Huawei、ETRI、 ON.Lab 等公司和组织参与贡献，公司数目和质量还不及 OpenDayLight（Huawei 在开源道路上战略很明确，使用人海战术不放过任何一个可能的发展方向）。它的技术架构都和 OpenDayLight 类似，也是通过 Yang 模型定义其抽象层对象，集群实现的发展从使用 Zookeeper、 Hazelcast 到最后听说选择了 Raft，由于我没有尝试使用过和分析过该系统源码，对其技术不妄下判断，但是从其对 OpenStack 的支持力度上看，还只是 Demo 阶段，似乎 Plugin 也没有完善，希望能尽快看到整合方案，并且从其官网的宣传上看，落地的生产项目也几乎没有。

5. Midonet

Midonet 是去年下半年开源的企业级 OpenStack SDN 解决方案，也是我介绍的主流方案中唯一一个全球范围内认可的企业级解决方案，毕竟这个是人家 Midokura 公司卖了 2 年的产品，非常成熟，提供了完整的 OpenStack 网络解决方案。从架构上讲，第一次将分布式 SDN 控制器的概念落地，使用了 Zookeeper 和 Cassandra 作为持久化存储方案（网络拓扑数据库），其控制器分布在每一台计算节点上，实现了一个纯分布式的控制平面，管理接口通过 Restful HTTP Server 实现，数据平面利用了 Openvswitch datapath，通过分布式路由实现东西向的流量调度，通过 BGP 发布外网网段，是一个没有 SPOF 的解决方案，更加精妙的是，其流表的下发完全使用 Proactive 模型，其安全组和防火墙是基于 Ingress Filtering 的设计方案，大大降低了数据网络的无效流量，其还存在一个简单的防 DDoS 模块；另外它实现了 Virtual Single Hop，虚拟网络内任意两点间均只存在单跳。所以从架构、性能、稳定性上，Midonet 都是最适合大规模生产环境使用的 SDN 解决方案，并且已经得到了 OpenStack 业界权威 RedHat 和 Mirantis 的认证支持。但是，它也不是完美的。第一，和 OpenDayLight/ONOS 不同，Midonet 仅支持 OpenStack 和 VMware，无法脱离 OpenStack 和 vSphere 单独使用；第二，其虽然开源，但是从 governance model 看，完全是掌握在 Midokura 公司手里，并且没有指导开发的技术文档（其在 Github 上的开发文档都是完全落后于其当前代码设计的，我在阅读源码过程中发现大量无效内容，让我莫名走了很多的弯路）；第三，它的技术堆栈主体是基于 JVM 的 Scala 语言，任务管理框架基于 Akka，在云计算技术中比较冷门，一般需要较长的学习周期才能适应这门函数式编程语言及其框架。 当然，我和 Midonet 的核心开发人员以及社区管理员都进行过多次面谈和电话交流，他们承诺会尽自己努力构建一个完善的开源生态，希望他们能越走越开放。

6. OVN

OVN 这个项目之所以会抛出，就是因为发现 Neutron 并不适合于作为完整的 SDN 控制器使用，仅适合作为整个虚拟网络层的北向应用（定义 API 接口）。 （就如我之前说的，专业的系统让专业的人去开发，OpenStack 社区做好应用层和生态的管理就行了）。最终，因为 OVS 在那个时候就已经成为 de facto，具有一定的话语权，所以这个社区也就承担了为 OpenStack 设计并实现一套能大规模生产化使用的网络系统的任务。从技术架构讲，这个项目最初的设计就是参考了 Midonet（当时 Midonet 已经得到了大家的注意），但是由于 OVS 社区是基于 C stack 的，所以架构虽然类似，但却更多利用了已有的 OVS 代码进行改造，比如它的数据持久化方案，完全借助其已经在使用的 OVSDB-server 作为全局的网络拓扑数据库和本地状态存储；部署架构上，每台计算节点上都部署了 ovn-controller 作为本地 SDN 控制进程负责 OpenFlow 和 OVSDB 的通信。从产品成熟度来讲，毕竟这个是一个全新刚起步的方案，当前还仅仅实现了和 Neutron ML2 的对接，依照它的 Roadmap，明年初就可以完善对接到 Neutron ML2 Plugin+Service Plugins，并且实现分布式路由；另一个方面，OVSDB-server 是一个不支持 HA、Cluster 的单点 NoSQL 数据存储系统，所以除非 OVN 引入更可靠的分布式系统，比如 Zookeeper、Cassandra、Raft，否则肯定无法生产环境使用。还是希望 OpenStack 东京峰会能有更多利好的消息，以及待到明年开始具体进行测试评估工作。然后从社区角度讲，毕竟和 OVS 同源，所以确实是一个值得期待和信任的方案，但是由于其设计初就绑定了 OpenStack，所以和 Midonet 类似，无法扩展到非 CMS（云管理系统）的应用场景。另外，这个项目的核心推动者之一，还是 Neutron 前 PTL Kile，看来他对 Neutron 当前实现怨念很深啊。

7. Neutron DVR 和 Dragonflow

这两个项目是当前 Neutron 社区设计并实现的分布式路由解决方案，专门解决东西向流量的问题。

（1）DVR

这个是 Neutron 最初的分布式路由方案，由 HP 主导，将 L3-agent 管理的网络拓扑分布到所有的计算节点上，看似很牛，实则纯粹就是个玩具。为什么那么说？因为首先，它的设计并没有创新，而是将整个 L3 的控制和转发面复制到了所有的计算节点，确实开发省心省力，并且设计之初就没有考虑其他高级网络服务对 L3Router 的依赖，导致兼容性问题；其次，运维复杂度上升不止一个数量级， 针对虚拟路由器所定义的本地状态（tap, veth peer, router namespace, flow table 等等）原本仅分布在某几台网络节点（L3-agent）上，现在却分布在所有的计算节点上，看似没有了 SPOF，但运维难度并没有降低；然后也是最让人郁闷的是，整个 BP 的推动到代码的编写充斥着不确定性，一方面代码的实现并不优雅，实现过程中都是硬生生地嵌入 Neutron 已有的代码中，之后再发现问题，提交大量的重构去满足 DVR 的落地；该功能的代码写完提交给社区进行测试后，才发现原来和社区已经存在的 L3 HA、甚至与存在了 1 年多的 L2pop 均有兼容性问题；单元测试和功能测试用例极其不完善；每个 Release 都曝出各种 High Level 的 Bugs，据统计大于 30+，所以就如我之前说的，给 HP 和 Review BP 的人狠狠点赞，各种刷 Commits 和 Reviews 的机会啊。最后从 SDN 技术发展的角度上说，DVR 的推动是 Neutron SDN 的退步，它虽然解决了东西向流量集中路由的问题，但是在 packet tracing 没有可靠工具的前提下，不仅其增加了 datapath 的复杂度，间接导致增加了运维的复杂度，提高了企业网络运维的隐形成本，与利用 SDN 技术降低 OpEx 的初衷相反。

（2）Dragonflow

这个是 Neutron 社区之后推动的第二个分布式路由方案，完全由 Huawei 主导，OpenFlow Reactive 的设计思路，利用纯流表实现的分布式路由，设计比 DVR 优雅太多，我也没有时间去做测试评估，但是从设计文档看，确实非常清晰，但由于一方面该项目参与的开发者并不多，另一方面项目起步也比较晚、到目前社区 CI 系统还没能支持该项目的集成测试，所以当前是否能直接上生产，我持保留意见，反正东京峰会快要举行了，在峰会上应该会有一些确定的结论。最后要说明 Dragonflow 只是替代 L3-agent 的方案，包括与 FWaaS、VPNaaS 的兼容性问题，更重要是首包上送的性能，还有待生产环境去考证。所以，和 DVR 一样，它的应用范围实在有限，不是一个完整的 SDN 解决方案。

8. 本文纯属个人观点，请自由拍砖，但本人仅关注在文章中技术层面存在严重失误的拍砖。

作者简介

马力，海云捷迅（AWcloud）架构师，关注领域：大规模云计算架构、数据中心基础架构、SDN、OpenStack，Email： mali@awcloud.com