这次介绍的两个SDN项目，虽然都是开源的，但背后都有一个商业版在售。

OpenContrail

OpenContrail背后的厂商是Juniper，在ODL创立初期，Juniper也曾经是ODL的会员，后来据说是不满Cisco把持ODL项目，退出了ODL。

OpenContrail前身是由来自谷歌，Cisco，Juniper的员工在2012年创立的创业公司Contrail Systems，同一年底Juniper就收购了这家公司，并在第二年将其产品作为自己的SDN产品。

OpenContrail本身是一个开源的SDN，同时Juniper也提供了一个商业版，两者提供的代码和功能是一样的，区别是商业版提供了更好的支持。OpenContrail的定位是支持Cloud Networking和NFV场景，是一个可扩展的SDN平台。

OpenContrail与Neutron的集成之前是作为OpenStack Neutron的一个plugin存在于Neutron代码中，在Neutron ML2重构之后，这部分代码被从Neutron中移除。现在是由Juniper在管理这部分代码。

OpenContrail有两大构成部分，Controller和vRouter。Controller是一个逻辑集中，但是物理上分散的SDN控制器。vRouter是一个转发平面的实现，它运行在计算节点上，为虚拟网络提供路由和转发功能。vRouter与OpenvSwitch很像，但是提供网络层和其他服务，也因此叫做vRouter（而不是vSwitch）。Controller对vRouter提供逻辑集中的管控。

OpenContrail Controller

这是一个逻辑集中的控制器。由三部分构成：

• Configuration nodes：提供REST api，将北向（northbound）数据模型转换成南向（southbound）数据模型，并存储在Cassandra数据库。Cassandra是一个高速的NoSQL数据库。
  
• Control nodes：实现了逻辑上集中的控制平面。Control nodes将southbound数据模型发送到各个vRouter或者物理网络设备，并从这些节点收集数据。
  
• Analytics nodes：将vRouter和物理网络设备的数据转换成northbound应用可以直接使用的数据。
  

这三类nodes都可以以active active的模式存在，这样既实现了HA，也方便水平扩展。

vRouter／Compute nodes

运行在计算节点（Compute nodes）上的转发平面。OpenContrail没有用OpenvSwitch，自己实现了一套转发平面。vRouter又可以分成两个部分。

• vRouter agent：运行在Linux中的进程。它的作用是：向上连接Control nodes和Analytic nodes，接收和上报数据；向下连接实际的转发层面（vRouter Forwarding Plane），下发和查询数据；为网络流量的首包下发转发策略，也就是在转发平面下发流表；代理DHCP, ARP, DNS, and MDNS等协议。出于HA的考虑，每个vRouter agent都至少连接两个Control nodes。
  
• vRouter Forwarding Plane：这是一个Linux系统中的内核模块。它的作用是：overlay 网络的封包解包；将虚机和虚拟网卡绑定起来；完成数据转发，可以是三层IP转发也可以是二层MAC转发；匹配现有流表，并应用相应的action；如果本地没有匹配的流表，将数据包上送到vRouter agent，由vRouter计算流表并下发；对特定的协议（DHCP, ARP, DNS, and MDNS）数据包，上送到vRouter agent做代理。
  

Routing Instance

这是个分布式转发平面的概念，Routing Instance在vRouter Forwarding Plane中，Routing Instance与tenant对应，只有当前计算节点有租户的虚机时，才会在当前的vRouter Forwarding Plane中创建Routing Instance。

按照这种设计，就算集群规模变大，每个计算节点只需要关心有限的租户信息，这种设计有利于OpenContrail在大规模环境下部署。

Gateway nodes

用来连接物理网络和虚拟网络的节点。

Service nodes

用来提供网络服务的物理网络单元，网络服务包括DPI（Deep Packet Inspection），IDP（Intrusion Detection），IPS（Intrusion Prevention），load balancer 等。Service nodes用在service chain，而service chain可以包含基于虚机的网络服务，也可以包含基于service nodes的网络服务。

一个包含了所有OpenContrail节点的架构如下图所示：

OpenContrail的架构在设计的时候参考了MPLS VPN的架构，组件和节点之间通讯的协议与MPLS VPN也很像。这有两点好处：

• MPLS VPN是一个成熟的技术，并且已经应用在大规模环境下，采用类似的架构可以使得OpenContrail从架构上胜任大规模环境
• 另一方面MPLS VPN广泛部署在现有设备上，采用类似MPLS VPN的架构可以使得OpenContrail能较为容易的接入现有的设备。
  

