这一篇讲一下基于OpenvSwitch的SDN。
OVN（Open Virtual Network）是OVS社区在2015年1月发起的OVS子项目，其代码与OVS在一个库里面。OVN提供了一个可在大规模环境下部署的、产品级别的轻量级SDN。
在之前（2014年）的一个调查中，OpenvSwitch已经成为了OpenStack中最受欢迎的virtual switch，OVS为hypervisor提供了虚拟的网络设备，共同参与构建虚拟环境。鉴于OVS的广泛接受程度，并为了让OVS能胜任更多的场景，OVS社区提出提供一个轻量级的控制平面，借助这个控制平面，可以在虚拟网络设备之上实现OVS对虚拟网络的支持。
基于这个出发点，OVN在创立之初只关注2-3层的虚拟网络，这是区别于其他全功能的SDN控制器或者平台。OVN可以看成是OVS的补充，因此OVN可以运行在任何OVS兼容的环境下。虽然两者在一个项目下，OVN与OVS的连接采用的是OVS的通用接口，因此ovs-vswitchd和ovsdb-server不会因为OVN而受到影响（说Midonet呢）。另一方面，就算不使用OVN，对OVS本身也没有什么影响。
随着OVS 2.6的发布，OVN的第一个版本也随着发布（包含在OVS中），OVN从创立之初就考虑了与OpenStack的集成。OVN通过networking-ovn项目与OpenStack集成。Networking-ovn项目也是Neutron前PTL Kyle Mestery发起的项目。他后来跳槽到IBM，我曾经有幸在他的lead下参与过OVN的开发工作。
下面看看OVN的架构：
在OVS的基础上，OVN新增了两个进程：ovn-northd和ovn-controller，两个数据库：Northbound DB和Southbound DB。下面来分别看看：
存储virtual networking data model，例如 Switch，Router，Port等。Northbound DB是由CMS（OpenStack）写入，也就是说与之前说过的SDN不太一样，OVN北向不提供RESTful接口，而是直接由CMS写入数据库内容。举个例子，在OpenStack Neutron的场景下，对应的在Neutron中创建一个Network，需要通过networking-ovn在Northbound DB中创建一个LogicalSwitch。
监听Northbound DB的变化，将Northbound DB的内容翻译成LogicalFlow，存储在Southbound DB。Ovn-northd是一个集中的进程，在OVN环境下一般运行在独立的Database node上，在下面会再提到Database node。
存储LogicalFlow，Chassis和其他的一些信息。Southbound DB存储ovn-controller的数据。传统的集中式SDN控制器会根据已有的配置和数据计算OpenFlow规则，并下发到各个节点。而OVN将这个过程分解成了两部分：
先通过ovn-northd将配置和数据计算成LogicalFlow。一个LogicalSwitch下的LogicalFlow是一样的。
将LogicalFlow分发到各个ovn-controller，再由ovn-controller将计算出相应的OpenFlow规则下发。这样做的好处是一些全局的运算只需要做一次。
分布在各个计算节点（OVN中叫做chassis）的SDN controller。Ovn-controller向上读取Southbound DB的数据，应用在本地；并且读取本地的VIF和Chassis信息，向上更新。
OVN对于网络功能的实现，秉承的是分布式思想。因此网络功能都分布在计算节点，并且没有一个专门的网络节点。但是OVN需要独立的Database node。这是因为OVN目前采用ovsdb-server作为其DB，一方面，这对于OVN的部署很方便，因为OVN本身就基于OVS，采用ovsdb-server可以避免新增依赖。但是另一方面，ovsdb-server之前的主要应用场景是给OVS存储hypervisor本地的虚拟网络设备信息，而OVN是一个集群内运行的软件，ovsdb-server明显不能胜任这种大规模的数据读写。同时，前面说过ovn-northd是一个集中式进程，因此用一个独立的Database node来运行ovn-northd并存储Northbound DB和Southbound DB，可以一定程度的缓解瓶颈问题。
OVN与OpenStack集成之后的运行框架如下图所示 ：
OVN是一个厂商中立的开源项目，背后并没有一个大的厂商在操纵，项目的发起是VMware的工程师，项目的推进有Redhat和IBM等其他公司的参与。相比ODL，ONOS其架构也较为简单。OVN在创立之初就考虑了与OpenStack的集成，因此OVN在OpenStack环境下工作的较好，一些OpenStack Neutron已知的问题，在OVN中都有较好的解决，例如DVR，Security Group的性能问题。对于已有的OpenStack + OVS环境，升级到OVN也是一个不错的选择。据说OVN已经在数百个物理节点上进行了部署测试，并且用ovn-scale-test项目进行了数千个节点的模拟测试。
其现在的主要问题就在于Database node的瓶颈问题，相信后继的改进能够解决这个问题。其他问题在于项目的定位不是一个全功能的SDN，因此只有2-3层的virtual networking。不过这个倒是契合OpenStack Neutron的定位。其他的advanced 功能可以通过OpenStack Neutron的各个子项目弥补。
如果说其他的SDN项目是在OpenStack之外生长的，再嫁接到OpenStack，那Dragonflow就是土生土长的OpenStack SDN项目，Dragonflow是OpenStack的big tent项目，属于Neutron下面的子项目，是一个基于Python的完全开源的项目。
Dragonflow是华为公司以色列团队发起并推动的项目，最早在OpenStack Kilo版本提出，是为了解决Neutron DVR的问题。有关Neutron DVR的问题，这里就不展开了，以后有机会细说。在OpenStack Liberty版本开始，可能是受OVN项目的影响，Dragonflow转向全面的SDN项目，与OVN不同的是，Dragonflow目的是提供全功能的SDN解决方案。一直到刚刚结束的Ocata版本，Dragonflow社区一直处于活跃的开发和正向的演进中。本人目前也是Dragonflow项目的活跃开发者之一。
Dragonflow的定位是大规模环境下高性能SDN解决方案。来看看它的架构吧：
其组成部分主要有Neutron plugin，Message Driver，DB driver，Dragonflow controller。分别来看看这些组成部分：
由于Dragonflow就是OpenStack Neutron下面的的子项目，因此Dragonflow自己完成了与Neutron的集成，Neutron plugin就是Dragonflow中与Neutron的集成部分，这个与其他的SDN一样，实现了ML2 mech driver和各种Service plugins。与OVN类似的是，目前Dragonflow本身不提供独立的RESTful接口，Neutron plugin直接写Dragonflow Database，并触发相应的Message。
Dragonflow组件间通讯的方式，其他的SDN一般是定义好了组件间通讯的方式，要么是RPC，要么是其他协议，而Dragonflow将这部分做了一个抽象，可以支持多种Message机制，目前支持的有ZeroMQ和ReidsMQ。这样用户可以根据不同的使用场景，选用不同的Message机制。Message Driver用来连接Dragonflow Controller和Neutron server，并在之间传递数据。
与Message driver类似，其他的SDN一般只支持一种DB，但是Dragonflow将这部分也做了抽象，可以支持多种NoSQL数据库，目前支持的有etcd，RAMCoud，Reids，Cassandra等。这样实现的目的也是为了用户可以根据不同的使用场景，选用不同的DB，以达到最好的性能效果。
这个是Dragonflow的核心部分。
所有的Dragonflow controller都监听Message driver，当Neutron plugin发布相应的Message，Dragonflow Controller能收到这个消息，并进行相应的计算，更新相应的OpenFlow规则和本地的配置，同时Dragonflow会通过Message driver上报本地的信息，例如端口上线事件。
刚刚结束的Dragonflow Northbound DB重构，将Dragonflow Controller中的数据和消息机制，按照Model来管理，这有点类似于ODL中的MD-SAL。
为了提高网络计算的速度，Dragonflow本地有一个数据的缓存，这样在进行网络计算的时候，直接可以从内存中读取数据进行运算，而不需要再读取远端DB数据。这样能减少网络计算的时间，降低网络延时。
为了适应大规模部署，Dragonflow中还有一个selective topology的概念，这个有点类似我在上一篇中介绍的OpenContrail里的的vRouter中的routing instance概念。
只有当前计算节点关注的Topology才会在当前Dragonflow Controller中存在缓存，并且相应消息才会被当前Dragonflow Controller接收。当前计算节点关注的Topology是指当前计算节点上相应租户（tenant）的虚拟机。这样的设计，使得在大规模部署环境下，每个Dragonflow Controller的只需要监听有限的信息，缓存有限的数据，不会因为规模的变大而导致单个Dragonflow Controller负荷变大。
这里是具体网络功能的实现，因为Dragonflow Controller是运行在各个计算节点的，因此，Dragonflow对于网络的运算，也是放到各个计算节点，这是一个真正的分布式可插拔的SDN方案。之前介绍的SDN要么是集中式的SDN，要么是部分运算在集中式节点，部分计算在分布式节点。
在NAL，每个网络功能都是一个独立的application。为了实现相应的网络功能，每个计算节点上都必须运行一套applications。目前实现的网络功能有DHCP，L3 routing，L2，Security Group，等等。
与ovn-controller类似的是，Dragonflow Controller底层连接的也是ovs-vswitchd和ovsdb-server。
与OVN类似的是，Dragonflow也有一个专门的Database node，但是与OVN不一样的是Dragonflow的Database Node可以是任何DB backend，例如实际环境下可以部署一个RedisDB的HA集群，这在大规模环境下优势要明显强于OVN的ovsdb-server。另一方面不一样的是，Dragonflow的Database node不关心任何网络运算，所有的网络运算都交由分布在计算节点的Dragonflow controller完成。
Dragonflow是一个真正的分布式SDN解决方案，其底层依赖OVS。因此对于现有的Neutron + OVS架构，迁移到Dragonflow也较为自然，实际上，Dragonflow目前也有相应的努力，提供Neutron + OVS agent迁移到Dragonflow的方案（开发中）。
从社区开发来看，华为是目前的主要贡献者，不过从其目前的开源策略看，Dragonflow并没有想做成一个厂商控制的开源项目。
另一方面，Dragonflow现在还处于一个相对早期的阶段。并且分布式的SDN方案，虽然将网络运算分布到了各个计算节点，能够从理论上去除瓶颈，扩大集群规模，但是也增加了开发的难度和浪费了集群内整体的计算资源，因为同一个网络运算，需要在多个计算节点分别完成，从整体上看是有一定的浪费。
不过鉴于目前计算资源成本较低，这些副作用利大于弊，总体来说，Dragonflow还是一个很有前途的SDN项目。
本文转载自：https://zhuanlan.zhihu.com/p/25996102
