转载

透过现象看本质——谈谈ML2 plugin这回事儿

本文关键词：OpenStack、Neutron Plugin、Neutron Agent、Core Plugin、ML2插件、ML2架构、Driver、紧耦、解耦。

前言

在OpenStack中，其控制管理着计算、存储、网络三大资源。要想明白OpenStack是如果对计算、存储和网络资源进行管理的，就需要清楚OpenStack的架构，模块组成和各自分工的任务等等。

而网络是作为OpenStack中最为核心之一的、也是相对于其他最为复杂的一块，因此需要细品~

今天就来透过现象看本质，谈一谈ML2插件这回事儿~

Neutron Plugin是个什么鬼？

Plugin——插件，根据百度搜索的结果，其介绍为：一种遵循一定规范的应用程序接口编写出来的程序。那么什么是Neutron插件呢？不用想太多，其实就是有关网络的插件，可以使Neutron提供完整的服务。

我们知道，在OpenStack中，总的来说插件的作用可以理解为：

处理Neutron Server发来的请求；
维护OpenStack中网络的状态；
调用agent处理请求；

由此也可以明白，在OpenStack Neutron项目中，插件和代理服务是相对应的，而且plugin解决的是在数据库中存放网络信息，需要解决的是网络请求时需要什么配置的问题，而agent解决的是如何具体配置网络的问题，而agent处理时需要通过Neutron provider（网络提供者）提供虚拟或物理网络（Linux Bridge或OVS或其他的物理交换机），也可以说这三者需要配套使用。

细的来说，Neutron Plugin 有两种，一种是Core Plugin——核心插件,主要是在数据库中维护network、subnet和port的状态，并负责调用相应的agent在network provider上执行相关操作，比如创建network；另一种是Service Plugin——服务插件，主要是在数据库中维护router、load balance、security group等资源的状态，并负责调用相应的agent在network provider上执行相关操作，比如创建router。

那么，plugin的其中一个职责就是维护Neutron网络的状态信息的，那么这就产生了一个问题：

对于不同的Neutron Provider的plugin，就需要对每种plugin写一个十分类似的代码用来访问数据库，这样代码又多又冗杂。于是就有了ML2插件，来解决这个问题，当然，也不仅仅是因为这个原因。下面就来聊聊ML2插件吧。

ML2 Core Plugin又是个什么鬼？

ML2——Moduler Layer 2，是Neutron在H版本实现的一个新的核心插件，用来替代原来的linux bridge plugin 和open vswitch plugin。说白了，就是新的技术来了，用ML2这个核心插件换了原来的插件，一统江山了。

这就又会有两个问题：

为什么要更换核心插件？
ML2核心插件怎么用?

我们如果深究这两个问题，不难发现，这两个问题的精髓——一个涉及作用优势，另一个涉及架构原理。

我们一步一步来推究这两个问题。

1、传统Core Plugin在使用过程中出现的主要问题

第一个问题在前面已经提出了，主要是开发成本和效率的问题，这个问题其实从本质上来说就是稍加复杂罢了，倒不至于是最为核心的问题，最麻烦的是不易维护。而最为核心的是这第二个问题：对于不同的Neutron Provider来说，传统的核心插件是不支持它们共存使用的。

怎么来理解这第二个问题呢？

通过之前的了解，我们知道传统的核心插件与其代理是一一对应的，这就意味着假设选择是Linux Bridge Plugin，那么就必须使用Linux Bridge Agent,并且在OpenStack的所有节点上都必须使用Linux Bridge作为虚拟交换机作为网络提供者，OVS同样如此。

我们要知道，在生产环境中，服务器的数量和对应的角色，甚至是所处的位置都可能不一样。如果每一个节点服务器上的都必须统一为同一个网络提供者，这势必会导致一系列的问题，最容易想到的就是技术更新带来的工程量的问题。

2、ML2 Core Plugin 是怎么解决传统Core Plugin的问题的？

