盘他！openstack中neutron 插件，DHCP，Linux Bridge，Open vSwitch三个代理的基础理论！

前言

一：neutron 插件，代理与地理服务的层次结构

• neutron插件，地理服务层次结构如下：

• 今天主要介绍ML2插件和二层代理与三层代理中的DHCP

• 

二：ML2插件

2.1：诞生史

• Neutron可以通过开发不同的插件和代理来支持不同的网络技术、这是一种相当开发的架构。不过随着所支持的网络提供者种类的增加，开发人员发现两个突出的问题。一个问题是多种网络提供者无法共存。 Core Plugin负责管理和维护 Neutron二层的虚拟网络的状态信息，一个 Neutron网络只能由一个插件管理，而 Core Plugin插件与相应的代理是一一对应的，如果 Linux bridge插件，则只能选择 Linux Bridge代理，必须在 OpenStack的所有节点上使用Linux Bridge作为虚拟交换机，另外一个问题是开发插件的工作量太大，所有传统的core Plugin之间存在大量重复的代码（如数据库访问代码）
• 为了解决这两个问题，从 OpenStack的 Havana版本开始， Neutron实现一个插件ML2（ Moduler Layer2），为了取代所有 Core Plugin，允许在 OpenStack网络中同时使用多种二层的网络技术，不同的节点可以使用不同的网络实现机制，ML2能够与现在所有的代理无缝集成，以前使的代理无需变更，只要将传统的 Core Plugin替换ML2。
• ML2使得对新的网络技术支持更为简单，无须重新开发新的 Core plugin，只需要开发相应的机制驱动（ Mechansion Driver），大大减少要编写和维护的代码。

2.2：ML2插件的实现架构图

• 

2.3：架构图详解

• ML2对二层的网络进行抽象，解锁了 Neutron所支持的网络类型（Type）与访问这些网络类型的虚拟网络实现机制（ Mechansim），并通过驱动的形式进行扩展，不同的网络类型对应不同的类型的驱动（ Type Driver），由类型管理器（Typer Manager）进行管理。不同的网络实现机制对应不同的机制驱动（ Mechansiom driver），由机制管理器（ Mechansim Manager）进行管理。

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

  • 1.类型驱动（ Type Driver）

    Neutron支持的每一种网络类型都有一个对应的ML2类型驱动，类型驱动负责维护网络类型的状态，执行验证、创建网络等工作。

    目前 Neutron已经实现的网络类型包括Flat、 Local 、VLAN、 VXLAN、GRE

  • 机制驱动（ Mechansiom driver）

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

2.4：举例理解

• 类型驱动VLAN，机制驱动为 Linux Bridge，如果创建VLAN10，那么VLAN的类型驱动会确保将VLAN10的信息保存到 Neutron数据库中，包括网络的名称、 VLAN ID等，而 Linux Bridge机制驱动会确保各个节点上的 Linux Bridge代理在物理网卡上创建ID为10的VLAN设备和 Bridge设备，并将二者进行桥接。
• 目前 Neutron已经实现的网络机制有3种类型。
  • 基于代理（ Agent-based）：包括 Linux bridge、 Opens vSwitch
  • 基于控制器（ controller-Based）：包括 OpenStacDaylight、 VMWavre NSX等
  • 基于物理交换的：包括 Cisco Nexus、 Arista、 Mellanox等
• 扩展资源
  • ML2作为一个 Core Plugin，在实现网络、子网和端口核心资源的同时，也实现了包括端口绑定（ Port Bindings）、安全组（ Security Group）等部分扩展资源。

三：Linux Bridge代理

3.1：概述

• Linux Bridge是成熟可靠的 Neutron二层网络虚拟化技术，支持 Local、Flat、VLAN、VXLAN这四种网络类型，目前不支持GRE
• Linux Bridge可以将一台主机上的多个网卡桥接起来，充当一台交换机，它可以桥接物理网卡，又可以是虚拟网卡，用于桥接虚拟机网卡（虚拟机网卡）的是Tap接口，这是一个虚拟机出来的网络设备，称为Tap设备，作为网桥的一个端口，Tap接口在逻辑上与物理接口具有相同的功能，可以接收和发送数据包。

3.2：涉及到的设备解释

• 如果选择 Linux Bridge代理，在计算机节点上数据包从虚拟机发送到物理网卡需要绎过下设备。
• Tap接口（ Tap interface）：用于网桥虚拟机的网卡，命令为 tapXXX
• Linux网桥（ Linux Bridge）：作为二层交换机，命令为 brqxxxx
• VLAN接口（ VLAN Interface）：在VLAN网络中用于连接网桥，命名为 ethx.y（ethx为物理网卡名称，y为VLAN ID）
• VXLAN接口（ VXLAN Interface）：在VXLAN网络中用于连接网桥，命名为 vxlan-z（z是VNID）
• 物理网络接口：用于连接到物理网络。

3.3：举例：Linux Bridge环境下的Flat网络和VLAN网络

• 计算节点上的 Linux Bridge环境下的Flat网络和VLAN网络，下面个2个图其中网桥是核心。VLAN网络有2个VLAN有自己的网桥，实现了基于VLAN的隔离，如果改用VXLAN，其中的VLAN接口换成VXLAN接口，可以命令为vxlan101和vxlan-102
• 
• 

四：Open vSwitch代理

4.1：概述

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

4.2：Open vSwitch的设备类型

