OpenStack入门之核心组件梳理（5）——Neutron篇
前言
本文将讲解OpenStack核心组件之一的Neutron组件。希望阅读本文前，建议初学者提前认知云计算、Linux操作系统、服务器群集以及OpenStack概念以及架构图。本文主要是为了自行整理有关OpenStack的相关知识理论，也是同读者分享自己对OpenStack中Neutron下面的浅解。
友情链接：下面的三篇文章对于初学者或多或少可以帮你在宏观上了解云计算以及OpenStack。
云计算浅谈
OpenStack概念以及核心组件概述
OpenStack部署节点类型和架构
一、Neutron的基本概念
1.1Neutron的前世今生
Neutron的前身是Quantum，Quantum英文为量子，Neutron英文翻译为中子，虽然笔者不知道这样来命名项目的具体原因，但从直观的感觉上就会觉得这个玩意不简单哈！
其实最初OpenStack并没有将网络组件独立出来，为之成立单独的一个核心项目，最初是一个叫做Nova-network的网络模型，这种模型非常简单，就是一种单一的平面网络，如下图所示：
但若熟悉网络知识就会发这种模式存在很大的缺点，比如：
- 单一网络有瓶颈，没有体现出云的特性（如可伸缩）；
- 难以实现租户的隔离性；
所以技术需要不断更新发展，相关的技术大佬经过思索，尝试，最后制定出一种方案——将网络服务独立出来，随后不断优化成立了Neutron项目。而Neutron的网络模型也发生了很大改变，后面会深入介绍。这里主要是体会一下技术发展的魅力，了解一下Neutron的前身与发展。
1.2 Neutron的基本概念
Neutron是OpenStack核心的项目之一，主要是提供云计算环境下的网络服务。在OpenStack中，Neutron本身采用的也是分布式架构，即由多个服务或者说功能模块来共同对外提供网络服务。Neutron的设计初衷是实现"网络即服务"，即NaaS。在设计上遵循的是基于SDN（软件定义网络）实现网络虚拟化的原则，而在其实现上采用的是linux系统的相关网络技术。
1.3 Neutron的主要作用
在OpenStack中，Neutron网络服务具体的作用是允许用户创建和管理网络对象，这里的对象指的就是网络、子网、端口等，并且这些对象可以被其他的OpenStack服务使用。
并且，Neutron为整个OpenStack环境提供网络的支持，涵盖了二层交换、三层路由转发、负载均衡、防火墙和***等网络通信技术。
此外，Neutron项目中非常值得一提的就是插件，插件的存在意味着OpenStack架构的可扩展性非常强，并且可以适应不同的网络设备，稳定工作。其中ML2算是典型代表，之后的文章也会进行介绍。
二、Neutron的基本架构
在上述给出链接的第三篇文章中，介绍了由OpenStack官网给出的关于OpenStack概念架构图以及逻辑架构图。如果细心认真看这个架构图的话，你会发现逻辑架构图中都有OpenStack中Neutron组件。笔者将之截取出来，如下图所示：
那么如何梳理理解上述的逻辑架构图？
其实，这和我们生活中一样，熟悉一个事物，或者一个人，你得先初步认识，然后有所了解，最终理解熟悉，这在我们学习中也是一样的道理。所以，先来认知理解框架中的功能模块的概念和作用。
2.1Neutron架构模块介绍
2.1.1 neutron-server
该模块是一个进程，而且是Neutron唯一主要的服务进程，一般运行于控制节点，提供相应的API（这类API一般基于REST风格原则）作为访问Neutron的入口。
2.1.2 neutron plugin
neutron 插件，由core plugins（核心插件）和service plugins（服务插件）组成。担任类似接收请求派发任务的角色。
- core plugins：提供基础的二层虚拟网络支持，包括网络、子网和端口核心资源；（之后技术和版本的更新使其发生了变化，后面会谈到）
- service plugins:指的是除了core plugins以外的其他插件，例如提供路由器、防火墙、安全组以及负载均衡等服务的支持。
2.1.3 neutron agent
neutron代理模块，负责接收消息并且执行任务的模块，与上述的neutron plugin对应，扮演的是真正处理工作的角色。
2.1.4 neutron provider
neutron网络提供者，主要作用是提供OpenStack网络服务的虚拟机或者物理网络的设备，例如Linux Bridge、OVS（Open vSwitch）（这两者也是重点）或者其他可以正常Neutron的物理交换机。
2.1.5 Queue
Queue——队列，这里是消息队列——MQ，用于Neutron各个模块之间相互的通信，一般默认的是基于Erlang语言的RabbitMQ来实现协调通信问题的。
2.1.6 neutron database
这里大家都知道是数据库，不过这是存放网络信息的数据库，默认使用的是Mariadb数据库。
好了，看完上述的内容，想必对架构中的各种模块有所了解了。那么如何将这些模块联系起来呢？
这就需要来讲述一下该架构工作时的过程，笔者将这个过程称作"看图说话"。
2.2Neutron的工作流程
这里可以通过一个例子结合上图来讲述该架构的工作原理以及整个过程。
假设现在要创建一个虚拟网络。整个流程是这样的：
（1）Neutron-server 收到要创建虚拟网络的请求，通过消息队列通知对应的插件，（先不考虑ML2）假设网络提供者（neutron provider）为OVS（Open vSwitch），那么这里的插件对应的就是OVS的插件；
（2）OVS插件收到消息后，将需要创建的虚拟网络的信息（名称、ID值等）保存到Neutron database中并通过消息队列通知运行在各个节点上的agent；
（3）agent，即代理收到消息后会在节点上创建对应设备，例如vlan设备。
三、Neutron-server分层模型讲解
本小节将详细谈一下Neutron-server服务。下图为Neutron-server的分层结构。
3.1 Neutron-server分层结构简述
Neutron-server的分层结构如上图所示，自上而下分别是：
3.1.1 Core API 和 Extension API
- Core API：对外提供管理网络（network）、子网（subnet）和端口（port）的RESTful API；
- Extension API：对外提供管理路由（router）、负载均衡（LB）、防火墙（firewall）等资源的RESTful API；
3.1.2 Common Service
- 用于认证和校验API请求；
3.1.3 Neutron Core
- Neutron-server中的核心处理程序，去调用对应的插件处理请求；
3.1.4 Core Plugin API 和 Extension Plugin API
- Core Plugin API：用于给核心处理程序调用Core Plugin的接口；
- Extension Plugin API：与给核心处理程序调用Extension Plugin的接口；
3.1.5 Core Plugin 和 Service Plugin
- 分别对应核心插件和服务插件，核心插件响应核心API，服务插件响应扩展API；
其中，核心插件主要是在数据库中维护network、subnet和port的状态，并负责调用相应的agent在network provider上执行相关操作，比如创建network；服务插件主要是在数据库中维护router、load balance、security group等资源的状态，并负责调用相应的agent在network provider上执行相关操作，比如创建router。
3.1.6 Database
数据库，用于存放对应的数据信息。
其实归根结底，Neutron-server说白了就可以理解为是API和Plugins的组合，即提供API服务和运行插件两大任务。
3.2 Neutron-server响应的流程
其实Neutron-server响应服务请求的流程并不复杂，主要可以分为以下几个步骤：
假设Neutron-server收到客户端发送的创建网络请求的案例：
1、首先，根据用户需要创建的对象调用对应的API（核心还是扩展API）；
2、对应的API响应之后将请求下发，此时需要通过Common Service进行认证校验以及授权；
3、认证和授权等操作都通过之后，交付给Neutron Core核心处理程序通过调用对应的插件类型处理请求。
四、Neutron的网络基本概念
Neutron管理的网络资源包括network、subnet和port，下面依次介绍。
4.1 network
network是一个隔离的二层广播域。Neutron支持多种类型的network，包括local、fla、VLAN、VxLAN和GRE以及Geneve。
local
local网络与其他网络和节点隔离。local网络中的instance只能与位于同一节点上同一网络的instance通信，local网络主要用于单机测试。
特点：
- 不具备vlan特性，不能对二层网络进行隔离；
- 同一个local网络的虚拟机实例会连接到相同的虚拟交换机上， 实例之间可以通信；
- 虚拟交换机没有绑定任何物理网卡，无法与宿主机之外的网络通信；
flat
flat网络是无vlan tagging的网络。flat网络中的instance能与位于同一网络的instance通信，并且可以跨多个节点。
vlan
vlan网络是具有802.1q tagging的网络。vlan是一个二层的广播域，同一vlan中的instance可以通信，不同vlan只能通过router通信。vlan网络可以跨节点，是应用最广泛的网络类型。
vxlan
vxlan是基于隧道技术的overlay网络。vxlan网络通过唯一的segmentation ID（也叫VNI）与其他vxlan网络区分。vxlan中数据包会通过VNI封装成UPD包进行传输。因为二层的包通过封装在三层传输，能够克服vlan和物理网络基础设施的限制。
vxlan和vlan相比的优势：
- 租户数量从4K增加到16M——支持数量增大；
- 租户内部通信可以跨越任意IP网络，支持虚拟机任意迁移——跨网络通信；
- 一般来说，每个租户逻辑上都有一个网关实例，IP地址可以在租户间进行复用——重复使用不冲突；
- 能够结合SDN技术对流量进行优化——支持与其他技术结合应用
gre
gre是与vxlan类似的一种overlay网络。主要区别在于使用IP包而非UDP进行封装。
不同network之间在二层上是隔离的。
4.2 Subnet
subnet是一个IPv4或者IPv6地址段。instance的IP从subnet中分配。每个subnet需要定义IP地址的范围和掩码。
4.3 Port
port可以看作虚拟交换机上的一个端口。port上定义了MAC地址和IP地址，当instance的虚拟网卡VIF（Virtual Interface）绑定到port时，port会将MAC和IP分配给VIF。
port与subnet是1对多关系。一个port必须属于某个subnet；一个subnet可以有多个port。
五、Neutron的主要功能
前文第一小节中提到有关Neutron的主要作用，的确，Neutron为整个OpenStack环境提供着网络支持，包括二层交换、三层路由、负载均衡、防火墙等等。并且Neutron提供了对应的框架，使得用户通过配置可以实现这些功能。下面简述这些功能。
5.1二层交换VSwitch
Neutron支持多种虚拟交换机，包括Linux原生的Linux Bridge和Open vSwitch。
Open vSwitch（OVS）是一个开源的虚拟交换机，它支持标准的管理接口和协议。
利用Linux Bridge和OVS，Neutron除了可以创建传统的VLAN网络，还可以创建基于隧道技术的Overlay网络，比如VxLAN和GRE（Linux Bridge目前只支持VxLAN）。
5.2三层路由VRouter
实例可以配置不同网段的IP，Neutron的VRouter（虚拟路由器）实现实例可跨网段通信。一般可以通过IP forwarding、iptables等技术来实现路由和NAT。
5.3负载均衡Load Balance
Openstack在Grizzly版本第一次引入了Load-Balancing-as-a-Service（LBaaS），提供了将负载分发到多个实例的能力。LBaaS支持多种负载均衡产品和方案，不同地实现以Plugin的形式集成到Neutron，目前默认的Plugin是HAProxy（个人理解是属于七层负载吧）。
5.4防火墙Firewall
Neutron通过下面两种方式来保障instance和网络的安全性。
- Security Group：通过iptables限制进出实例的网络包。
- Firewall-as-a-Service：FWaaS，限制进出虚拟路由器的网络包，也是通过iptables实现。
六、小结
本文主要介绍OpenStack中核心子项目之一的Neutron，Neutron项目原理内容涉及非常广，本文先针对其基础部分进行讲述，从整体上了解Neutron,对于neutron provider、neutron plugins（重点是ML2）、网络原理、相关代理（L3）等深层原理（例如Linux中的网络虚拟化，名称空间等专业词汇的理解）后面会继续更新。
本文主要讲述了其基本概念作用、核心组件介绍（着重讲述Neutron-server的响应过程）、Neutron的架构讲解以及Neutron提供的主要功能和网络类型（记住前面4种！）
谢谢阅读！