Openstack中Neutron的实现模型

栏目: 服务器 · 发布时间: 6年前

内容简介:创建ns把tap移动到对应的ns中创建bridge

一、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。

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!

网络类型 br-int br-tun
VLAN 10 ----
VXLAN 10 100
2. 转换关系的建立

前文得知,每个OVS是由OVS Agent所创建,OVS Agent将内外VID(VNI)的映射关系存储在OVS Bridge的端口表中的other_config字段中,以完成转换。

Openstack中Neutron的实现模型

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

风口上的汽车新商业

风口上的汽车新商业

郭桂山 / 人民邮电出版社 / 59

本书从互联网+汽车趋势解析、汽车电商困局突围策略、汽车后市场溃败求解等三个篇章详细阐述了作者的观察与思考,当然更多的还是作者在汽车电商行业的实践中得出的解决诸多问题的战略策略,作者站在行业之巅既有战略策略的解决方案,同时也有战术上的实施细则,更有实操案例解析与行业大咖访谈等不可多得的干货。当然,作者一向追崇的宗旨是,书中观点的对错不是最重要的,重在与行业同仁探讨,以书会友,希望作者的这块破砖头,能......一起来看看 《风口上的汽车新商业》 这本书的介绍吧!

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换