一、Neutron概述

众所周知,整个Open stack中网络是通过Neutron组件实现,它也成为了整个Open stack中最复杂的部分,本文重点介绍Neutron的实现模型与应用场景,闲言少叙,步入正题。
1. Neutron的架构
Neutron的架构如下图所示:
Open stack生产环境中几种常见的网络结构
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在指挥具体的程序实现功能
Open stack生产环境中几种常见的网络结构
举例来说,当Neutron Server通过CLI接收到开启DHCP功能的指令后,会将该指令下发给DHCP Agent,DHCP Agent则通过dnsmasq这个具体程序来实现DHCP功能,L3 Agent则是由开启了转发功能的Linux内核来实现。
3. Linux网络虚拟基础
通过上文也得知Neutron本身不做具体功能的实现,此处对Neutron中经常涉及的虚拟网络设备进行说明。虚拟网络设备也称为虚拟网元,不同于现实中的物理设备,Linux中一个类似于数据结构,内核模块或设备驱动都可以称为一个设备,举例来说,一个硬盘在创建了多个分区后每一个分区在Linux下都是一个设备,通过以上概念,引出以下设备:
(1)Tap设备
Tap设备是Linux内核中二层的虚拟网络设备,只与二层中的以太网协议对应,所以常被称为虚拟以太网设备,它实现的是虚拟网卡的功能。基于TAP驱动,即可以实现虚拟网卡的功能,虚拟机的每个vNIC都与hypervisor中的一个TAP设备相连。当一个TAP设备被创建时,在Linux设备文件目录下生会生成一个对应的字符设备文件,用户程序可以打开普通文件一样打开这个文件进行读写。当对这个TAP设备文件执行write()操作时,对于Linux网络子系统来说,相对于TAP设备收到了数据,并请求内核接受他,Linux内核收到此数据后将根据网络配置进行后续处理,处理过程类似于普通的物理网卡从外界收到数据。(VM向外发数据)。当用户程序执行read()请求时,相对于向内核查询TAP设备上是否有数据需要被发送,有的话则取出到用户程序里,从而完成TAP设备发送数据的功能。(VM接收数据)。在这个过程中,TAP设备可以被当做本机的一个网卡,而操作TAP设备应用程序相对于另外一台VM,它通过read/write系统调用,和本机进行网络通信。
(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
VETH设备总是成对出现,送到一端请求发送的数据总是从另一端以请求接收的形式出现。创建并配置正确后,向其一端输入数据,VETH会改变数据的方向并将其送入内核网络子系统,完成数据的注入,而在另一端则能读到此数据。可以理解为虚拟网线,数据从一头发进去会从另一头发出,连接不同的ns或者虚拟网元。
Open stack生产环境中几种常见的网络结构
(4) Bridge
虚拟交换机,即前文中的OVS或者Linux Bridge,具体实现请参考作者其他博文,本处不再赘述。
用一个示例对上述概念进行说明,如下图所示:
一个host主机内有4个ns,通过1对veth pair连接到vbridge上
Open stack生产环境中几种常见的网络结构
创建veth pair,中间隐含着一个事实,即veth和veth_peer之间有一条虚拟的链路将两块网卡连接起来,就好像一条双绞线连接的两块物理网卡一样。

[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节点为例,此时网络模型如下图所示:
Open stack生产环境中几种常见的网络结构
通过上图可以知道,在原生Open stack下,所有计算节点中的VM,如果需要访问外网,都必须经过网络节点,每1个租户都有自己的DHCP和Router,通过ns进行隔离。其中对外部网络需要特别强调:Neutron中所说的外部网络是其不能管理的网络,不一定是公网。
2. 计算节点实现模型
2.1 VLAN实现模型
本小节重点介绍计算节点的实现模型,在Neutron中数据报文有个内外转换的概念,举例说明:假设Host1节点的VM1-1与Host2节点的VM1-2都属于VLAN10,此时Neutron使用VLAN网络类型,它们之间通信的流程为:
Open stack生产环境中几种常见的网络结构
(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:
Open stack生产环境中几种常见的网络结构
上图中br-tun和br-ethx都是由OVS实现,不同于br-ethx所执行的普通二层交换机功能,br-tun所执行的是VXLAN中的VTEP功能,2个IP为VXLAN的隧道终结IP。
2.3 内外VID不需要转换的情况
上文得知,VM在跨host节点通信时都需要进行内外VID的转换,但有一种情况例外,就是同一host上的相同VLAN下的VM通信时不需要经过转换:
Open stack生产环境中几种常见的网络结构
如上图中VM1-1和VM2-1都属于VLAN10,则VM1-1直接通过br-int与VM2-1进行通信,不需要在经过br-tun。
3.网络节点实现模型
从网络角度看,网络节点分为4层,前2层与计算节点相同,不再赘述,网络服务层中1个网络对应1个DHCP Service(通过dnsmasq程序实现),Router由开启了转发功能的Linux内核实现,提供了SNAT和DNAT功能,每1个DHCP和Router都运行在ns中。外部网络层的br-ex一般也选用OVS,其上绑定的IP地址为FIP,为内部的VM提供DNAT功能。
Open stack生产环境中几种常见的网络结构

三、产生的疑问

通过上述的介绍可能会有人产生以下疑问:
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!

网络类型 br-int br-tun
VLAN 10 ----
VXLAN 10 100

2.转换关系的建立
前文得知,每个OVS是由OVS Agent所创建,OVS Agent将内外VID(VNI)的映射关系存储在OVS Bridge的端口表中的other_config字段中,以完成转换。
Open stack生产环境中几种常见的网络结构