Neutron框架之流分析
1.控制端neutron-server通过wsgi接收北向REST API请求,neutron-plugin通过rpc与设备端进行南向通信。
2.设备端agent则向上通过rpc与控制端进行通信,向下则直接在本地对网络设备进行配置。
3.Neutron-agent的实现很多,彼此之间也没什么共性的地方,下面选取比较具有代表性的ovs-neutron-agent的实现进行简单的介绍。
Nova-compute向neutron-server请求虚拟机对应的Port资源。
Neutron-server根据neutron-database生成Port资源。
Neutron-server通知Dhcp agent虚拟机信息。
Dhcp agent将虚拟机信息通知给dhcp server。
虚拟机接入并启动。
虚拟机从dhcp server处获得IP地址。
(1)qbr:Linux Bridge网桥 Bridge 设备是基于内核实现的二层数据交换设备
(2)br-int:OVS网桥
(3)br-tun:OVS隧道网桥
(4)VXLAN封装:网络类型的转变
网络节点部署了Router、DHCP Server服务,网桥连接物理网卡。
(1)Router:路由转发
(2)DHCP: 提供DNS、DHCP等服务。
(3)br-ex: 连接物理网口,连接外网
计算节点的 br-int 上,Neutron 为每个虚机连接 OVS 的 access port 分配了内部的 VLAN Tag。这种 Tag 限制了网络流量只能在 Tenant Network 之内。
计算节点的 br-tun 上,Neutron 将内部的 VLAN Tag 转化为 VXLAN Tunnel ID,然后转发到网络节点。
网络节点的 br-tun 上,Neutron 将 VXLAN Tunnel ID 转发了一一对应的 内部 VLAN Tag,使得 网络流被不同的服务处理。
网络节点的 br-int 上连接的 DHCP 和 L3 agent 使用 Linux Network Namespace 进行隔离。
patch-port ovs里的不同bridge之间可以通过patch port进行连接,类似于linux的veth接口。成对出现。
TAP 设备是一种工作在二层协议的点对点网络设备,每一个 TAP 设备都有一个对应的 Linux 字符设备,用户程序可以通过对字符设备的读写操作,完成与 Linux 内核网络协议栈的数据交换工作,在虚拟化环境中经常被模拟器使用。
Neutron利用网络控制节点上的Network Namespace中的iptables,实现了进出租户网络的网络防火墙,从而保证了进出租户网络的安全性
qvo 为了实现IPtables 建立了一层中间层 qbr 用网络空间实现, br-int端为qvo
qvb 为了实现IPtables 建立了一层中间层 qbr 用网络空间实现, 近tap端为qvb
Vxlan的模型和vlan的模型十分相似,从表面上来看,他俩相比只有一个不同,vlan对应的是ethx网桥,而vxlan对应的是tun网桥。
在这里ethx和tun都是ovs网桥,所以说两者的差别不是实现组件的差别而是组件所执行功能的差别,ethx执行的是普通二层交换机的功能,tun执行的是vxlan中的vtep的功能,图中俩tun对应的接口ip就是vxlan的隧道终结点ip。所以说虚机的数据包在到达tun网桥之前是打的是vlan tag,而到达tun之后会发生网络类型的转换,从vlan封装为vxlan然后到达网络节点。而之前的vlan类型的网络,虚机数据包的类型一直都是vlan。
VTEP是直接与终端连接的设备,负责原始以太报文的VXLAN封装和解封装。
物理的二层与虚拟的二层(VLAN模式)
(1)物理的二层指的是:物理网络是二层网络,基于以太网协议的广播方式进行通信。
(2)虚拟的二层指的是:Neutron实现的虚拟网络也是二层网络(openstack的vm机所用的网络必须是大二层),也是基于以太网协议的广播方式进行通信,但毫无疑问的是该虚拟网络是依赖于物理的二层网络。
(3)物理二层+虚拟二层的典型代表:VLAN网络模式。
物理的三层与虚拟的二层(GRE模式与VXLAN模式)
(1)物理三层指的是:物理网络是三层网络,基于IP路由的方式进行通信。
(2)虚拟的二层指的是:Neutron实现的虚拟网络仍然是二层网络(openstack的vm机所用的网络必须是大二层),仍然是基于以太网的广播方式进行通信,但毫无疑问的是该虚拟机网络是依赖于物理的三层网络,这点有点类似于VPN的概念,根本原理就是将私网的包封装起来,最终打上隧道的ip地址传输。
(3)物理三层+虚拟二层的典型代表:GRE模式与VXLAN模式。
关于上图,整体的理解为:
1、首先通过dashboard或命令行CLI的形式获取用户登录信息,调用keystone的restful api去做身份验证
2、keystone对用户登录信息进行校验,然后会产生token并返回给对应的认证请求
3、然后携带着这个token通过restful api向nova-api发送一个boot instance请求
4、nova-api接受请求后会先向keystone发送token校验和权限认证请求
5、keystone校验token是否有效,并将结果返回给nova-api
6、通过认证之后nova-api会向nova-database进行通信,为新实例创建一个数据库条目
7、nova-api调用rabbit MQ,向nova-scheduler请求是否有创建虚机的资源主机
8、nova-scheduler进程监听消息队列,获取到nova-api的请求
9、nova-scheduler与nova-database交互,获取集群中计算节点的信息和状态,并通过调度算法计算出合适的计算节点(host)
10、对于符合虚拟机创建的主机,nova-scheduler更新数据库中的虚机对应的物理主机信息
11、nova-scheduler通过rpc调用向找到的那个host上的nova-compute发送创建虚机的请求,目标主机上的nova-compute会从对应的消息队列中获取到创建虚机的请求
12、nova-compute通过rpc调用向nova-conductor发送请求创建虚机的信息,如host ID,flavor等;nova-conductor从消息队列中获取到nova-compute的请求
13、nova-conductor与nova-database交互,查询到虚机的信息
14、nova-conductor把信息通过消息的形式发送到消息队列中,nova-compute从消息队列中获取到虚机信息
15、nova-compute会向glance-api请求获取虚机创建所需的镜像
16、glance-api会先向keystone验证token,并返回验证结果
17、验证通过后,nova-compute获得image数据
18、nova-compute调用neutron api,传入token,去分配和配置网络,比如虚机的IP地址等
19、neutron-server向keystone验证token是否有效,并返回结果
20、验证通过之后,nova-compute获得虚机网络信息
21、nova-compute请求cinder-api获取虚机所需要的持久化存储信息
22、cinder-api向keystone验证token是否有效,并返回结果
23、验证通过之后,nova-compute获得虚机的块存储信息
24、nova-compute根据instance信息调用配置的虚拟化驱动来创建虚拟机