OpenStack 之 ML2详解

问题导读

1.ML2 是如何发展的？
2.ML2 与 OpenStack 节点上的 L2 agents 有什么区别？
3.ML2 的提出解决了哪两个问题？
4.ML2 框架是什么样子的？
5.ML2 采用什么样的工作方式？








OpenStack Neutron 是 OpenStack 中的网络模块，管理着虚拟的 Layer 2 至 Layer 7 网络。Neutron 中的 ML2（Module Layer 2）模块，统一管理着 Layer 2 网络的虚拟化。尽管 Neutron 支持多种 L2（Layer 2）技术，但是这些不同的 L2 技术都统一由 ML2 管理。这使得 Neutron 扩展 L2 支持极为方便，另一方面，也使得 ML2 模块较为复杂。本文将介绍 ML2 模块的代码框架以及其工作方式。



ML2 简介

尽管网络环境错综复杂，但是都遵循着 OSI（Open System Interconnection Reference Model）7 层网络模型。7 层网络模型分别是指：Layer1 物理层；Layer2 数据链路层；Layer3 网络层；Layer4 传输层；Layer5 会话层；Layer6 表示层；Layer7 应用层。更多有关 OSI 7 层网络模型的信息，可以在这里找到。

不仅在实际的物理网络环境对应 7 层网络模型，在虚拟网络环境中也是如此。尤其是虚拟环境中，更可能同时存在多种不同的 Layer 2 技术。OpenStack Neutron 作为一种 SDN（Software Defined Network），在其内部使用 ML2 模块来管理 Layer2。ML2 全称是 Modular Layer 2。它是一个可以同时管理多种 Layer 2 技术的框架。在 OpenStack Neutron 的项目代码中，ML2 目前支持 Open vSwitch，linux bridge，SR-IOV 等虚拟化 Layer 2 技术。在 Neutron 的各个子项目中，有更多的 Layer 2 技术被支持。

需要注意的是，ML2 与运行在各个 OpenStack 节点上的 L2 agents 是有区别的。ML2 是 Neutron server 上的模块，而运行在各个 OpenStack 节点上的 L2 agents 是实际与虚拟化 Layer 2 技术交互的服务。ML2 与运行在各个 OpenStack 节点上的 L2 agent 通过 AMQP（Advanced Message Queuing Protocol）进行交互，下发命令并获取信息。

ML2 的发展过程

ML2 并非是随着 OpenStack Neutron 一同诞生的，直到 Havana 版本，OpenStack Neutron 才支持 ML2。OpenStack Neutron 最开始只支持 1-2 种 Layer 2 技术，随着发展，越来越多的 Layer 2 技术被支持。而在 ML2 之前，每支持一种 Layer 2 技术，都需要对 OpenStack Neutron 中的 L2 resource，例如 Network/Subnet/Port 的逻辑进行一次重写，这大大增加了相应的工作量。并且，在 ML2 之前，OpenStack Neutron 最多只支持一种 Layer 2 技术，也就是说如果配置使用了 Open vSwitch，那么整个 OpenStack 环境都只能使用 neutron-openvswitch-agent 作为 Layer 2 的管理服务与 Open vSwitch 交互。

ML2 的提出解决了上面两个问题。ML2 之前的 Layer 2 plugin 代码相同的部分被提取到了 ML2 plugin 中。这样，当一个新的 Layer 2 需要被 Neutron 支持时，只需要实现其特殊部分的代码，需要的代码工作大大减少，开发人员甚至不需要详细了解 Neutron 的具体实现机制，只需要实现对应的接口。并且，ML2 通过其中的 mechanism drivers 可以同时管理多种 Layer 2 技术，如图 1 所示。这在后面会详细介绍。

图 1. ML2 与 Neutron L2 agents




ML2 的代码框架

本部分将会介绍 ML2 的代码框架，以及其中各个组成部分的作用。ML2 框架可以用图 2 来表示。

图 2. ML2 框架

从图 2 可以看出，ML2 主要由 ML2 plugin，extensions drivers，types drivers，mechanism drivers 和 rpc 组成。下面分别介绍各个部分。

ML2 plugin

这是所有对 Neutron 中 L2 resource 操作的入口，实现文件是 neutron/plugins/ml2/plugin.py。仅当如清单 1 所示，在 neutron.conf 文件中配置才生效。用户如果希望创建一个 Neutron Network，那么对应执行的代码将是该文件中的 ML2Plugin.create_network。

清单 1. 配置使用 ML2 plugin

[mw_shl_code=text,true]
[DEFAULT]
core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin[/mw_shl_code]extensions drivers

如前所述，网络都遵循着 OSI 7 层模型，但是并非每层之间就完全独立，例如 Neutron 中 DNS 服务与 Network 和 Port 关联。extensions drivers 就是建立 Neutron 中 L2 resource 与其他 resource 之间的联系。当创建、更新或删除 Neutron 中 L2 resource 时，对应的 extensions driver 会被执行，并更新对应的其他 resource。同时 extensions drivers 还会将其他 resource 与 Neutron L2 resource 的关联报告给 ML2 plugin，这样，用户在查看 Port 信息的时候，就能看到对应的 Security Group。extensions drivers 是一个可配置项，对应的配置信息在 ml2_conf.ini 中，如清单 2 中的 extension_drivers 所示。配置值默认为空，当需要打开某功能时，例如清单 2 中的 port_security，则需要在此处加上相应的信息，并重启 neutron-server。ML2 plugin 通过 neutron.plugins.ml2.managers.ExtensionManager 与配置了的 extension driver 交互。

