OpenStack----Neutron插件、Linux Bridge代理、Open VSwitch代理的理论知识

一、ML2插件（core plugin）

1.1、前言

Neutron可以通过开发不同的插件和代理来支持不同的网络技术、这是一种相当开发的架构。
不过随着所支持的网络提供者种类的增加，开发人员发现两个突出的问题。

• 一个问题是多种网络提供者无法共存。Core Plugin负责管理和维护Neutron二层的虚拟网络的状态信息，一个Neutron网络只能由一个插件管理，而Core Plugin插件与相应的代理是一 一对应的，如果Linux Bridge插件，则只能选择Linux Bridge代理，必须在OpenStack的所有节点上使用Linux Bridge作为虚拟交换机。

• 另外一个问题是开发插件的工作量太大，所有传统的Core Plugin之间存在大量重复的代码(如数据库访问代码)

1.2、ML2插件的出现

• 为了解决这二个问题，从OpenStack的Havana版本开始，Neutron 实现一个插件 ML2(Moduler Layer2)。

• ML2插件为了取代所有Core Plugin，允许在OpenStack网络中同时使用多种二层的网络技术，不同的节点可以使用不同的网络实现机制，ML2能够与现在所有的代理无缝集成，以前使用的代理无需变更，只要将传统的Core Plugin替换ML2插件。

• ML2使得对新的网络技术支持更为简单，无须从新开发新的Core Plugin,只需要开发相应的机制驱动(Mechansion Driver) ,大大减少要编写和维护的代码。

1.3、ML2的实现架构图

• ML2对二层的网络进行抽象，解锁了Neutron所支持的网络类型(Type)与访问这些网络类型的虚拟网络实现机制(Mechansim)，并通过驱动的形式进行扩展。

• 不同的网络类型对应不同的类型的驱动(Type Driver) ,由类型管理器(Typer Manager)进行管理。不同的网络实现机制对应不同的机制驱动(Mechansiom Driver)，由机制管理器(Mechansim Manager)进行管理。

  扫描二维码关注公众号，回复： 11166969 查看本文章

• 这种实现框架ML2具有弹性，易于扩展，能够支持多种网络类型和实现机制。

1.4、类型驱动和机制驱动

1、类型驱动 (Type Driver)

Neutron支持的每一种网络类型都有一个对应的ML2类型驱动，类型驱动负责维护网络类型的状态，执行验证、创建网络等工作。目前Neutron己经实现的网络类型包括Flat、Local、VLAN、VXLAN、GRE

2、机制驱动 (Mechansim Driver)

Neutron支持的每一种网络机制都有一个对应的ML2机制驱动。机制驱动负责获取类型驱动维护的网络状态，并确保在相应的网络设备 (物理或虚拟的)上正确实现这些状态。

举列：类型驱动VLAN，机制驱动为Linux Bridge，如果创建VLAN10，那么VLAN的类型驱动会确保将VLAN 10的信息保存到Neutron数据库中，包括网络的名称、VLAN ID等, 而Linux Bridge机制驱动会确保各个节点上的Linux Bridge代理在物理网卡上创建ID为10 的VLAN设备和Bridge设备，并将二者进行桥接。

• 目前Neutron已经实现的网络机制有3种类型。

  • 基于代理 (Agent-based) :包括Linux bridge、Open vSwitch
  • 基于控制器 (controller Based):包括OpenStacDaylight、VMWavre NSX等
  • 基于物理交换的:包括Cisco Nexus、Arista、 Mellanox 等

1.5、扩展资源

• ML2作为一个Core Plugin，在实现网络、子网和端口核心资源的同时，也实现了包括端口绑定(Port Bindings)、安全组(Security Group)等部分扩展资源。

二、Linux Bridge代理

Linux Bridge是成熟可靠的Neutron二层网络虚拟化技术，支持Local、Flat、VLAN、VXLAN这四种网络类型，目前不支持GRE。

• Linux Bridge可以将一台主机上的多个网卡桥接起来，充当一台交换机，它可以桥接物理网卡，又可以是虚拟网卡，用于桥接虚拟机网卡的是Tap接口，这是一个虚拟机出来的网络设备，称为Tap设备，作为网桥的一个端口，Tap 接口在逻辑上与物理接口具有相同的功能，可以接收和发送数据包。

2.1、Linux Bridge代理过程

如果选择Linux Bridge代理，在计算机节点上数据包从虚拟机发送到物理网卡需要经过以下设备。