• Tap设备：用于网桥连接虚拟机网卡
• Linux网桥：桥接网卡接口（包括虚拟接口）
• VETH对（ VETH Pair）：直接相连的一对虚拟机网络接口，发送VETH对一段的数据包由另一端接收。在 Open Stack中，它用来连接两个虚拟网桥
• OVS网桥：Open VSwitch的核心设备，包括一个OVS集成网桥（ Integration Bridge）和一个OVS物理连接网桥。所有在计算节点上运行的虚拟机连接到集成网桥， Neutron通过配置集成网桥上的端口来实现虚拟机网络隔离。物理连接网桥直接连接到物理网卡。这两个OVS网络通过一个VETH对连接， Open VSwitch的每个网桥都可以看做是一个真正的交换机，可以支持VLAN。

4.3：Open vSwitch数据包流程

• 如果选择 Open VSwitch代理，在计算节点上的数据包从虚拟机发送到物理网卡需要依次经过一下设备
• Tap接口（ Tap interface）：用于网桥虚拟机的网卡，命令为 tapXXX
• Linux网桥（ Linux Bridge）：与 Linux Bridge不同，命名为qbrxxx（其中编号xx与 tapxxx中的x相同）
• VETH对：两端分别命名为qbbxx和 qvoxxx（其中编号xx与 tapxxx中的xx保持一致）
• 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为物理网卡的名称中的编号）

4.4：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端口收到一个VLAN1标记的数据包时，会将其中的VLAN1转让为VLAN101，；当 br-init网桥上的 init-br-eth1端口收到一个VLAN101标记的数据包时。会将其中的VLAN101转让为VLAN1。

• 例如：以VLAN网络为例的Open vSwitch网络的逻辑结构

• 

五：DHCP代理

5.1：主要组件

• OpenStack的实例在启动过程中能够从 Neutron提供的DHCP服务自动获取IP地址
• DHCP代理（ neutron-dhcp- agent）：为项目网络提供DHCP功能，提供元数据请求（ Metadata request）服务
• DHCP驱动：用于管理DHCP服务器，默认为 DNSmasq，这是有1个提供DHCP和DNS服务的开源软件，提供DNS缓存和DHCP服务功能。
• DHCP代理调度器（ Agent Scheduler）：负责DHCP代理与网络（ Network）的调度。

5.2：DHCP代理的主要任务

• Neutron DHCP提供两类 REST API接口：Agent Managerment Extension API和Aent Scheduler extension apl这两类API都是 extension APl， dhcp代理是核心组件，完成以下任务。
• （1）定期报告DHCP代理的网络状态，通过RPC报告给 Neutron-server，然后通过 Core Plugin报告给数据库并进行更新网络状态
• （2）启动 dnsmasq进程，检测 qdhcp-xxx名称（ Namespace）中的ns-xxx端口接收到DHCP DISCOVER请求，在启动 dnsmasq进程的过程中，决定是否需要创建名称空间中的ns-xxx端口，是否需要配置名称空间中的 iptables，是否需要刷新 dnsmasq进程所需的配置文件。名称空间下的知识点介绍。
• 创建网络（ Network）并在子网（ subnet）上启用DHCP时，网络节点上的DHCP代理会启动一个 dnsmasq进程为网络提供DHCP服务。 dnsmasq与网络（ network）是一一对应关系，一个 dnsmasq进程可为同一网络中所有启动DHCP的子网（ Subnet）提供服务

5.3：DHCP代理配置文件

• DHCP代理配置文件是/etc/ neutron/ dhcp_agent. ini其中有重要的配置选项有二个

• 

• （1） interface_driver：用来创建TAP设备的接口驱动，如果使用 Linux bridge连接，该值设为 neutron.agent. linux.interface. BridgeInterfaceDriver；如果选择 Open VSwitch，该值为neutron.agent.linux interface. OVSInterface Driver

• （2） dhcp_driver：指定DHCP启动，默认值为 neutron.agent.linux.dhcp.Dnsmasq表示dnsmasq进程来实现DHCP服务

• 

5.4：DHCP代理工作机制

• DHCP代理运行在网络节点上，DHCP为项目网络提供DHCP服务IP地址动态分配，另外还会提供源数据请求服务。工作机制如下：
• 
• 通过DHCP获取|P地址过程如下
  • 1）创建实例时， Neutron随机生成MAC并从配置数据中分配一个固定的IP地址，一起保存到 dnsmasq的 hosts文件中，让 dnsmasq进程做好准备。
  • 2）与此同时， Nova-compute会设置Mac地址
  • 3）实例启动，发出 DHCP DISCOVER广播，该广播消息在整个网络中都可以被收到
  • 4）广播消息到达 dnsmasq监听Tap接口。 dnsmasq收到后检查 hosts文件，发现有对应项，它以 DHCP OFFER消息将IP和网关IP发回到虚拟机实例
  • 5）虚拟机实例发回 DHCP REQUEST消息确认接收 DHCP OFFER
  • 4）广播消息到达 dnsmasq监听Tap接口。 dnsmasq收到后检查 hosts文件，发现有对应项，它以 DHCP OFFER消息将IP和网关IP发回到虚拟机实例
  • 5）虚拟机实例发回 DHCP REQUEST消息确认接收 DHCP OFFER
  • 6）dnsmasq发回确认消息 DHCP ACK，整个过程结束。