Openstack中Neutron的实现模型

一、Neutron概述

众所周知，整个Open stack中网络是通过Neutron组件实现，它也成为了整个Open stack中最复杂的部分，本文重点介绍Neutron的实现模型与应用场景，闲言少叙，步入正题。
1. Neutron的架构
Neutron的架构如下图所示：
Openstack中Neutron的实现模型
Neutron Serve由Core Plugins和Service Plugins组成，原生Neutron的Core Plugins使用的是ML2插件，它又分为类型驱动和机制驱动，可以提供基础的网络类型和实现机制，高级的功能如×××等通过Service Plugins实现，同时Neutron作为一个开放性的组件，允许厂商在1，2，3位置处对接自己的插件，本文采用Core Plugins的ML2插件进行说明，通过OVS重点讲述VLAN和VXLAN类型的网络。
2. Open stack部署模型
以3节点为例，Open stack由控制节点，网络节点和计算节点组成，当位于控制节点的Neutron server通过RESTful或CLI接收到请求后，会通过RPC的方式将信息传递给网络和计算节点的Agent，Agent在指挥具体的程序实现功能
Openstack中Neutron的实现模型
举例来说，当Neutron Server通过CLI接收到开启DHCP功能的指令后，会将该指令下发给DHCP Agent，DHCP Agent则通过dnsmasq这个具体程序来实现DHCP功能，L3 Agent则是由开启了转发功能的Linux内核来实现。
3. Linux网络虚拟基础
通过上文也得知Neutron本身不做具体功能的实现，此处对Neutron中经常涉及的虚拟网络设备进行说明。虚拟网络设备也称为虚拟网元，不同于现实中的物理设备，Linux中一个类似于数据结构，内核模块或设备驱动都可以称为一个设备，举例来说，一个硬盘在创建了多个分区后每一个分区在Linux下都是一个设备，通过以上概念，引出以下设备：
（1）Tap设备
Tap设备是Linux内核中二层的虚拟网络设备，只与二层中的以太网协议对应，所以常被称为虚拟以太网设备，它实现的是虚拟网卡的功能。
（2）名称空间
namespace简称ns，传统的Linux资源是全局的，ns是在一个HOST内创建了许多隔离的空间，彼此相互看不见，将全局的资源变成特定ns中独有的资源，ns可以隔离的资源有

资源	含义
uts_ns	UTS为Unix Timesharing System的简称，包含内存名称、版本、底层体系结构等信息
ipc_ns	所有与进程通信（IPC）有关的信息
mnt_ns	当前装载的文件系统
pid_ns	有关进程PID的信息
user_ns	资源配额的信息
net_ns	网络信息

具体到网络视角，每一个ns中都有一个独立的网络协议栈。
（3） veth pair
虚拟以太网接口，成对出现，可以理解为虚拟网线，数据从一头发进去会从另一头发出，连接不同的ns或者虚拟网元。
Openstack中Neutron的实现模型
（4） Bridge
虚拟交换机，即前文中的OVS或者Linux Bridge，具体实现请参考作者其他博文，本处不再赘述。
用一个示例对上述概念进行说明，如下图所示：
一个host主机内有4个ns，通过1对veth pair连接到vbridge上
Openstack中Neutron的实现模型
创建veth pair对

[root@host3 ~]# ip link add tap1 type veth peer name tap1_peer  
[root@host3 ~]# ip link add tap2 type veth peer name tap2_peer  
[root@host3 ~]# ip link add tap3 type veth peer name tap3_peer  
[root@host3 ~]# ip link add tap4 type veth peer name tap4_peer

创建ns

[root@host3 ~]# ip netns add ns1  
[root@host3 ~]# ip netns add ns2  
[root@host3 ~]# ip netns add ns3  
[root@host3 ~]# ip netns add ns4

把tap移动到对应的ns中

[root@host3 ~]# ip link set tap1 netns ns1  
[root@host3 ~]# ip link set tap2 netns ns2  
[root@host3 ~]# ip link set tap3 netns ns3  
[root@host3 ~]# ip link set tap4 netns ns4

创建bridge

[root@host3 ~]# yum install bridge-utils.x86_64 -y  
[root@host3 ~]# brctl addbr br1

把tap peer添加到对应的bridge中

[root@host3 ~]# brctl addif br1 tap1_peer  
[root@host3 ~]# brctl addif br1 tap2_peer  
[root@host3 ~]# brctl addif br1 tap3_peer  
[root@host3 ~]# brctl addif br1 tap4_peer

配置对应tap的IP地址

[root@host3 ~]# ip netns exec ns1 ip addr add 192.168.10.1/24 dev tap1  
[root@host3 ~]# ip netns exec ns2 ip addr add 192.168.10.2/24 dev tap2  
[root@host3 ~]# ip netns exec ns3 ip addr add 192.168.10.3/24 dev tap3  
[root@host3 ~]# ip netns exec ns4 ip addr add 192.168.10.4/24 dev tap4

