Openstack和Opendaylight框架集合

最新推荐文章于 2023-10-26 17:13:16 发布

qugq丶

最新推荐文章于 2023-10-26 17:13:16 发布

阅读量1.4k

点赞数 1

分类专栏：网络

本文链接：https://blog.csdn.net/Q1341389014/article/details/78342709

版权

网络专栏收录该内容

9 篇文章 0 订阅

订阅专栏

最近在了解openstack和opendaylight框架及集合过程

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]区域：

username = admin
password = admin
url = http://IP-Address-Of-OpenDayLight:8080/controller/nb/v2/neutron

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

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

OpenStack和OpenDaylight融合

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

ML2 plugin

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

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

TypeDriver

和neutron中的网络拓扑对应。实现和底层实现技术无关的代码，有4个接口：

def validate_provider_segment(self, segment):

def reserve_provider_segment(self, session, segment):

def allocate_tenant_segment(self, session):

def release_segment(self, session, segment):

TypeDriver的代码和具体的底层实现无关，所有的实现都可以复用这部分代码。

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

MechanismDriver是用来将rest api转化为底层实现技术的调用，类似于原来的Plugin实现。每种网络虚拟化实现要实现自己的MechanismDriver来驱动后端的实现。

ml2的核心就是可以加载多个mechanism drivers，在一个openstack环境中支持多种虚拟网络实现技术。如有些节点可以使用openvswitch,有些则使用cisco Nexus 1000V等。

ml2的基本代码逻辑：

针对每个rest api,会调用所有mechanism driver的相应方法(这个思路和meta中遍历调用Plugin的方法类似)。如create network:

self.mechanism_manager.create_network_precommit(mech_context)

self.mechanism_manager.create_network_postcommit(mech_context)

mechanism driver提供2个方法，一个是XXX_precommit，一个是XXX_postcommit.

XXX_precommit在一个事物中调用，过程中抛出异常，neutron中的数据库会自动回滚。

XXX_postcommit在事物外调用，过程中出现异常，neutron中的数据库不变。

开发人员需要根据业务特点，来决定使用哪种方式。

MechanismManager：

def _call_on_drivers(self, method_name, context,

continue_on_failure=False):

该方法用来调用ml2加载的所有meachnism driver。

openstack和opendaylight集成主要关注Mechanism Driver

networking_odl

OpenStack支持多种SDN控制器的对接，有一个对接方案是将一个mechanism driver的python文件放在neutron ml2目录下面，使得OpenStack对neutron的操作可以转发给SDN控制器。后来发展的driver被命名为networking-XXX项目。

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

ODL-Networking分为v1 driver和v2 driver，v1 driver会把OpenStack上的网络更改同步到ODL控制器上。举个例子，用户创建了一个网络，首先这个操作会被写进OpenStack数据库中，然后ODL driver会发送一个POST请求到ODL控制器。虽然这个操作看起来很简单，但是却有一些隐含的问题：

ODL并不是实时反应的，即使REST call成功给到了ODL,ODL也不一定可以马上响应；
在负载很大的时候（可能是odl或者openstack）,两边的同步可能会存在瓶颈；
在遇到odl与openstack同步失败时，v1 driver在下次的call REST API时会尝试去“full sync”整个neutron DB，所以会导致下次的REST API call花费很长的时间
在多个rest api call竞争的情况下可能会出问题：
1.如，创建subnet时再创建port的情况，neutron的HA部署的时候，这2个创建的消息会同步的通过v1 driver发给ODL,导致创建port失败；
2.在前面的“full sync”操作的时候，数据库如果正在删除资源，那么此时同步，会把下一时刻被删除的资源，同步到odl这边，形成openstack和odl的资源不同步。

面对前面的这些问题，社区又重新设计了v2 driver：
v2 driver最重要的机制是引入了journaling（记录）机制，v2 driver会把openstack传给open daylight的数据记录在一个journal表中，journal表使用一堆队列来构成的。而不是直接把openstack的数据传递给odl；
v2 driver中会起一个journal的线程，它会周期性地检查journal表中是否有新的数据，然后处理新的数据，另外的，openstack neutron的postcommmit的操作也会触发这个线程工作；
用户在创建一个网络资源的时候，这条数据会一开始存在neutron DB中，v2 driver再把这条数据存在“journal entry”里面，这个时候触发journal线程来处理这条数据；
数据在pre-commit的时候就已经被记录在journal entry中了，以防止这个commit失败的时候，journal entry也可以马上中止，实现消息的同步。

OpenDaylight Neutron和ovsdb-openstack

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

以创建一个子网作为例子，请求处理流程如下图所示：

ovsdb-openstack组件中注册了各种监听Data Store中不同资源变化的listener，根据变化的情况，进行对应的处理。上图中Neutron组件对Data Store的操作都会被listener监听到，并转化为相应的事件。对于这些事件，ovsdb-openstack组件也定义了不同的handler进行处理，最典型的处理就是下发相应的流表。

交互过程

介绍完了不同的组件，有必要对它们之间的交互过程做一个总结，如下图。可以看到，当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变化，处理并下流表。