总结

OpenContrail号称能支持大规模部署，经过这几年的开发已经较为成熟，从架构设计上看也比较完善，支持的场景也比较多。并且，OpenContrail近得到了OpenStack老牌创业公司Mirantis的背书，同时Mirantis也开始转售Juniper的商业版Contrail system。去年的时候Mirantis收购了TCP cloud，TCP cloud是一家基于OpenContrail和OpenStack提供服务的小公司。通过这次收购整合，Mirantis也一定程度掌握了OpenContrail，近期Mirantis宣布OpenContrail将作为Mirantis OpenStack的默认构成部分，用户可以选择是否使用它，同时Mirantis也会提供对OpenContrail的支持。

但是另一方面，虽然OpenContrail是一个开源SDN，但是背后还有一个商业版的Contrail system。现在网上的安装部署文档也不多。个人认为开源版的目的是为了推广商业版，开源版本的落地还是有一定的难度（如果没有难度商业版也就没有存在的意义了）。

Midonet

Midonet是日本创业公司Midokura的网络虚拟化平台。Midokura早在2010年就开始做网络虚拟化，2014年底的OpenStack峰会上，Midokura将自己的产品Midonet开源出来，并通过networking-midonet项目集成到OpenStack中。Midonet有自己的北向（northbound）接口，提供RESTful API，可以独立于OpenStack存在。与OpenContrail类似的是，Midonet也有一个在售的商业版。除了更好的支持之外，商业版的Midonet支持VMware平台，带有一个集成的UI页面和更多的管理工具。它们的对比如下图所示：

来看看Midonet的架构吧。

从图中可以看出，Midonet的架构主要由三部分构成：

Network State Database

与前面介绍的ODL和OpenContrail不同的是，Midonet不再有逻辑集中的SDN controller，Midonet的逻辑中心是NSDB。NSDB北向提供REST api，供OpenStack和其他的Cloud orchestrator对接。南向通过RPC与运行在各个节点的Midonet Agent对接。NSDB的核心是基于Zookeeper + Cassandra。也就是说数据存储在一个高速的NoSQL数据库中。

Midonet Gateway

集群中连接外网的节点，通过BGP传播和学习路由信息，Midonet的BGP没有采用OpenStack的方案，而是自己基于quagga实现的。

Provider router

Midonet cluster中通常有一个provider router，这个是OpenStack Neutron没有的概念。这里的provider router是一个虚拟的概念，所有的tenant router都连接到这个provider router上。在Neutron里，tenant router之间的网络通讯，是走到external network，然后由provider（物理）network完成的转发。而在Midonet中，tenant router之间的网络通讯是通过provider router 完成的转发，而不需要走到provider network。

这么做的好处是：tenant router之间的网络通讯变得可控了；provider router 管理所有的南北向流量；集中的provider router做为BGP edge router，方便BGP路由的应用和管理。

Provider router 的uplink连接的就是Midonet Gateway节点。通常连接三个。

Midonet Agent

运行在计算节点上，管控着计算节点上的Cloud networking。Midonet Agent基于OpenvSwitch实现，但是只保留了OpenvSwitch的内核态部分，也就是说只保留了OVS datapath。而对应的ovs-vswitchd和ovsdb-server部分，都是由Midonet实现的。

Midonet Agent更像是对应ovs-vswitchd，OVS datapath不能处理的数据包上送到Midonet Agnet，Midonet Agent如果处理不了再通过RPC调用NSDB进行Overlay Topology Simulation。

Overlay Topology Simulation会根据Midonet掌握的集群网络信息进行运算，得出相应的配置和转发规则，再下发到OVS datapath。

Midonet自己有个图很有意思，描绘了Midonet的整体架构，包括虚拟和现实的对应。

总结

Midonet是一个商用化的SDN为了OpenStack做的开源，并且Midokura的工程师在OpenStack社区也很活跃。所以Midonet与OpenStack的集成没有大问题。其次，不像ODL和ONOS希望做大而全的SDN，Midonet专注于数据中心的Cloud networking，项目较为可控，适合大规模部署。

但是，Midonet本身还是掌握在Midokura公司，开源代码和商业版代码也不是一套，文档较为落后。而且Mirantis在选择第三方SDN的时候选择了OpenContrail而不是Midonet，对Midonet也有一定的冲击。

大体上来说，背后有商业版的开源，都不是真正意义的开源，开源只是为了更好的售卖商业版，毕竟背后的公司要挣钱。本文介绍的两个SDN都属于这个情况。