【星海出品】SDN neutron (四) 流分析

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信息调用配置的虚拟化驱动来创建虚拟机