OpenDaylight融合OpenStack架构分析_opendaylight那个人接口可以集成openstack-CSDN博客

OpenStack和OpenDaylight（ODL）的融合是一个热门话题，有大量的文档可供参考，但是这些文章主要对其使用方面进行阐述，而没有讲如何实现OpenStack和ODL的融合。本文将详细说明如何实现不同组件的融合。

ODL和OpenStack完整的安装步骤如下：

1、在虚拟机或者物理机上构建和安装合适的ODL版本（取决于你的选择）。确保你有合适的bundle实现Neutron的API（OVSDB、VTN Manager、LISP等）。

2、正确配置并启动ODL。

3、部署OpenStack。最好是多节点部署：一个控制节点，一个网络节点和若干个计算节点。

4、配置OpenStack，为ODL和OpenStack的融合作准备：

确保核心插件在模块化的二层组件（ML2）上。
将ODL作为“机制驱动”部署在ML2上。
配置ml2_conf.ini文件的[ml2_odl]区域：

 
Shell
 
           1 
         
           2 
         
           3 
         
          1、 
          username 
            
          = 
            
          admin 
         
          2、 
          password 
            
          = 
            
          admin 
         
          3、 
          url 
            
          = 
            
          http 
          : 
          / 
          / 
          IP 
          - 
          Address 
          - 
          Of 
          - 
          OpenDayLight 
          : 
          8080 
          / 
          controller 
          / 
          nb 
          / 
          v2 
          / 
          neutron

5、在OpenStack上创建虚拟机，构建虚拟网络。

6、验证ODL界面生成的网络拓扑是否与想要的一致。

OpenStack和OpenDaylight融合

图1总结了OpenStack和ODL融合的全过程。Neutron包含ML2机制驱动，该机制驱动（ODL）作为REST代理能够调用所有的Neutron API。ODL包含北向REST服务（Neutron API服务），能够调用这些代理API缓存数据并可用于ODL的其他服务。下图详细地描述了这两个组件，这些RESTful API可以完成OpenStack和ODL的绑定。

图1:OpenStack和OpenDaylight融合

OpenStack

Neutron的模块化的二层组件（ML2）是一个可以使用二层网络多样性技术的框架。带有ML2插件的驱动程序实现了网络类型（local、flat、VLAN, GRE和VXLAN）的扩展和访问这些网络的机制驱动。

在ML2上，当添加、删除和修改三种核心资源（网络、子网和端口）的时候，将调用两次机制驱动。首次调用（也称为预提交调用）是为了维护机制驱动的状态，属于数据库业务的一部分。就ODL机制驱动而言，没有必要做这种预提交的操作。一旦业务被提交，机制驱动可以与外部服务和控制器交互的时候，其将被二次调用（也称为提交后调用）。

Figure Two ML2 Mechanism Driver Architecture

图2：ML2机制驱动架构

机制驱动在端口绑定过程中也发挥了作用：确定是否相关的机制可以为网络提供连接，如果可以，就使用相应的网段和VIF驱动。

图2总结了OpenStack Neutron的ML2机制驱动架构。ODL机制驱动由“mechanism_odl.py”文件和网络ODL驱动组成。基于ODL的API手册，机制驱动被分成了两个部分（核心API和扩展API），ODL机制驱动和ODL驱动类实现了核心API，ODL的3层路由插件类只实现了扩展API。目前，ODL驱动不支持防火墙服务（FWaaS）和负载均衡服务（LBaaS）。

ODL机制驱动接收到调用消息后，就对核心资源（网络、子网和端口）进行相应的添加、删除和修改的操作，机制驱动通过调用同步函数将消息转发给ODL驱动类，该同步函数采用了‘sendjson’ API。

同样地，ODL的3层路由插件类利用3层的API添加、删除和修改路由和浮动IP。因此，核心API和扩展API都调用‘sendjson’ API向ODL控制器发送REST请求，并等待应答。

之后的章节会介绍ODL是如何处理这些REST调用的。

OpenDaylight

OpenDaylight暴露OpenStack Neutron API服务接口，给多样性的解决方案提供Neutron API操作。图3总结了OpenDaylight Neutron API的实现架构，Neutron API服务主要由三个bundle组成：北向API和南向接口（SPI）、转录器（transcriber）以及解决方案的集合。

图3：OpenDaylight Neutron API实现架构

Northbound API Bundle

OpenDaylight的北向API处理来自OpenStack插件的REST请求并作出合适的应答。该bundle的组成部分如下：

1、父类请求： IneutronRequest。

2、JAXB(Java architecture for XML Binding)带注释的request类的集合，这些类涉及到的资源有：网络、子网、端口、防火墙和负载均衡等，这些request实现了IneutronRequest接口。例如：网络request包含如下属性：class NeutronNetworkRequest implements INeutronRequest

Shell
 
           1 
         
           2 
         
           3 
         
           4 
         
           5 
         
           6 
         
          @ 
          XmlElement 
          ( 
          name 
          = 
          "network" 
          ) 
         
          NeutronNetwork  
          singletonNetwork 
          ; 
         
          @ 
          XmlElement 
          ( 
          name 
          = 
          "networks" 
          ) 
         
          List 
          < 
          NeutronNetwork 
          > 
            
          bulkRequest 
          ; 
         
          @ 
          XmlElement 
          ( 
          name 
          = 
          "networks_links" 
          ) 
         
          List 
          < 
          NeutronPageLink 
          > 
            
          links 
          ;

