一、Neutron基本架构
- OpenStack中Neutron采用分布式架构，由多个组件（服务）共同对外提供服务，Neutron架构灵活，层次多。一方面是为了支持各个现有或者将来会出现得先进的网络技术，另外一方面支持分布式部署，获得足够的扩展性
- Neutron仅由一个主要的服务进程Neutron-server，它运行于控制节点
- Neutron-server对外提供Openstack网络API作为Neutron的入口，收集请求后调用plugin（插件）进行处理，最终由计算节点和网络节点上的各种agent（代理）完成请求
- network-provider（网络提供者）是指提供OpenStack网络服务的虚拟机或者物理网络设备，比如Linux Brigde、Open vSwitch或者其他支持neutron的物理交换机。与其他的五福一样，Neutron的各个组件服务之间需要相互协调通信，Neutron-server、插件之间通过消息队列（默认用RabbitMQ实现）进行通信和相互协调
- Neutron-database（数据库，默认使用MariaDB）用于存放OpenStack的网络状态信息，包括网络、子网、端口、路由器等
- Client（客户端）是指使用Neutron服务的应用程序，可以是命令行工具（脚本）、Horizon和Nova计算服务等
创建一个Vlan10的虚拟网络过程
1.Neutron-server收到创建网络（Network）的请求，通过消息队列通知已注册的Linux brige插件，假设网络提供者为Linux Bridge
2.该插件将要创建的网络信息保存到数据库中，并且通过消息队列通知各个运行的节点代理
3.代理收到信息后会在节点上的物理网卡创建vlan设备，并且创建一个网桥来桥接网络设备
二、Neutron-server解析
- neutron-server其作用是提供一组API来定义网络连接和IP地址，供Nova等客户端调用，其本身也是分层模型
- Resetful API：是直接对接客户端API服务，属于最前端的API，包括核心接口和扩展接口两种类型。
- Core API提供管理网络、子网、端口等核心资源
- Extension API提供给网络管理路由器、负载均衡、防火墙、安全组等扩展资源
- common service：通用服务，负责对API请求进行校验、认证、并且提供授权
- Neutron cron：核心处理程序，是调用相应的插件API来处理API的请求
- Plugin API：定义插件的抽象功能集合，提供调用通用插件的API接口，包括核心插件接口、扩展插件接口。Neutron cron通过cron plugin API调用相应的Core plugin，通过扩展插件接口调用相应的service plugin
三、插件、代理与网络提供者
- 插件是Neutron的一种API的后端实现，目的是增强扩展性。插件按照功能可分为CorePlugin和Service Plugin两种类型。Core Plugin提供基础二层虚拟机网络支持，实现网络、子网和端口核心资源的支持。Service plugin是指Core Plugin之外的其他插件，提供路由器、防火墙、安全组、负载均衡等服务支持,值得一提的是， 直到OpenStack的Havana版本，Neutron才开始提供一个名为L3 RouterService Plugin的插件支持路由服务。
- 插件由Neutron-server 的Core Plugin API和Extension Plugin API调用，用于确定具体的网络功能，要配什么样的网络，插件处理Neutron-Server发来的请求，主要职责是在数据库中维护Neutron网络的状态信息(更新Neutron数据库)，通知相应的代理实现具体的网络功能。每一个插件支持一组API资源并完成特定操作，这些操作最终由插件通过RPC调用相应的代理(Agent)来完成。
- 代理处理插件转来的请求，负责在网络提供者上真正实现各种网络功能。代理使用物理网络设备或者虚拟化技术完成实际的操作任务，如用于路由具体操作L3 Agent。
- 插件和代理与网络提供者配套使用，比如网络提供者是Linux Bridge，就需要使用LinuxBridge的插件和代理，如换成OpenySwitch,泽需要改成相应的插件和代理。
ML2插件的发展
Neutron可以通过开发不同的插件和代理来支持不同的网络技术、这是一种相当于开发的架构。不过随着所支持的网络提供者种类的增加,开发人员发现两个突出的问题。
一个问题是多种网络提供者无法共存。Core Plugin负责管理和维护Neutron二层的虚拟网络的状态信息,一个Neutron网络只能由一个插件管理 ,而Core Plugin插件与相应的代理是一一对应的，如果Linux Bridge插件，则只能选择Linux Bridge代理,必须在OpenStack的所有节点上使用Linux Bridge作为虚拟交换机。
另外一个问题是开发插件的工作量太大，所有传统的CorePlugin之间存在大量重复的代码(如数据库访问代码)
为了解决这二个问题，从OpenStack的Havana 版本开始，Neutron 实现一一个插件ML2(Moduler. Layer2)为了职代所有Core Plugin,允许在OpenStacks网络中同时使用多种二二层的网络技术，不同的节点可以使用不同的网络实现机制，ML2能够与现在所有的代理无缝集成，以前使用费的代理无需变更，只要将传统的Core Plugin替换ML2,
四、Neutron的物理部署
- Neutron与其他OpenStack服务组件系统工作，可以部署在多个物理主机节点上，主要涉及控制节点、网络节点计算节点，每个节点可以部署多个,典型的主机节点部署介绍如下
- 控制节点和计算节点上的部署
控制节点上部署Neutron-service (API)、Core Plugin和Service Plugin的代理，这些代理包括neutron-plugin -agent、neutron-me dadata-agent neutron-dhcp-a gnet、neutron-l3-agent、neutron-lbaas-agent等。Core plugin和service plugin已经集成到neutron-server中，不需要运行独立的plugin服务。
计算节点上可以部署Core Plugin、Linux Bridge或Open ySwitch的代理，负责体提供二层的网络功能。
控制节点和计算节点都需要部署CorePlugin的代理，因为控制节点与计算节点通过该代理才能建立二层连接。
- 控制节点和网络节点上的部署
可以通过增加网络节点承担更大的负载，该方案特别适合规模较大的OpenStack环境控制节点部署Neutron-server服务，只负责通过Neutron-server响应的API请求。（水平扩展）
网络节点部署的服务包括Core Plugin的代理和se rvice Plugin的代理。将所有的代理从上述控制节点分离出来，部署到独立的网络节点上，由独立的网络节点实现数据的交换，路由以及负责均衡等高级网络服务。
