Openstack 网络模块

Openstack新建云主机流程图

虚拟机创建过程：

1. 界面或命令行通过RESTful API向keystone获取认证信息。
2. keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
3. 界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。
4. nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。
5. keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。
6. 通过认证后nova-api和数据库通讯。
7. 初始化新建虚拟机的数据库记录。
8. nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
9. nova-scheduler进程侦听消息队列，获取nova-api的请求。
10. nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
11. 对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
12. nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
13. nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
14. nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）
15. nova-conductor从消息队队列中拿到nova-compute请求消息。
16. nova-conductor根据消息查询虚拟机对应的信息。
17. nova-conductor从数据库中获得虚拟机对应信息。
18. nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
19. nova-compute从对应的消息队列中获取虚拟机信息消息。
20. nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
21. glance-api向keystone认证token是否有效，并返回验证结果。
22. token验证通过，nova-compute获得虚拟机镜像信息(URL)。
23. nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
24. neutron-server向keystone认证token是否有效，并返回验证结果。
25. token验证通过，nova-compute获得虚拟机网络信息。
26. nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
27. cinder-api向keystone认证token是否有效，并返回验证结果。
28. token验证通过，nova-compute获得虚拟机持久化存储信息。
29. nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

keystone与各组件的交互

Neutron

在网络这一块，OpenStack经历了由nova-network（早期）到Quantum（F版本）再到Neutron（H版本）的演进过程。

neutron-server 接到请求 --> 将请求发送到MQ --> neotron-plugins 得到请求 --> 发送请求到MQ --> neotron-agent 建立网络设备。
neutron包含组件及功能介绍：

• neutron-server ：对外提供rest api，接收请求 并将请求分发到不同的 neutron-plugin 上。
• neutron-plugin ： 处理 Neutron Server 发来的请求，维护 OpenStack 逻辑网络的状态， 并调用 Agent 处理请求。每个厂商基于Openstack开发了模拟自己硬件的软件，这个软件就是plugin。 在早期，每个厂商开发各自的plugin，功能也是各自实现，有大量的代码是重复的；另外，不同的厂商有不同的开发标准，导致程序的兼容性很差。针对这种情况neutron-plugin 被分为了两部分：Core-plugin 和 Service-plugin 。
• Core-plugin ： Neutron中即为ML2（Modular Layer 2），负责管理L2的网络连接。ML2中主要包括network、subnet、port三类核心资源，对三类资源进行操作的REST API被neutron-server看作Core API，由Neutron原生支持。其中：
• Network ： 代表一个隔离的二层网段，是为创建他的租户而保留的一个广播域。Subnet 和 Port 始终被分配给某个特定的network。 Network 的类型包括Flat、Vlan、VxLan、Gre等等
• Subnet：代表一个IPv4/v6的CIDR地址池，以及与其相关的配置，如网关、DNS等等，该 Subnet 中的 VM 实例随后会自动继承该配置。Subnet 必须关联一个 Network。
• Port：代表虚拟交换机上的一个虚拟交换端口。VM 的网卡连接 VIF 连接Port后，就会拥有 MAC 地址和 IP 地址，Port 的 IP 地址是从Subnet 地址池中分配的。
• Service-plugin ： 即为除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要实现L3-L7的网络服务。这些plugin要操作的资源比较丰富，对这些资源进行操作的REST API被neutron-server看作Extension API，需要厂家自行进行扩展。
• neutron-agent ： 处理 Plugin 的请求，负责在 network provider 上真正实现各种网络功能。和 plugin 是一一对应的关系，

在架构设计上， Neutron沿用了OpenStack完全分布式的思想，各组件之间通过消息机制进行通信，使得Neutron中各个组件甚至各个进程都可以运行在任意的节点上，如前面的流程图所示。这种微内核的架构使得开发者可以集中精力在网络业务的实现上。目前Neutron提供了众多的插件与驱动，基本上可以满足各种部署的需要，如果这些还难以支撑实际所需的环境，则可以方便地在Neutron的框架下扩展插件或驱动。

一般而言，neutron-server和各neutron-plugin部署在控制节点或者网络节点上，而neutron agent则部署在网络节点上和计算节点上。我们先来简单地分析控制端neutron-server和neutron-plugin的工作，然后再分析设备端neutron-agent的工作。
（注意，以前厂商开发的L2 plugin跟ML2都存在于neutron/plugins目录下，而可插拔的ML2设备驱动则存在于neutron/plugins/ml2/drivers目录下）

控制端的实现：
从neutron-server的启动开始说起。neutron-server启动时，主要就干了两件事，第一是启动wsgi服务器监听Neutron REST API，第二是启动rpc服务，用于core plugin与agent间的通信，两类服务作为绿色线程并发运行。从SDN的角度来看，wsgi负责Neutron的北向接口，而Neutron的南向通信机制主要依赖于rpc来实现（当然，不同厂家的plugin可能有其它的南向通信机制）。