3、Neutron北向类的集合：为管理资源提供REST API。例如：NeutronNetworksNorthbound 类包括如下API：listNetworks(), showNetwork(), createNetworks(), updateNetwork()和deleteNetwork()。

除非特别提及，symbol*类都表示如下资源：网络、子网、端口、路由、浮动IP、安全组、安全组规则、负载均衡、负载均衡监测、负载均衡监听器和负载均衡资源池等。

Neutron SPI Bundle

Neutron SPI是连接北向API到实现方案的重要bundle，这个bundle包括：

1、JAXB (Java architecture for XML binding)注释的基类和子类。这些类以Neutron*命名，支持v2.0版本的API文档。

2、INeutron*CRUD接口。这些接口通过转录器（transcriber）实现。

3、INeutron*Aware接口。这些接口通过特定的插件（OpenDove、OVSDB、VTN等）实现。

Transcriber Bundle

Transcriber模块包含Neutron*类，这些类通过实现INeutron*CRUD接口将Neutron对象缓存下来。其中，大部分的类都包含一个并发的HashMap。如private ConcurrentMap portDB = new ConcurrentHashMap()，所有的添加、删除和获取的操作都在HashMap上进行。

Implementation Bundle

OpenDaylight的优势在于其包含Neutron网络的多种实现方式，提供多种与OpenStack结合的方法。ODL的北向服务能够提供网络虚拟化，这一功能可以作为Neutron网络的一种实现方案。ODL用于Neutron API实现的插件包括：

1、OVSDB：OpenDaylight将其北向API与Neutron结合，使用OVSDB对计算节点的虚拟交换机进行配置。所以ODL可以管理网络连接，还可以为计算节点开通GRE或者VXLAN隧道。OVSDB Integration是一个可以实现Open vSwitch数据库管理协议的bundle。该管理协议是网络虚拟化中Open vSwitch转发数据需要的重要协议。虚拟化版本中的OVSDB neutron bundle支持使用VXLAN和GRE隧道部署OpenStack和CloudStack的网络虚拟化。

2、VTN Manager（Virtual Tenant Network）：VTN manager是网络虚拟化的一种解决方案，实现了一个使用AD-SAL的控制器的OSGI bundle，可以管理OpenFlow交换机。VTN manager还有一个单独的组件为OpenStack提供网络服务。VTN manager的Neutron组件能使OpenStack运行在单纯的OpenFlow环境下，因为数据平面所有的交换机都支持OpenFlow。VTN manager还可以使用OVSDB-enhanced VTN。Neutron bundle可以使用OVSDB插件进行添加端口等操作。

3、Open DOVE：Open DOVE是一个“网络虚拟化”平台，控制平面使用OpenDaylight，数据平面基于Open vSwitch。Open DOVE的目的在于供2层或3层的多租户网络建立连接，它运行在虚拟数据中心的所有IP网络上。据IBM研究，Open DOVE是基于IBM SDN虚拟环境和DOVE技术的。Open DOVE在氢版本发布之后就再没有更新过，无疑它在ODL锂版本上的扩展性受到了限制。

4、OpenContrail (plugin2oc)：为OpenDaylight控制器和OpenContrail平台提供交互。开源解决方案的结合使得OpenContrail具备了一些功能，例如：OpenDaylight项目的云网络和网络功能虚拟化（NFV）。

5、LISP Flow Mapping
LISP（Locator/ID Separation Protocol）目的在于提供一个灵活的map-and-encap框架可以为overlay网络应用程序所使用，并将网络的控制平面与数据转发平面分离。LISP包含两个namespace：endpoint identifiers (EIDs — 主机的IP地址)和routing locators (RLOCs —连接主机的LISP路由的IP地址).LISP流映射提供了LISP映射系统服务来存储数据（包括路由策略和负载均衡等）。

这些解决方案实现了以下部分或全部的功能：网络、子网、端口、路由、浮动IP、防火墙、防火墙策略、防火墙规则、安全组、安全组规则、负载均衡、负载均衡监测、负载均衡监听器、负载均衡资源池和负载均衡资源池成员。这些处理程序支持对核心资源（网络、子网和端口）进行相应的添加、删除和修改的操作。例如：NeutronNetworkHandler实现了如下操作:

 
Shell
 
           1 
         
           2 
         
           3 
         
           4 
         
           5 
         
           6 
         
          canCreateNetwork 
          ( 
          NeutronNetwork  
          network 
          ) 
         
          neutronNetworkCreated 
          ( 
          NeutronNetwork  
          network 
          ) 
         
          canUpdateNetwork 
          ( 
          NeutronNetwork  
          delta 
          , 
            
          NeutronNetwork  
          original 
          ) 
         
          neutronNetworkUpdated 
          ( 
          NeutronNetwork  
          network 
          ) 
         
          canDeleteNetwork 
          ( 
          NeutronNetwork  
          network 
          ) 
         
          neutronNetworkDeleted 
          ( 
          NeutronNetwork  
          network 
          )