清单 2. ML2 的其他配置信息

[mw_shl_code=text,true][ml2]
tenant_network_types = vxlan
extension_drivers = port_security
type_drivers = local,flat,vlan,gre,vxlan
mechanism_drivers = openvswitch,linuxbridge
[/mw_shl_code]


types drivers

物理环境中的 L2 网络类型有很多种，而在虚拟网络 OpenStack Neutron 中，也支持多种网络类型。这些网络类型的支持由 ML2 的 types drivers 来完成。当希望 OpenStack 的网络环境支持某一种或多种网络类型时，需要在清单 2 所示的 type_drivers 中进行配置。该配置项默认值是'local'，'flat'，'vlan'，'gre'，'vxlan'，'geneve'。实际上就是 ML2 内部所有支持的网络类型。清单 2 所示的配置项中没有 geneve，那么在 OpenStack Neutron 中创建 geneve 类型的网络时，Neutron 会报网络类型不支持的错误。

清单 2 所示的配置项中，tenant_network_types 也属于 types drivers 的配置项。它表示，在创建 Network 时，如果没有指定网络类型，按照该配置项的内容自动给 Neutron Network 指定网络类型。可以理解成 Neutron Network 中网络类型的缺省值。当设定多个值时，第一个可用的值将被采用。

ML2 plugin 通过 neutron.plugins.ml2.managers.TypeManager 来与配置了的 type driver 交互。

mechanism drivers

这部分是对各种 L2 技术的支持，例如 Open vSwitch，linux bridge 等等。最近流行的 OVN 也是作为一个 mechanism driver，通过 ML2 与 OpenStack Neutron 工作。有关 OVN 的更多信息，可以查看这里。mechanism drivers 也是 ML2 的一个可配置项，如清单 2 所示的 mechanism_drivers。该配置项默认值为空，当希望 Neutron 支持某个 L2 技术，例如 Open vSwitch 时，可以加上相应的配置。清单 2 中同时配置了 openvswitch 和 linuxbridge，这样 Neutron 就同时支持这两种 L2 技术。当希望支持 OVN 时，可以在这个配置项上加上 ovn。ML2 plugin 通过 neutron.plugins.ml2.managers.MechanismManager 与配置了的 mechanism driver 交互。

rpc

这是 ML2 与 L2 agents 通讯的部分，是基于 AMQP 的实现。例如，删除 Network，需要通过 rpc 通知 L2 agents 也删除相应的流表，虚拟端口等等。ML2 的 rpc 实现在 neutron.plugins.ml2.rpc。

ML2 的工作方式

本部分将介绍 ML2 内部各个部分如何工作。前面介绍过 ML2 plugin 是所有对 Neutron 中 L2 resource 操作的入口，实际上，对 ML2 中其他部分的调用，也是在 ML2 plugin 中完成的。下面通过两个常用的操作来说明一下 ML2 的工作方式。

Create Network

本部分介绍 OpenStack Neutron 中创建 Network 的流程。图 3 显示了创建 Network 的流程。

图 3. ML2 创建 Network 流程

如果在 Commit Network in DB 之前发生异常，那么 DB 不会做任何修改。从图 3 可以看出，extension drivers，type drivers 和 mechanism drivers，如果其中任何一个不能接受新创建的 Network，都会导致创建 Network 失败，并且清除在 Network 在 DB 中的记录。由于新创建的 Network 不含有任何 Port 或 Subnet，没有必要通知 L2 agents，所以在创建 Network 的过程中，没有调用 rpc 的过程。

Create Port

如果把 Neutron Network 理解成一个 Layer 2 Switch，那么 Port 就是接在这个 Switch 上的虚拟端口。图 4 显示了创建 Port 的流程。

图 4. ML2 创建

整个流程与创建 Network 类似。差别是少了调用 type drivers，因为 type drivers 针对的是 Network type 的支持，所以没有必要在 Port create 中调用。另一方面，创建 Port 会调用 rpc 通知 L2 agents，这是因为 Port 在 ML2 中还只是一个内存或者 DB 中的对象，真正在 SDN 中起作用的，是在各个 L2 agents 上的虚拟端口。ML2 通过 rpc 通知到 L2 agents，并创建相应的虚拟端口，这样，虚机，虚拟路由器，DHCP 服务等都能基于虚机端口提供网络服务。

总结

ML2 框架是一种极易扩展的框架。使用者和开发人员可以在不用改变现有 OpenStack Neutron 代码的前提下，对 ML2 进行扩展。

• 当需要增加一种与 L2 resource 相关的 Neutron resource 时，不需要修改现有的 L2 resource 代码，只需要扩展 extension drivers。
• 当需要支持一种新的网络类型时，只需要扩展 type drivers。
• 当需要支持一种新的 L2 技术时，只需要扩展 mechanism drivers。
  

同时，ML2 也是 OpenStack Neutron 中最复杂的模块之一，正确理解它的工作方式有助于了解 Neutron 的工作原理。

来源：IBM

作者：肖宏辉

正需要  多谢