目录
1.OpenDaylight简介
OpenDaylight（ODL）作为软件定义网络（SDN）的控制面，拥有一套模块化、可插拔灵活地控制平台作为核心，这个控制平台基于Java开发，理论上可以运行在任何支持Java的平台上，在一定程度上能够降低北向应用和南向协议的耦合性。相比于传统网络架构来说具有很多优点：（1）传控分离，网络资源集中控制，统一调度，提高网络运行的效率.（2）实现于数据面的解耦合，改善了传统网络升级、维护带来的难题。（3）可以实现大规模路由，提高网络资源的利用率。下面将分别介绍ODL的相关内容。
1.1 OSGI框架
ODL控制器采用OSGi框架，OSGi框架是面向Java的动态模型系统，它实现了一个优雅、完整和动态的组件模型，应用程序（Bundle）无需重新引导可以被远程安装、启动、升级和卸载，通过OSGi捆绑可以灵活地加载代码与功能，实现功能隔离，解决了功能模块可扩展问题，同时方便功能模块的加载与协同工作。
自Helium版本开始使用Karaf架构，作为轻量级的OSGi架构，相较于早前版本的OSGi提升了交互体验和效率，当然其特性远不仅仅于此。
1.2 Maven项目管理工具
ODL项目是由多个feature构建而成，而每个feature是由大大小小的bundle组合而成的，Maven负责构建bundle，它包含项目对象模型、标准集合、项目生命周期、依赖管理系统和用来定义生命周期阶段中插件和目标的逻辑。
1.3 模型驱动的服务抽象层（MD-SAL）
ODL控制平台引入了SAL（服务抽象层 ），SAL北向连接功能模块，以插件的形式为之提供底层设备服务，南向连接多种协议，屏蔽不同协议的差异性，为上层功能模块提供一致性服务，使得上层模块与下层模块之间的调用相互隔离。SAL可自动适配底层不同设备，使开发者专注于业务应用的开发。
但是随着南向协议的的发展，AD-SAL难以支持多种南向协议，由此SAl层变得越来越臃肿。因此自Helium版本开始向MD-SAL演进。MD-SAL与AD-SAL设计结构上的差别主要如下：
1.不同于AD-SAL，MD-SAL引入了Data Store的概念，在其提供的Data Store中，存储由北向Application和南向Device所定义的Yang Model数据。
2.北向Plugin、南向Plugin均可对这些Yang Model定义的数据进行存取操作。
3.不同于AD-SAL，在MD-SAL中，北向Plugin与南向Plugin之间的适配由单独的适配Plugin来完成。该适配Plugin仅在北向API与南向API不同时才需求。如果北向API与南向API是1:1的关系，那二者就可以通过访问共同的Data Store来实现数据交互，这就避免了AD-SAL中必需的南北向API静态绑定的问题。
引入Data Store及Model的概念后，MD-SAL所完成的主要工作就是数据提供者(provider)和数据消费者(consumer)之间的连通工作：数据提供者/数据消费者均需向MD-SAL注册；数据提供者在提供数据后，会产生Notification;数据消费者可以向MD-SAL订阅数据，在收到数据发生变化的Noticifaction后，其可以从MD-SAL的Data Store获取数据。即以下三种详细传递机制：
总之，可以将MD-SAL看作DataStore和消息总线的结合体。
1.4 YANG数据模型
YANG是一种数据建模语言，被用来为NETCONF远程过程调用操作的配置和状态数据模型。
每个个YANG module定义了具有垂直结构的数据，这些数据可以被用做基于NETCONF的operations，比如configuration，state date，RPCs，以及notifications。它使得NETCONF的client和server之间能有完整的数据描述。
YANG数据具备树形结构，其中每一个节点都有一个名字，都有一个值或者一些子节点。YANG为这些节点，以及节点之间的交互提供明确清晰的描述。
后面将介绍使用YANG语言来进行ODL的开发。
1.5 ODL整体结构
经过上述陈述，可以将opendaylight总结为以下以MD-SAL为中心的结构框架。
2. OpenStack集成OpenDaylight架构
2.1 融合结构概述
云和虚拟化方向的整合，一直伴随着Opendaylight的发展，在最早的Hydrogen版本，就有了Openstack Service、OVSDB Neutron和VTN这三个云相关的项目。发展到现在，目前与云/虚拟化相关的项目有Neutron-NorthBound、Netvirt、VTN、GBP、SFC、Genius等项目。
因此，最近做了关于openstack和opendaylight项目的集成测试，OpenDaylight与OpenStack集成主要依赖的主要插件是OpenStack的ML2 plugin，作为ODL驱动程序的Networking-odl项目、和Opendaylight中用来接收、分发Networking-odl的RESTful API的plugin-Neutron-NorthBound、以及作为openstack网路后端的项目Netvirt。
本文的前半部分先给大家简单介绍一下集成中所涉及的组件以及它们之间的交互，后半部分为具体的集成过程和一些值得注意的点。
2.2 组件结构
OpenDaylight与OpenStack集成过程，需要不同的组件协同配合，包括OpenStack 中的ML2 plugin、networking_odl以及OpenDaylight 中的Neutron-NorthBound和Netvirt组件。接下来将分别介绍它们的功能和组件交互过程。
2.2.1 插件管理-ML2 plugin
ML2（Modular Layer 2）是一种允许OpenStack网络同时利用多种二层网络技术的框架。ML2主要包含两种驱动类型，类型驱动（TypeDriver）和机制驱动（MechanismDriver），分别实现可扩展的网络类型和访问这些类型的网络机制集合。
（1）类型驱动可以管理多种网络类型，目前支持local, flat, vlan, gre, vxlan等。类型驱动维护任何类型所需的网络状态、分配租户网络等。
（2）机制驱动接口支持网络、子网、端口的创建、更新、删除操作。对每个资源，机制驱动暴露出两种方法ACTION_RESOURCE_precommit,和ACTION_RESOURCE_postcommit。其中，precommit方法用于验证ACTION是否有效并且维护机制驱动私有的数据库，这类方法不能被阻塞。postcommit主要负责操作资源，并且把资源的变化同步给控制器，控制器可以根据变化做出响应。
上图列举了部分的ML2 Type Driver以及部分Mechanism Driver，本次集成主要关注Mechanism Driver，这些驱动除了各个厂商以及OVS，Linuxbridge等提供的驱动外，还包括OpenDaylight、ONOS等驱动。
2.2.2 接口组件-networking_odl
openstack通过networking-odl项目与opendaylight进行对接，目前支持的Plugin包括ML2、L3、FWaas、LBaas、SFC等，其功能非常丰富。
networking_odl是ML2机制驱动的一种具体实现，具体作用就是实现ML2中定义的precommit和postcommit方法来操作网络资源。
其中postcommit方法实现了同步OpenStack Neutron里面的网络信息到OpenDaylight Neutron组件的功能。
存在三种场景会触发postcommit操作：
第一种是OpenStack Neutron网络资源的增删改查时。
第二种是OpenDaylight重启在内存中的信息丢失时。
第三种是OpenDaylight Neutron组件中的信息发生错误时。
networking-odl经历了两个版本，在V1版本中networking-odl主要工作就是将Neutron的RESTful API转化为ODL的RSETful API，然后直接进行透传networking-odl本身是没有任何状态的，由于ODL在本地有自己的数据库，因此在使用networking-odl v1时，尤其是在Neutron HA的部署方式下，Neutron和ODL间的数据库同步存在很大问题。
因此，在M版本开始，networking-odl提出了v2版本，希望你能够解决数据库同步问题。networking-odl v2的做法就是增加一个Syncer，他在收到北向plugin的RESTful API时，并不是直接透传给odl，而是通过Syncer来同步openstack和odl间的状态。
图描述了networking_odl v2版本的运行情况：
具体来说,整个由上及下的工作流如图6-11所示，具体流程如下：
（1）用户发送一个Neutron API,由Neutron-Server路由给相应的ODL v2 Driver（networking-odl v2）
（2）ODL v2 Driver接收到API后，不会直接发送给ODL,而是将该API作为一个journal entry存人Journal DB中,标记其状态为PENDING.
（3）Networkin-odl v2会在后台运行一个Journal Thread, Journal Thread会读取Journal DB中最先存入journal entry,将其状态置为PROCESSING,然后转化为相应的RESTful API发送给ODL，由openstack service provide作为后端，并阻塞等待ODL的执行结果。
（4）如果ODL执行成功,则Journal Thread将该journal entry，状态置为COMPLETED,表示执行成功。否则将该journal entry状态重新置回PENDING，将其Retry Counter (重试计数器)加1。
（5）当某个journal entry的Retry Counter超过一定次数时，journal entry会将其状态置为FAILED，表示执行失败。除了journal entry以外，后台还有MaintenanceThread去处理COMPLETE和FAILED的journal entry。
数据库出现同步问题，主要由于操作顺序混乱，而journal主要是为Neutron和ODL之间引入顺序操作的能力，从而解决同步的问题，但是Journal Thread的阻塞必然会导致，它们之间的并发能力。netwoking-odl v2也只能说是一个探索，未来还需要不断优化。
2.2.3 接口组件-Northbound
OpenDaylight Neutron项目在集成中主要有两方面的作用：
第一，提供一套RESTful API供ML2调用，用来进行网络资源操作以及同步数据，当然用户也可以通过这套API对网络资源的整体情况做一个把控。
第二，维护一个网络资源的Data Store，通过对API请求的处理，对Data Store进行增删改查。
ODL有一个专门用来接收、分发networking-odl的RESTful API的plugin：neutron-NotherBound，目前在GitHub上的项目名为neutron。
其中，networking-odl和nerthbound对接模式如图所示：
networking-odl下发RESTul给NeNorthbound Plugin, Neutron-Northbound Plugin在实现上分为2个模块(Boron之后的版本),包括northbound-api, Transcriber：
其中, North-bound-API模块接收RESTful API,并将其中Neutron的标准数据结构交给Transcriber模块。
Transcriber模块负责将Neutron的标准数据结构转化为MD-SAL中为Neutron设计的YANG Model,然后对DataStore进行相应的操作。
其他一些Plugin (如Netvirt, VTN等)监听DataStore上的数据变化,并完成相应的后端操作。
2.2.4 后端提供者-Netvirt
在早期的版本中，Netvirt作为openstack的后端提供者，它有两种实现方式：ovsdb-netvirt和v*nService。首先ovsdb-netvirt是由原先的OVSDB项目分离出来，通并过OVSDB来实现网络虚拟化的，v*nService提供v*n服务没有限定南向协议，两者都可以作为openstack的网络后端，两者在功能上有些重叠。
因此，自Borneo版本开始，社区计划将v*nService合并入Netvirt中，但是由于对两者的合并比较困难，在cabon版本中两者目前都是netvirt下两种独立的provide。
所以，首先来看合并之前的OVSDB-netvirt和v*nService两种provide：
OVSDB-netvirt早在ODL的Hydrogen版本中就已经出现，经过几个版本的发展，对openstack的网络支持已经很完善了。其北向上以来Neutron-NorthBound来处理RESTful API，而所有的后端实现都是由Netvirt-provider目录下的Application来完成，南向上通过openflow和OVSD来操作完成pipeline。
对于v*nService来说，同样作为openstack的后端，其功能也很多，v*nService是一个非常庞大的项目，在合并前主要分为三大块：
（1）Neutron v*n Manager,它监听DataStore中由Neutron Northbound Transcriber生成的数据结构,并将其转化为v*nService的数据结构,再存人DataStore中。
（2）各类业务逻辑模块,它们监听DataStore中v*nService的数据结构,并提供相应的业务实现,主要包括负责二层网络连通性的ELAN Manager,负责三层网络连通性的v*n Manager,负责NAT的NATService等等。
（3）各类通用的资源管理,如负责隧道管理的Tunnel Manager,负责接口管理的Interface Manager,等等。
目前在氧版本中（待考证），两者已经基本融合完毕，在ODL的后续版本中，Netvirt将以v*nService为代码基础进行后续功能的开发和迭代，而OVSDB-netvirt的代码会继续维护但不在添加新的功能。
因此，v*nService和OVSDB-Netvirt合并后目标，是将代码分散到3个plugin中：
（1）Neutron v*n Manager和各类业务逻辑合并到新的netvirt；
（2）各类通用的资源管理提取到Genius中
（3）而与BGP v*n直接相关的模块仍然保留在v*nService项目中。
所以，融合之后的结构如下图所示，在后边文章将分别介绍ovsdb-netvirt和v*nService的实现过程和Genius项目。
2.3 融合结构总结
通过以上几种组件的介绍，现在对它们之间的交互过程做一个总结，下图是其交互过程的示意图：
(1)当OpenStack Neutron API接收到用户创建网络等操作请求，它会调用ML2的相关方法。
（2）ML2已经定义了postcommit方法实现资源操作和同步，由networking_odl提供postcommit的具体实现。
（3）networking_odl的postcommit会调用OpenDaylight Neutron的REST接口将请求封装后发送到OpenDaylight Neutron（NortherBound）组件。
（4）OpenDaylight Neutron中的northbound-api模块将neutron中的标准数据传递给Transcriber，Transcriber将数据转换成MD-SAL定义的Yang格式，并存入Data Store。
（5）netvirt组件中注册了各种监听Data Store中不同资源变化的listener，根据变化的情况，进行对应的处理。上图中Neutron组件对Data Store的操作都会被listener监听到，并转化为相应的事件。对于这些事件，netvirt组件也定义了不同的handler进行处理，最典型的处理就是下发相应的流表。