• 北向方面： Neutron的wsgi通过Paste工具进行模板化部署，它接收Neutron REST API的业务请求，然后通过APIRouter将其分发给对应的plugin。
• Neutron内部，plugin与数据库交互，获取业务的全局参数，然后通过rpc机制将操作与参数传给设备上的Agent（某些plugin和ML2 Mechanism Driver通过别的方式与Agent通信，比如REST API、NETCONF等）。
• RPC机制就可以理解为Neutron的南向通信机制，Neutron的RPC实现基于AMPQ模型，plugins和agents之间通常采用“发布——订阅”模式传递消息，agents收到相应plugins的***NotifyApi后，会回调设备本地的***CallBack来操作设备，完成业务的底层部署。

设备端的实现：
控制端neutron-server通过wsgi接收北向REST API请求，neutron-plugin通过rpc与设备端进行南向通信。设备端agent则向上通过rpc与控制端进行通信，向下则直接在本地对网络设备进行配置。

网络模式

根据创建网络的用户的权限，Neutron network 可以分为：

• Provider network：管理员创建的和物理网络有直接映射关系的虚拟网络。
• Tenant network：租户普通用户创建的网络，物理网络对创建者透明，其配置由 Neutorn 根据管理员在系统中的配置决定.

根据网络的类型，Neutron network 可以分为：

• Local
• Flat / Flat Dhcp
• VLan
• Gre
• VxLan
• 等等

1. Local
所有的组件全部安装在一台机器上，多用于测试环境。
2. Flat / Flat Dhcp
Flat模型最为简单，所有的虚拟机共用一个私有IP网段，IP地址在虚拟机启动时完成注入，虚拟机间的通信直接通过HyperVisor中的网桥转发，公网流量在该网段的网关上进行NAT（Nova-network实现为开启nova-network主机内核的iptables，Neutron实现为网络节点上的l3-agent）。Flat DHCP模型与Flat区别在于网桥中开启了DHCP进程，虚拟机通过DHCP消息获得IP地址（Nova-network实现为nova-network主机中的dnsmaq，Neutron实现为网络节点上的dhcp-agent）。

• 优点：结构简单，稳定
• 缺点：全部租户都在一个水平面上，租户之间没有隔离，因为全部租户都在一个子网内，当大规模部署后，其广播风暴将会是不小的负面因素。
  
  3. VLan
• LAN： 表示 Local Area Network，本地局域网，通常使用 Hub 和 Switch 来连接LAN 中的计算机。一般来说，当你将两台计算机连入同一个 Hub 或者 Switch 时，它们就在同一个 LAN 中。同样地，你连接两个 Switch 的话，它们也在一个 LAN 中。一个 LAN 表示一个广播域，它的意思是，LAN 中的所有成员都会收到 LAN 中一个成员发出的广播包。可见，LAN 的边界在路由器或者类似的3层设备。
• VLAN： 表示 Virutal LAN。一个带有 VLAN 功能的switch 能够同时处于多个 LAN 中。最简单地说，VLAN 是一种将一个交换机分成多个交换机的一种方法。比方说，你有两组机器，group A 和 B，你想配置成组 A 中的机器可以相互访问，B 中的机器也可以相互访问，但是A组中的机器不能访问B组中的机器。你可以使用两个交换机，两个组分别接到一个交换机。如果你只有一个交换机，你可以使用 VLAN 达到同样的效果。你在交换机上分配配置连接组A和B的机器的端口为 VLAN access ports。这个交换机就会只在同一个 VLAN 的端口之间转发包。

带 VLAN 的交换机的端口分为两类：

• Access port：这些端口被打上了 VLAN Tag。离开交换机的 Access port 进入计算机的以太帧中没有 VLAN Tag，这意味着连接到 access ports 的机器不会觉察到 VLAN 的存在。离开计算机进入这些端口的数据帧被打上了 VLAN Tag。
• Trunk port： 有多个交换机时，组A中的部分机器连接到 switch 1，另一部分机器连接到 switch 2。要使得这些机器能够相互访问，你需要连接两台交换机。 要避免使用一根电缆连接每个 VLAN 的两个端口，我们可以在每个交换机上配置一个 VLAN trunk port。Trunk port 发出和收到的数据包都带有 VLAN header，该 header 表明了该数据包属于那个 VLAN。因此，只需要分别连接两个交换机的一个 trunk port 就可以转发所有的数据包了。通常来讲，只使用 trunk port 连接两个交换机，而不是用来连接机器和交换机，因为机器不想看到它们收到的数据包带有 VLAN Header。