ML2 Core Plugin提供了一个允许在OpenStack网络中同时使用多种Layer 2 网络技术的框架，这样可以使不同的节点可以使用不同的网络实现机制。如下图所示：

透过现象看本质——谈谈ML2 plugin这回事儿

通过上图所示，在采用ML2核心插件之后，可以在不同的节点服务器上分别部署不同的Agent。并且，ML2不仅支持这样的部署方式，而且可以实现与Agent的无缝集成，也就是说，之前所使用的agent不需要更改，只需要将原来的Neutron Server上的传统的核心插件换为ML2插件即可。

这说明了两个方面：

其他节点上的Agent可以是不一样的，并且无需更改；
只需要针对ML2实现机制的原理进行研究和开发对应的功能即可（下面了解ML2的架构时再细说）；

3、瞅一瞅ML2的架构

如果需要了解ML2或者深入理解ML2的工作原理，就先要引入驱动的概念。在计算机中，驱动指的是驱动计算机里软件的程序。而在ML2中，驱动其实就是为了使ML2具备更好的弹性，易于扩展，方便而灵活地支持和访问多种网络类型及其机制的程序。

ML2对二层网络进行的抽象和建模，引入了type driver和mechansim driver，分别对应类型驱动和机制驱动。在讲述这两个驱动之前，先来瞅一眼ML2创建的架构图：

透过现象看本质——谈谈ML2 plugin这回事儿

通过这幅图，可以体现出在架构设计乃至程序设计时的解耦思想，这里补充说明一下什么是紧耦和解耦：

这两者的思想恰好相反，紧耦表示二者或二者以上之间的关联、联系非常紧密，谁离开谁，单方面都无法正常工作或提供服务；解耦的意思就是多方之间虽然互相之间有一定联系，但是并非缺少谁就不能工作，例如现在非常火的容器开发，就是基于这样的思想。这样的思想在软件开发层面比较多，在运维方面则体现在架构的设计层面。

有了直观的架构格局，再来说明一下这两类驱动：

（1）Type Driver

type driver——类型驱动，显然从上图就可以明白，Neutron支持的每一种网络类型都有与之对应的ML2的类型驱动。

类型驱动主要负责维护网络类型的状态，执行验证创建网络等。这些网络类型可以参考上一篇文章。

（2）Mechansim Driver

Mechansim Driver——机制驱动，Neutron支持的每一种网络机制都有一个对应的ML2 机制驱动。（有的可能没听说过，本文暂且忽略）

机制驱动主要负责获取由Type Driver维护的网络状态，并确保在相应的网络设备（物理或虚拟）上正确实现这些状态。

4、理一理ML2驱动工作的过程

可能，如此直白的解释不仅抽象而且无聊，还是通过一个例子来简述一下吧，也好方便理解一下ML2插件的工作过程。

假设type driver为Vlan，mechansim driver为Linux Bridge，我们需要创建一个vlan 10的网络。这个创建的过程是这样的：

vlan type driver会确保将vlan10的信息保存到Neutron数据库中，包括network的名称，vlan ID等；
对应的linux bridge 的mechanism driver会确保各节点上的linux brige agent在物理网卡上创建ID为10的vlan设备和bridge设备，并将两者进行桥接；

补充说明：

Linux Bridge Driver支持的type包括local、flat、vlan、and vxlan；
Open Vswitch Driver除了这4种type还支持gre；
L2 population driver作用是优化和限制overlay网络中的广播流量；
vxlan和gre都属于overlay网络；

结尾来一个小总结

本文将述了有关ML2核心插件的相关内容，通过问题的引出深入浅出理解neutron目前使用最为广泛的ML2核心插件。ML2插件是核心插件，替换了传统的插件，通过引入两个驱动，解决了传统核心插件带来的问题。这也体现出在架构设计中所需要考虑的问题，尤其是可扩展性方面。此外，通过本文可以了解有关驱动的作用以及理解紧耦和解耦的思想。

原文 https://blog.51cto.com/14557673/2478779

正文到此结束