码农学ODL之OpenDaylight与OpenStack的集成

OpenDaylight和OpenStack的集成一直是热门话题，OpenDaylight官网也提供了相应的文档（https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylight）供大家参考。但是， 由于OpenStack的版本以及安装配置存在差异，以及OpenDaylight版本也不断更新，所以仅仅参考官方文档进行集成，可能会遇到不少困难。在此，笔者就自己的集成过程做个总结，希望对大家有所帮助。此次集成的实验环境为Ubuntu14.04，jdk1.8，OpenStack Kilo版本以及OpenDaylight Beryllium版本。

OpenDaylight与OpenStack集成主要依赖OpenStack的ML2 plugin，本文的前半部分先给大家简单介绍一下集成中所涉及的组件以及它们之间的交互，后半部分为具体的集成过程和一些值得注意的点。

一、组件结构

OpenDaylight与OpenStack集成过程，需要不同的组件协同配合，包括OpenStack 中的ML2 plugin、networking_odl以及OpenDaylight 中的Neutron和 ovsdb-openstack组件。接下来将分别介绍它们的功能和组件交互过程。

1.ML2 plugin

ML2（Modular Layer 2）是一种允许OpenStack网络同时利用多种二层网络技术的框架。ML2主要包含两种驱动类型，类型驱动（TypeDriver）和机制驱动（MechanismDriver），分别实现可扩展的网络类型和访问这些类型的网络机制集合。

类型驱动可以管理多种网络类型，目前支持local, flat, vlan, gre, vxlan等。类型驱动维护任何类型所需的网络状态、分配租户网络等。

机制驱动接口支持网络、子网、端口的创建、更新、删除操作。对每个资源，机制驱动暴露出两种方法ACTION_RESOURCE_precommit,和ACTION_RESOURCE_postcommit。precommit方法用于验证ACTION是否有效并且维护机制驱动私有的数据库，这类方法不能被阻塞。postcommit主要负责操作资源，并且把资源的变化同步给控制器，控制器可以根据变化做出响应。

图1.1.1 ML2结构和驱动类型

上图列举了部分的ML2 Type Driver以及部分Mechanism Driver，本次集成主要关注Mechanism Driver，这些驱动除了各个厂商以及OVS，Linuxbridge等提供的驱动外，还包括OpenDaylight、ONOS等驱动。

2.networking_odl

networking_odl是ML2机制驱动的一种具体实现，具体作用就是实现ML2中定义的precommit和postcommit方法来操作网络资源。其中postcommit方法实现了同步OpenStack Neutron里面的网络信息到OpenDaylight Neutron组件的功能。存在三种场景会触发postcommit操作， 第一种是OpenStack Neutron网络资源的增删改查时。第二种是OpenDaylight重启在内存中的信息丢失时。第三种是OpenDaylight Neutron组件中的信息发生错误时。

图1.2.1是一个networking_odl组件在OpenStack Neutron中工作以及同步信息到OpenDaylight的情形。当前版本的networking_odl虽然在大多数情况能够使得OpenStack与OpenDaylight协同工作，但是存在扩展性不足，不支持Neutron HA以及特定条件下OpenStack Neutron数据库信息与OpenDaylight中信息不同步等问题，具体信息可以参考链接：https://wiki.opendaylight.org/images/8/8d/Experiences_with_Neutron.pdf。

图1.2.1 networking_odl工作模式

图1.2.2描述了新版本的networking_odl预计的运行情况，在新版本的规划中，networking_odl首先解决数据库信息不同步的问题，然后对Neutron HA提供了支持。目前该版本还在开发中，大家可以关注一下。

图1.2.2 新版networking_odl工作模式

3.OpenDaylight Neutron和ovsdb-openstack

OpenDaylight Neutron项目在集成中主要有两方面的作用，第一，提供一套RESTful API供ML2调用，用来进行网络资源操作以及同步数据，当然用户也可以通过这套API对网络资源的整体情况做一个把控。第二，维护一个网络资源的Data Store，通过对API请求的处理，对Data Store进行增删改查。

OpenDaylight Neutron项目使用Jersey作为RESTful框架提供服务，以创建一个子网作为例子，请求处理流程如下图所示：

图1.3.1 OpenDaylight Neutron组件创建子网实例

ovsdb-openstack组件中注册了各种监听Data Store中不同资源变化的listener，根据变化的情况，进行对应的处理。上图中Neutron组件对Data Store的操作都会被listener监听到，并转化为相应的事件。对于这些事件，ovsdb-openstack组件也定义了不同的handler进行处理，最典型的处理就是下发相应的流表。其具体过程将作为重点在后续篇目中给出，此处不再赘述。

4.交互过程

介绍完了不同的组件，有必要对它们之间的交互过程做一个总结，图1.4.1是其交互过程的示意图。可以看到，当OpenStack Neutron API接收到用户创建网络等操作请求，它会调用ML2的相关方法，ML2已经定义了postcommit方法实现资源操作和同步，由networking_odl提供postcommit的具体实现。networking_odl的postcommit会调用OpenDaylight Neutron的REST接口将请求封装后发送到OpenDaylight Neutron组件，OpenDaylight Neutron处理请求并存入Data Store，ovsdb-openstack监听Data Store变化，处理并下流表。

图1.4.1 各个组件的交互过程

二、环境部署与集成

1.OpenStack环境部署

笔者实验的OpenStack版本为Kilo版本，其他版本的安装配置请参考各个版本的官方文档。OpenStack中服务很多，搭建过程中笔者选择了基本的的服务进行配置，保证OpenStack的基本功能，并且能够与OpenDaylight集成。安装的服务有：Keystone，Glance，Nova，Neutron，Dashboard。在此，给出Kilo版本官方文档地址：http://docs.openstack.org/kilo/install-guide/install/apt/content/ch_preface.html