转载

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. 本文纯属个人观点，请自由拍砖，但本人仅关注在文章中技术层面存在严重失误的拍砖。