在OpenStack中，网络服务使用Neutron-server进程提供服务API接口，用户通过Neutron-server提供的API可以进行网络插件的管理配置。
通常为了实现网络配置数据的永久性存储，网络插件要访问OpenStack的中心数据库。
Neutron-server不仅向云用户提供网络服务API，还向计算服务Nova和控制面板服务Horizon提供网络资源请求API，同时Neutron-server与Neutron插件需要访问Keystone服务以进行身份验证，而为了实现彼此交互，Neutron的服务代理与插件需要访问消息队列服务。
neutron由分布式组件组成
Neutron是一个由分布式组件构成的网络服务，其内部组件包括Neutron Server、插件代理（Plugin Agent）、DHCP代理、L3代理和计量代理（Metering Agent）等其他SDN服务、关于Neutron服务组件的功能和作用描述如下。
1) Neutron Server：Neutron Server主要运行在网络节点上，其组件包括Neutron-server服务进程和neutron-*-plugin服务，或者说Server API与插件构成Neutron Server。Neutron Server的主要作用在于对外提供OpenStack网络服务API及其扩展。API接收请求后负责调用相应的Plugin进行请求处理，而Plugin又负责调用Plugin Agent进行最终的任务处理并维护OpenStack网络逻辑状态，因此Plugin是Neutron中主要的数据库访问者。
2) Plugin Agent：插件代理是最终的网络提供者（Network Provider），即租户网络服务请求在经过Neutron Server和Plugin之后，最终通过Plugin Agent来实现租户网络请求任务。Plugin Agent(neutron-*-agent)服务主要运行在计算节点并管理本地虚拟交换机配置，用户选用的Plugin决定了计算节点所运行的Plugin Agent，因为Plugin与Agent总是相互对应的。插件代理服务需要访问消息队列以便和插件服务进行交互，同时插件代理需要访问数据库以便存储网络变更信息。因此插件代理也是Neutron中主要的数据库访问者。
3) DHCP Agent：DHCP Agent服务(neutron-dhcp-agent)主要为租户网络提供DHCP服务，DHCP Agent对于Neutron支持的全部网络Plugins都是相同的，即DHCP代理并不依赖用户选用的Plugin。DHCP Agent服务也需要访问消息队列以便同网络Plugins进行交互。
4) L3 Agent：L3 Agent在Provider类型的网络中并不是必须的，而在Self-Service网络中却是必须的。L3 Agent服务主要在外网访问租户网络中的虚拟机时提供L3 Route功能。L3 Agent也需要访问消息队列。
5) Network Provider Service：Network Provider Service又称SDN Service，即网络SDN服务，其主要作用在于向租户网络提供额外的网络服务。SDN Service通过REST APIs通信渠道与Neutron-server、Neutron-plugin和neutron-agent服务进行交互。
Neutron内部各个组件代理与Neutron Server和Plugins之间以RPC的形式进行通信，而SDN Service以REST APIs的形式访问Neutron Server和相应的插件代理。
Neutron以可插拔的模块化的Pulgins形式实现各种网络技术
为了可以实现灵活多样的OpenStack网络，Neutron以Pulgins的形式来实现各种网络技术。Neutron之所以能够处理各种网络技术和协议，主要因为Neutron包含了实现各种网络技术的插件。
从代码层面而言，插件是“可插拔(Pluggable)”的Python类和函数，这些Python类在Neutron API响应请求时被触发，同时插件在Neutron Server服务启动时加载，加载完成后插件被当成Neutron Server的一部分而运行。在Neutron中，API是Pluggable的，因此用户可以实现自己的Plugin并将其“插入”Neutron API中使用，通常不同插件实现的Neutron API是不同的。
用户对插件的实现可以是完整性(Monolithic)的也可以是模块式(Moduler)的。Monolithic意味着用户需要实现对网络进行直接或间接控制的全部核心技术，由于其实现过程较为复杂，Monolithic形式的插件正被逐步淘汰，取而代之的是Moduler插件，其中最为成功的便是Moduler Layer2，即ML2插件。
ML2插件解耦了对不同网络驱动的调用，它将驱动分为两个部分，即TyperDriver和MechanismDriver。在Neutron网络中，TyperDriver代表不同的网络隔离类型(Segmentation Type)，如Flat、Local、VLAN、GRE和VxLAN, TyperDriver负责维护特定类型网络所需的状态信息、执行Provider网络验证和租户网络分配等工作，而MechanismDriver主要负责提取TyperDriver所建立的信息并确保将其正确应用到用户启用的特定网络机制（Networking Mechanism）中。尽管ML2插件是个单一整体的插件，但是ML2插件支持多种TyperDriver和MechanismDriver，并且不同的MechanismDriver所支持的TyperDriver种类不一样，如LinuxBridge和OpevSwitch两种MechanismDriver都支持Flat、VLAN、VXLAN和GRE这4种TyperDriver，而L2 population仅支持VXLAN和GRE这2种TyperDriver，意味着在启动L2 population时，用户不能使用Flat和VLAN进行租户网络的隔离。
TyperDriver对MechanismDriver的支持矩阵
Neutron的众多插件被归为两类：Core插件和Service插件。Core插件实现的是Neutron中的Core API，其主要负责L2网络通信和IP管理，如网络、子网、子网池和端口的创建与删除。Service插件实现了Neutron中的扩展API，并负责提供三层、四层和七层的高级网络服务，如L3路由、防火墙、VPN与负载均衡等。ML2插件便是最典型的Core插件，ML2插件在Havana版本被提出，随后LinuxBridge和OpenvSwitch插件被废除，并由ML2插件来统一取代这些散乱且必须独立使用的完整性插件(Monolithic Plugins)。
自从H版本后，Neutron中已经集成ML2插件，并统一使用ML2插件来与不同的插件代理协调工作以实现各种L2层的网络技术。对比上下两张图，看到ML2插件的最大优势了吧：可以并行使用不同开源软件和厂商的网络技术以实现复杂的数据中心网络。
但是，使用ML2插件后，Plugin必须与Agent一一对应的硬性要求被屏蔽，即ML2插件可与多个Agent协同工作，因此用户便可在不同的节点上使用不同的Agent来实现各自的内网机制。Neutron Server中启用ML2插件，主机A使用的是LinuxBridge Agent，主机B使用的是Hyper-V Agent，而主机C和D使用的是Open vSwitch Aagent。
ML2插件的优势还在于减少新插件的开发工作量。以往新插件的开发需要从底层开始实现各种网络协议，其开发工作量非常巨大。
在Neutron中，Neutron Server服务扮演的是网络控制中心的角色（通常Neutron Server服务也会部署在控制节点上），而实际上与网络相关的命令和配置主要在网络节点和各个计算节点上执行，位于这些节点上的Agents便是与网络相关命令的实际执行者，而Agents可以划分为L2 Agents与非L2 Agents两大类，如OpenvSwitch agent、LinuxBridge Agent、SRIOV nic switch Agent和Hyper-V Agent等属于L2 Agents。L2 Agents主要负责处理OpenStack中的二层网络通信，是Neutron网络中最为核心的部分。非L2 Agents主要包括L3 Agent、DHCP Agent和Metadata Agent等。L3 Agent负责L3层服务，如路由和FloatingIP; DHCP Agent负责Neutron网络的DHCP服务，Metadata Agent允许用户实例通过网络访问Cloud-init元数据和用户数据。Agents所获取的消息或指令来自消息队列总线，并且由Neutron Server或Plugins发出。
ML2插件协同OpenvSwitch Agent的工作流程
Neutron Server接收到客户端的API请求后，触发ML2插件进行请求处理，由于ML2插件已经加载了OVS Mechanism Driver (也叫ovs驱动或OpenvSwitch插件)，于是ML2插件将请求转发给OVS驱动，OVS驱动收到请求后用请求中可用信息创建RPC消息，RPC消息以Cast形式投递到计算节点上特定的OVS Agent，计算节点上的OVS Agent接收到消息后便开始配置本地OpenvSwitch交换机实例。疑问：不是plugin和plugin agent一起嘛?怎么中间又多出来一个驱动?这里表述有些问题，实际上是M12包括TyperDriver和MechanismDriver。
在ML2插件中，各种L2 Agent与ML2插件的Mechanism Driver有着特定的对应关系，即用户在ML2插件配置时选用了特定的Mechanism Driver后，相应的计算节点或网络节点上应该运行特定的Agent。如在配置ML2插件的Mechanism Driver参数时，指定了OVS(代表OpenvSwitch)，则计算节点和网络节点上只能部署和运行Neutron-OpenvSwitch-agent服务。
Mechanism Drivers与L2 Agent
MacVTap & MacVTap Agent不支持L3 Agent和DHCP Agent，意味着用户在ML2插件配置时选择了使用MacVTap这个Mechanism Driver，并在计算节点/网络节点部署了MacVTap Agent，则该Neutron网络中不能使用L3服务和DHCP服务。待确定最新的DVS(Distributed vSwitch)是否支持L3 Agent和DHCP agent?
总结：Neutron内部结构剖析图
Neutron内部结构剖析图
个人学到的点：neutron的分布式组件有哪些？组件间以什么方式通信?完整性的插件如何被淘汰?取而代之的是模块化的可插拔的插件。后面还想知道插件agent如何实现各种网络技术? ML2插件解耦了对不同网络驱动的调用，体会解耦的好处。两大类插件agent的L2 Agent和非L2Agent负责的功能。
笔记整理来自山金孝的《OpenStack高可用集群（上册）：原理与架构》9.2.1和9.2.2章节，如有侵权请通知删除
网友评论