将bridge和所有tap设备up

[root@host3 ~]# ip link set br1 up  
[root@host3 ~]# ip link set tap2_peer up  
[root@host3 ~]# ip link set tap2_peer up  
[root@host3 ~]# ip link set tap3_peer up  
[root@host3 ~]# ip link set tap4_peer up  
[root@host3 ~]# ip netns exec ns1 ip link set tap1 up  
[root@host3 ~]# ip netns exec ns2 ip link set tap2 up  
[root@host3 ~]# ip netns exec ns3 ip link set tap3 up  
[root@host3 ~]# ip netns exec ns4 ip link set tap4 up

验证结果

[root@host3 ~]# ip netns exec ns4 ping 192.168.10.1

二、Neutron的网络实现模型

1. 整体网络模型
还是以3节点为例，此时网络模型如下图所示：
Openstack中Neutron的实现模型
通过上图可以知道，在原生Open stack下，所有计算节点中的VM，如果需要访问外网，都必须经过网络节点，每1个租户都有自己的DHCP和Router，通过ns进行隔离。其中对外部网络需要特别强调：Neutron中所说的外部网络是其不能管理的网络，不一定是公网。
2. 计算节点实现模型
2.1 VLAN实现模型
本小节重点介绍计算节点的实现模型，在Neutron中数据报文有个内外转换的概念，举例说明：假设Host1节点的VM1-1与Host2节点的VM2-1都属于VLAN10，此时Neutron使用VLAN网络类型，它们之间通信的流程为：
Openstack中Neutron的实现模型
（1）VM1-1发出纯报文（VM可以接受和发送带VID的保温，在后文介绍）到qbr-xx。qbr-xx是一个Linux bridge设备，他与VM1-1之间通过tap设备连接，他们之间其实只有1个tap设备，可以理解为tap设备一半在br上一半在VM上，此处为了便于理解画了2个tap，qbr-xx的作用在于应用安全功能，原生的OVS不支持安全功能（Stateful openflow已经支持），qbr-xx与VM的数量是1:1对应。
（2）报文在进入br-int的接口时打上VID10，br-int管理着本地网络层，每个计算和网络节点上都有且只有1个br-int。
（3）报文离开br-int，此时VID为10，在br-ethx处VID转换为100，通过br-ethx离开Host1。br-ethx管理着租户网络层，即租户所创建的网络位于该层。
（4）报文经过物理交换机到达Host2，进入br-ethx，在br-ethx出口处VID由100转换成10。
（5）报文流出br-ethx出口，进入br-int，此时VID为10，在离开br-int出口时Untag，以纯以太网报文进入qbr-xx最后进入VM1-2。
2.2 VXLAN实现模型
如果Neutron的网络类型是VXLAN，他与VLAN的流程大体上相似，只是不再进行VID的转换，取而代之的是将VLAN封装为VXLAN：
Openstack中Neutron的实现模型
上图中br-tun和br-ethx都是由OVS实现，不同于br-ethx所执行的普通二层交换机功能，br-tun所执行的是VXLAN中的VTEP功能，2个IP为VXLAN的隧道终结IP。
2.3 内外VID不需要转换的情况
上文得知，VM在跨host节点通信时都需要进行内外VID的转换，但有一种情况例外，就是同一host上的相同VLAN下的VM通信时不需要经过转换：
Openstack中Neutron的实现模型
如上图中VM1-1和VM2-1都属于VLAN10，则VM1-1直接通过br-int与VM2-1进行通信，不需要在经过br-tun。
3.网络节点实现模型
从网络角度看，网络节点分为4层，前2层与计算节点几乎相同，不再赘述，网络服务层中1个网络1个DHCP Service（通过dns masq程序实现），Router由开启了转发功能的Linux内核实现，提供了SNAT和DNAT功能，每1个DHCP和Router都运行在ns中。外部网络层的br-ex一般也选用OVS，其上绑定的IP地址为FIP，为内部的VM提供DNAT功能。
Openstack中Neutron的实现模型

三、产生的疑问

通过上述的介绍可能会有人产生以下疑问：
1.不同于VXLAN的再次封装，VLAN为什么要有2个OVS（br-int和br-ethx），并且还必须经过1次VID转换。
2.无论是VID（内部）到VID（租户）还是VID到VNI，他们的对应关系是如何建立的。
以下就这两个问题进行进一步的说明。
1.VID转换的意义
前文得知，每个网络和计算节点有且只有1个br-int，内部网络又是由Neutron自行维护，同时Open stack也是允许租户同时存在多种类型的网络，比如租户同时使用的VLAN和VXLAN，假如VLAN网络类型下没有br-ethx，租户创建的VNI100按照算法转换过来VID也是10，这样VID就会在br-int上撞车，所以任何类型的网络都需要转换，这样Neutron可以做到掌控全局。还需要说明的1点是，不管你租户网络层用的那种类型的网络，本地网络层只能是1种网络类型：VLAN！