• Tap接口(Tap interface)：用于网桥虚拟机的网卡，命令为tapXXX
• Linux网桥(Linux Bridge) :作为二层交换机，命令为brgxxx
• VIAN接口(VLANInterface) :在VLAN网络中用于连接网桥，命名为ethx:y(ethx为物理网卡名称，y为VLAN ID) .
• VXLAN接口(VXLAN Interface) :在VXLAN网络中用于连接网桥，命名为vyxlan-z(z是VNID)
• 物理网络接口：用于连接到物理网络。

2.2、Linux Bridge代理网络结构图

计算节点上的Linux Bridge环境下的Flat网络和VLAN网络，下面2个图中网桥是核心。

• VLAN网络有2个VLAN接口，分别有自己的网桥，实现了基于VLAN的隔离，VLAN网络的缺点：支持用户少，安全性不好。
• 基于Linux Bridge 的 flat 网络
  
• 基于Linux Bridge的VLAN网络
  

三、Open vSwitch代理

与linux Bridge相比，Open vSwitch (可简称ovs)具有几种管控功能，而且性能更加优化，支持更多的功能，目前在OpenStack领域称为主流。它支持Local、 Flat、 VLAN、VXLAN、GRE和GENEVE等所有网络类型。

3.1、Open vswitch 的设备类型

(1)、Tap设备：用于网桥连接虚拟机网卡

(2)、Linux网桥:桥接网络接口(包括虚拟接口)

(3)、VETH对(VETH Pair) :直接相连的一对虚拟机网络接口，发送VETH对一段的数据包由另一端接收。在OpenStack中，它用来连接两个虚拟网桥。

(4)、OVS网桥: Open Vswitch的核心设备，包括一个OVS集成网桥( Integration Bridge )和一个OVS物理连接网桥。所有在计算节点上运行的虚拟机连接到集成网桥，Neutron 通过配置集成网桥上的端口来实现虛拟机网络隔离。物理连接网络直接连接到物理网卡。这两个OVS网络通过一个VETH对连接，Open Vswitch的每个网桥都可以看做是一个真正的交换机，可以支持VLAN。

3.2、Open vSwitch数据包流程

如果选择Open Vswitch代理，在计算节点上的数据包从虚拟机发送到物理网卡需要依次经过一下设备。

• Tap接口(Tap interface) :用于网桥虚拟机的网卡，命令为tapxxx
• Linux网桥(Linux Bridge):与Linux Bridge不用，命名为gbrxxx (其中编号xxx与tapxxx中的x相同)
• VETH对：两端分别命名为qvbxxx和gvoxxx(其中编号xxx与tapxxx中的xxx保持一致)
• OVS集成网桥:命名为br-int
• OVS PATCH端口:两端分别命名为int-br-ethx和phy-br-ethx(x为物理网卡名称的编号)
• OVS物理连接网桥:分为两种类型，在Flat和VLAN网络中使用OVS提供者网桥(Provider Bridge)，命名为Br-ethx(x为物理网卡名称的编号)，在VXLAN、GRE和GENEVE叠加网络中使用OVS隧道网桥(Tunnel Bridge)，命名为Br-tun，另外在Local 网络中不需要任何OVS物理连接网桥
• 物理网络接口：用于连接到物理网络，命名为ethx(x为物理网卡的名称中的编号)

3.3、open vSwitch网络的逻辑结构

• 与Linux Bridge代理不同，Open vSwitch代理不通过Eth1.101、Eth1.102 等VLAN接口隔离不同的VLAN网络。

• 所有的虛拟机都连接到同一个网桥br-int，Open vSwitch通过配置br-int 和br-ethx上的流规则(Flow rule)来进行VLAN转换，进而实现VLAN之间的隔离。

• 例如：内部标签分别为1和2，而物理网络的VLAN标签是101和102，当br-eth1网桥上的phy-br-eth1端口收到一个VLAN 1标记的数据包时，会将其中的VLAN 1转让为VLAN 101，当br-int网桥上的int-br-eth1端口收到一个VLAN 101标记的数据包时。会将其中的VLAN101转让为VLAN 1。

• 下面是VLAN网络为例的Open vSwitch网络逻辑结构：

  • 基于Open vSwitch的VLAN网络
    br-eth1是桥接在物理网卡上的，也就是br-eth1是公网，那内部的br-int就相当于是内网交换机