码农学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
OpenStack的安装过程比较繁琐,难免遇到各种问题,笔者简单介绍了几个遇到的问题以及解决办法,供大家参考。

1)OpenStack Kilo版本比较老,官方文档有的没有更新,诸多配置文件已经从git库中移除,但是官方文档没有更新和说明。

处理办法:依赖社区或者原有的服务器,获取相应的配置文件。

2)OpenStack组件较多,笔者使用的Ubuntu官方源无法完整获取相应的软件依赖,可能导致部分服务起不来,如nova-compute服务等。

处理办法:更换国内的源,如阿里云源等或者自己公司(组织)配置的源。

2. OpenDaylight环境部署

OpenDaylight的安装主要以下载官方编译好的版本为主,有兴趣的话也可以自行下载源代码进行编译。此处不对安装过程多做介绍,只是针对性列举三点注意事项,可能会有所帮助。
1)OpenDaylight环境主要依赖java环境,比较容易,需要注意不同用户下面的配置在不同文件中,可以统一配置在/etc/profile下,供不同用户使用。

2)OpenDaylight的铍版本发布已经有一段时间了,目前使用的版本以锂版本为主。在与OpenStack集成过程中,笔者发现铍版本在性能和稳定性上都有较大的提高,建议大家使用铍版本完成集成实验。

3)如果选在源代码编译的方式安装OpenDaylight,建议选择linux作为编译环境,并且笔者遇到在Ubuntu16.04版本系统中编译不报错,但是生成的项目无法使用的问题,具体原因暂时没有分析,选择14.04版本系统解决。

3.集成过程

OpenStack中的Neutron项目中,使用ML2与OVS驱动来提供网络服务。ML2同时也支持各个厂商以及OpenDaylight、ONOS等提供的驱动,集成过程即更换配置驱动的过程。
3.1 配置
1)先删除OpenStack现有的虚拟机、路由器和网络。

2)停止neutron服务(控制节点)

3)停止neutron-plugin-openvswitch-agent服务(计算节点和网络节点)

也可以直接将这个agent卸载(计算节点和网络节点)

4)计算节点和网络节点清空OVS

5)连接OVS和OpenDaylight

此时,查看OVS情况将会看到OVS上已经创建了br-int,并且与控制器相连。

6)如果需要上外网,需要配置br-ex

此处的eth0为笔者的环境中的配置,指定为OpenStack节点隧道口网卡即可,此网卡不需要设置ip,详见OpenStack安装文档。

7)修改ML2配置
可以用命令:

也可以:
直接修改/etc/neutron/plugins/ml2/ml2_conf.ini文件,把mechanism_drivers的值由openvswitch换成opendaylight,tenant_network_types的值换成vxlan

再增加ml2_odl节点,配置OpenDaylight相关信息

8)创建ML2数据库,授权(在实际使用中发现,ML2数据库中没有写入任何数据,甚至连相关table都没有生成。后经验证,忽略本步骤也能正常集成OpenDaylight和OpenStack)

9)重启neutron服务

经过以上配置,OpenDaylight和OpenStack已经集成完毕,可以创建网络和虚拟机进行实验了,下面一个小节总结了集成的过程中容易出现的问题,读者可以参考排错。

3.2 可能遇到的问题
1)OVS与OpenDaylight连接之后,不能自动创建br-int
原因:OpenDaylight的组件问题,组件之间可能相互干扰
解决办法:清空组件,安装以下组件(以下组件为最小配置,如需使用OpenDaylight的其他功能请依照需求自行添加)

2)重启neutron服务失败
原因是虽然指定了mechanism_driver为opendaylight,但是还没有安装此driver的实现。使用以下命令安装之后,就能重启neutron服务了。

3)实验中,创建的虚拟机启动之后无法获取ip
原因:计算节点与网络节点的隧道没有建立
解决办法:将OVS相关信息告诉OpenDaylight,建立计算节点和网络节点之间的隧道,使得计算节点的虚拟机可以访问网络节点的dhcp服务。

上述命令中的uuid是OVS的uuid,可通过ovs-vsctl show命令查看,也可以通过ovs-vsctl get Open_vSwitch . _uuid命令查询,local_ip需要指定节点数据口的ip地址。

4)虚拟机不能访问外网
(1)需要修改网络节点/etc/neutron/l3_agent.ini文件,增加br-ex的配置,该配置在安装阶段默认留空,需要做如下配置:

(2)为br-int和br-ex之间建立patch对,使它们之间可以通信

3.3 简单验证
到这一步,恭喜你已经成功集成了OpenDaylight和OpenStack,可以通过简单的接口调用的形式进行验证,可以使用命令行curl工具或者使用postman发送请求。这里介绍命令行的方式。在控制节点上,使用如下命令:

当没有创建任何网络的情况下,将返回

尝试创建网络之后再次调用上述接口,将会返回相应网络资源的信息。

4 总结

至此,基本完成OpenDaylight与OpenStack的集成,OpenStack中创建网络、子网、虚拟机等功能与原来使用一致,但是计算节点与网络节点的OVS配置与原来不同,没有了br-tun,相应的流表也发生了变化。此时通过OpenDaylight Neutron项目提供的RESTful API,可以对OpenStack网络资源进行一定的管理。

作者:SDNLAB--SDN/NFV开发团队
简介:致力于SDN/NFV等前沿技术的研究、应用与实践,已研发推出UMS网络流量监控、SDN智能流量调度、NFV管理编排等产品。专注为高校、企业、政府以及电信运营商等客户提供定制化及个性化的SDN/NFV系统开发服务。

重要通知

OpenDaylight技术全球巡回中国行 | 南京站即将在12月12日在中国南京无线谷举行,报名链接:http://www.bagevent.com/event/280624

地址:江苏省南京市江宁区秣周东路9号中国无线谷,8号楼2楼学术报告厅
地铁3号线秣周东路地铁站3口出
驾车由苏源大道或双龙大道前往

嘉宾介绍

ad
  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。
  • 本文链接http://www.sdnlab.com/18099.html
  • 本文标签技术/tech

分享到:
相关阅读
0条评论

登录后才可以评论

SDNLAB君 发表于16-11-18
3