多机环境下虚机网络实现机制（一）

— 创建虚机时的网络配置

1、neutron服务回顾

1.1、neutron server

neutron server: 对收到的 rest api 请求进行解析，并最终转换成对该 plugin(core or service) 中相应方法的调用，启动后，根据配置文件动态加载对应的core plugin 和 service plugin。

Neutron-server可以理解为一个专门用来接收Neutron REST API调用的服务器，然后负责将不同的rest api分发到不同的neutron-plugin上。

1.2、plugins

plugin主要用来帮助实现neutron server发来的API请求，主要分为core plugin和service plugin。

core plugin

core plugin实现了对标准API的支持（network，subnet，port），这里主要指ml2 plugin。

  • network:代表一个隔离的二层网段，是为创建它的租户而保留的一个广播域。subnet和port始终被分配给某个特定的network。Network的类型包括Flat，VLAN，VxLAN，GRE等等。
  • subnet:代表一个IPv4/v6的CIDR地址池，以及与其相关的配置，如网关、DNS等等，该subnet中的 VM 实例随后会自动继承该配置。Sunbet必须关联一个network。
  • port: 代表虚拟交换机上的一个虚机交换端口。VM的网卡VIF连接 port 后，就会拥有 MAC 地址和 IP 地址。Port 的 IP 地址是从 subnet 地址池中分配的。

ML2 plugin作为L2的总控，其实现包括Type和Mechanism两部分，每部分又分为Manager和Driver。Type指的是L2网络的类型（如Flat、VLAN、VxLAN等），与厂家实现无关。Mechanism则是各个厂家自己设备机制的实现，如下图所示。当然有ML2，对应的就可以有ML3，不过在Neutron中L3的实现只负责路由的功能，传统路由器中的其他功能（如Firewalls、LB、VPN）都被独立出来实现了，因此暂时还没有看到对ML3的实际需求。

service plugin

  • service plugin：用来实现extension API，包括路由服务，防火墙，VPN等,Service-plugin，即为除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要实现L3-L7的网络服务。这些plugin要操作的资源比较丰富，对这些资源进行操作的REST API被neutron-server看作Extension API，需要厂家自行进行扩展。

neutron server启动的时候会启动一个core plugin和多个service plugin Neutron-plugin可以理解为不同网络功能实现的入口，各个厂商可以开发自己的plugin。Neutron-plugin接收neutron-server分发过来的REST API，向neutron database完成一些信息的注册，然后将具体要执行的业务操作和参数通知给自身对应的neutron agent。

1.3、agent

neutron agent主要是做为plugin的后端，通过RPC远端接受plugin的命令来对本地网络资源的操作，并将结果通过call back反馈给plugin。功能分为两大类：其一就是和plugin之间的rpc消息处理，用于和plugin进行交互，接受plugin命令等，调用plugin方法并汇报状态信息等；其二就是对本地资源进行操作，包括iptables的表项，配置dhcp服务等。

  • ml2 core agent：提供l2功能，该agent可以装在计算节点和网络节点上
  • dhcp agent：提供对虚机的dhcp管理和分配，可以安装在任意的节点上
  • l3 agent: 提供路由服务（iptables规则的配置），可以安装在任意的节点上
  • other agent：提供其他的网络服务，比如metadata、metering等。

1.4、drivers

通过被agent的调用，来具体实施网络操作。

2、vm启动时网络配置过程

2.1、openstack组件之间的协作

大致描述

  • Nova-compute向neutron-server请求虚拟机对应的Port资源
  • Neutron-server根据neutron-database生成Port资源。
  • Neutron-server通知Dhcp agent虚拟机信息。
  • Dhcp agent将虚拟机信息通知给dhcp server。
  • 虚拟机接入并启动。
  • 虚拟机从dhcp server处获得IP地址。

主要进程

  • Nova-compute向neutron-server发送create_port的REST API请求，生成新的Port资源。
  • Neutron-server收到该REST请求，通过APIRouter路由到ML2的create_port方法。该方法中，获得了neutron-database新生成的Port，并通知ML2 Mechanism Driver该Port的生成。
  • Nova-compute向neutron发送update_port的REST API请求
  • Neutron-server收到该REST请求，通过APIRouter路由到ML2的update_port方法。该方法中，在neutron-database更新该Port的状态，并根据ML2 Mechanism Driver的不同，决定后续的处理：若Mechanism Driver为hyperv/linuxbridge/ofagent/openvswitch，则需要通过ML2的update_port方法中执行rpc远程调用update_port；对于其余的Mechanism Driver，ML2的update_port方法调用其的update_port_postcommit方法进行处理，这些Mechanism Driver可能使用非rpc方式与自身的agent通信（如REST API、Netconf等）。
  • ML2执行完update_port方法后，Port资源在wsgi中对应的Controller实例通过DhcpAgentNotifyAPI实例rpc通知给网络节点上的dhcp agent（也可能通过一些调度机制通知给分布在计算节点上的dhcp agent）。
  • Dhcp agent收到该rpc通知，通过call_driver方法将虚拟机MAC与IP的绑定关系传递给本地的DHCP守护进程Dnsmaq。
  • Nova-compute通过libvirt driver的spawn方法将虚拟机接入网络，然后启动虚拟机。 到这里，虚拟机启动过程中的网络处理就都结束了，虚拟机间就可以开始通信了。