OpenStack入门之核心组件梳理（2）——Nova篇
前言
上篇文章我们从概念到原理，层层递进深入讲述了Keystone项目，而本文旨在继续介绍OpenStack核心组件之一的Nova组件项目。
相对于Keystone项目，Nova项目是作为OpenStack这个大开源项目最早也是最成熟的项目，从这一层面上也体现出Nova项目所提供的计算服务从始至终都是OpenStack最为核心的部分，笔者在之前的文章中谈到OpenStack这一开源项目所提供和管理的三大资源就是计算、网络和管理。这同样也是云计算的核心部分。
从笔者个人理解和观点来看的话，对于OpenStack而言，其真正的灵魂（可以理解为OpenStack中组件的复杂程度、使用概率以及故障出现概率等方面）一是在于宏观（这里“宏观的意思是相对早期版本的OpenStack平台而言”）的Nova（计算服务），二是在于相对其他服务最为复杂的Neutron网络服务（之后的文章也会针对该组件进行详细介绍），这里不包括CEPH分布式存储，因为CEPH本身就是可以认为是一个独立的大项目，其作用不仅仅是OpenStack中Swift（对象存储服务）的高效分布式集群存储的替代，还包括与其他技术的结合和支持等作用。但是无论在实验环境还是生产环境部署OpenStack云平台基本上选择CEPH作为分布式存储服务，当然在此个人补充一下，若是要进行OpenStack实验环境部署的话，对PC所配的硬件资源要求还是比较高的，包括CPU、内存、存储（最好是SSD），笔者所配的基础硬件资源是i79代CPU、32G内存（三级缓存达到9M）、1T的SSD M.2接口的固态盘，网络是家用百兆宽带，当然在实验环境中未必需要过高的配置，可以相对降低一些要求，不过如果要想体验感较好的话还是高配比较好，如果是决定从事这一方向的工作人员，可以购置服务器来模拟生产环境，这对初学者并不推荐哈。
闲话就不再多说了，接下来笔者将从其概念概述、主要组件、架构模式、工作原理四个方面介绍Nova项目。
一、Nova概述与发展
1.1 Nova概念介绍
Nova项目，作为OpenStack核心项目，提供着十分重要的计算服务，虽说在其发展过程中，部分核心组件在后来独立成为其他的核心项目及服务，但是Nova自身的核心地位也是非常之高的，因为了解OpenStack基础理论的朋友都知道OpenStack作为一种IaaS（基础设施即服务）的云计算服务，其最为核心的服务资源就是计算、存储和网络，而计算服务居于首位，在OpenStack云平台部署上，则正是通过Nova项目实现其计算服务的。
之所以前言部分从宏观角度说Nova项目对于OpenStack是最核心也的项目之一是有其具体原因的。在早期的OpenStack版本中，项目并不是一次规划好的，而Nova项目在初期就将存储和网络包含于自身，及nova-volume和nova-network模块，即后期独立出的Cinder(块存储服务)和Neutron（网络服务）。
1.2 Nova发展历程及具体作用
Nova项目从最初为云供应商提供实现IaaS服务的解决方案的初衷，到如今聚焦于大规模可扩展、高可用、可弹性伸缩服务和自助服务的目标，Nova一直在被优化改进升级。在2010年OpenStack项目成立之初，Nova项目主要分为Nova-Compute、Nova-volume和Nova-network三大功能模块。在2012年9月OpenStack的Folsom版本发行时，OpenStack社区才将Nova-volume和Nova-network独立出来分别构建了Cinder和Quantum项目（后因商标原因更名为Neutron项目）。
综上而言，Nova作为核心项目，在Linux服务器上作为一组守护程序运行。当然也需要依赖其他服务从而实现功能，下面讲解原理会着重介绍。其具体的功能主要是：负责管理实例虚拟机的生命周期、网络管理、存储卷管理。Nova支持创建虚拟机、裸机服务器（通过使用ironic），并且Nova计算资源的使用限额以项目为单位进行限制。
二、Nova的主要组件
Nova同Keystone一样，有组成自身的功能模块。其是由负责不同功能的服务进程构成，Nova对外提供的服务接口为REST API，其内部组件模块之间的通信基于RPC（远程过程调用）消息传递机制的。
下面来看一下组成Nova的一些主要组件：
2.1 Nova-API
Nova API服务组件。接收并响应最终用户的计算API调用请求，当其接收到请求后，通常将请求转发给Nova的其他组件进行处理，例如Nova-scheduler。
其遵循特定的策略并初始化大部分的编排操作，例如创建实例。
2.2 Nova-API-Metadata
Nova API服务组件。Nova-API-Metadata服务主要是用于接收来自实例的元数据请求。
2.3 Nova-Compute
Nova核心服务组件。Nova-Compute是一个通过Hypervisor API创建和终止实例的工作进程（在后面的架构中将涉及Hypervisor）。先前笔者对OpenStack节点类型介绍过程中有所提及，当时考虑到理解程度问题，没有细说。这里做一下详细说明。
在我们部署OpenStack的计算服务时，通常选择将Nova-Compute单独部署在支持虚拟化的物理服务器上，我们将这个物理服务器称作为计算节点。而常见的Hypervisor API有支持KVM/QEMU虚拟化引擎的Libvirt API、适用于XenServer / XCP虚拟化引擎的XenAPI以及支持VMware虚拟化引擎的VMware API。一般情况下，OpenStack默认使用的是KVM虚拟化引擎，因此在Nova-Compute中最常用的还是Libvirt API。
总之，Nova-Compute主要功能就是接收来自消息队列的请求，然后执行对应的系统命令的。例如启动KVM实例并更新其在数据库中的状态。
2.4 Nova-Scheduler
Nova核心服务组件。主要负责从队列中获取虚拟机实例请求，并确定其在哪台计算节点主机上运行。其采用的是过滤计算节点算法，即根据计算节点的CPU、内存和磁盘等参数进行筛选过滤。用户也可以通过自定义编辑nova.conf文件来指定过滤算法。
2.5 Nova-Conductor
Nova核心服务组件。Nova-Conductor 主要是为了使Nova-Compute服务与数据库（云数据库）之间进行交互。也就是说，有了Nova-Conductor，在实际运行中，消除了Nova-Compute服务对云数据库的直接访问，而是通过Nova-Conductor实现对数据库的访问。
此外，该组件支持水平扩展到多个节点上同时运行（Nova在水平扩展时采用的是Cell的部署方式），但是不能将之部署到运行Nova-Compute的计算节点上，否则无法实现Nova-Compute与数据库之间的隔离。
2.6 Nova-placement-api
主要追踪每个提供者的库存和使用量情况，比如追踪计算节点的资源，存储池的使用情况以及IP的分配情况等等。
2.7Nova-Cert
Nova核心服务组件。Nova-Cert是服务器守候进程，主要为基于X509认证的Nova Cert提供服务。
2.8 Nova-NoVNCproxy
属于虚拟机控制台服务。主要是提供用于通过VNC连接访问正在运行的实例的代理。支持基于浏览器的NoVNC客户端。
2.9 Nova-Spicehtml5proxy
属于虚拟机控制台服务。主要提供用于通过SPICE连接访问正在运行的实例的代理。支持基于浏览器的HTML5客户端。Spice是Redhat开源虚拟化桌面的主要组件之一，能够提供与物理桌面完全相同的最终用户体验，Open-Stack官方文档默认使用的虚拟机桌面访问方式为NoVNC，如果用户需要开启SPICE协议，则需要将NoVNC关闭。
2.10 QUEUE
Nova之外的核心组件。组件进程间消息交换传递的中心，一般用RabbitMQ实现。
2.11 Datebase
Nova之外的核心组件。存储基础架构中对象的创建时和运行时的状态，包括：
- 可用的实例类型；
- 使用中的实例；
- 可用网络；
- 项目。
从理论上讲，OpenStack Compute可以支持SQLAlchemy支持的任何数据库。常见的数据库是用于测试和开发工作的SQLite3，MySQL，MariaDB和PostgreSQL。
温馨提示：对于初学者理解Nova组件，重点在于理解前面的6个组件。
三、Nova的架构理解
3.1 Nova逻辑架构图梳理
上两小节主要介绍了Nova项目的概念作用以及组成，本小节来看一下这些组成之间的联系，即Nova的逻辑架构示意图。
该架构图表示的是OpenStack 提供的计算服务，该服务是由Nova项目的各个功能组件模块一起支持的。
其中大部分组件在上一小节进行了介绍，其中，nova-consoleauth也是属虚拟机控制台的服务，主要为虚拟机控制台连接提供认证授权服务的，万万不要将其与右上角的nova-console混淆，nova-console是XenAPI风格的控制台服务，对于多数VNC代理软件，该组件几乎不再使用。
针对上图可能对其中右下角的Hypervisor有所迷惑。同上文提及的Cell一样，这里不可能三言两语将这两者解释清楚，笔者在这里主要针对其作用进行说明。
Hypervisor呢，是运行于物理服务器和操作系统之间的软件层，主要是调度客户机系统对共享的物理硬件资源的使用请求，是虚拟化的基础，也是云计算的核心基础。所以上述的Nova-Compute组件就是依赖于Hypervisor API的调用来实现实例的创建以及终止的。
而cell呢，该功能模块主要是为了解决大规模Nova计算节点部署过程中的集群瓶颈问题，该问题涉及到传统集群架构与云计算架构之间的区别了，有兴趣的朋友可以进行资料查阅。该问题就是共享消息队列系统的性能在大规模的计算节点部署集群（上百个，500个以上）大大降低。而有了Cell模块，就基具备支持OpenStack计算节点水平扩展和大规模部署的能力，本文重点并不再次，关于Cell的具体原理和实现的过程在这里就不做详细介绍了。
此外，通过该架构逻辑图，可以发现，在Nova通过相应的服务的时候，各个组件服务之间的通信都是经过QUEUE实现的，一般默认是RabbitMQ。其实，通过前面的几篇文章，不难发现一些规律（个人的理解或者说是发现），在OpenStack中，大多数情况下，通信一般默认使用的的是消息队列进行的，数据库默认为Mariadb数据库，调用接口一般基于REST风格的RESTful API进行调用。
上图仅仅是Nova项目自身的架构图，那么Nova和其他服务是怎样的架构呢？其实上篇文章在讲述Keystone工作响应流程时所举案例包含了Nova所提供的服务功能。这里不多叙述。
这里穿插一些关于Cinder和Neutron项目的结构和组件来说明一下Nova与这两者之间的逻辑架构。
3.2 Nova与Cinder、Neutron之间的逻辑架构
为什么将这三者的逻辑架构在这里给出呢？一方面是加深对Nova的理解，理解其与其他一些项目之间的联系，例如通信方式等等，另一方面就是Nova的发展了，前文说过最初的OpenStack项目，Nova是包含块存储和网络的，如今将这二者独立出来，成为两个项目，分别对应OpenStack Block Service 和 OpenStack Networking服务。
如果对Cinder和Neutron组件不熟悉也没关系，这边主要理解上图中的三根虚线的含义即可。第四小节将会通过案例来简述Nova的工作原理。
其中，最上面的一条虚线表示的是Nova-Compute与网络服务Neutron-server之间的通信关系，Neutron-server是OpenStack网络服务提供相应的API作为访问Neutron的入口，这表示Nova需要使用Neutron提供的网络服务为虚拟机实例之间和虚拟机实例与外网之间的通信提供服务；
下面两条虚线表示的是Nova服务与块存储服务之间的通信方式，由cinder中volume和scheduler提供接口与之通信，这表示Nova需要使用Cinder服务提供块存储服务作为虚拟机实例的磁盘。笔者后期持续更新对各个核心项目的文章中，将会详细介绍Cinder以及Neutron项目等其他项目的相关知识。
温馨提示：AMPQ :高级消息队列协议，可以理解为一种通信协议。
四、Nova的工作原理
其实上文也多多少少涉及了Nova的工作流程以及些许原理，这里通过一个案例结合图示来讲述理解Nova内部的工作机制。
假设需要用户需要创建一个虚拟机的场景，这里涉及到的其他项目提供的服务就尽量跳过了，方便理解：
- 用户通过控制台（也可以是命令行等其他方式）获取认证后向Nova服务中的Nova-api发送一个"请为我创建一个虚拟机实例"的请求；
- Nova-api接收到请求后进行身份验证，之后进行必要的处理，然后将创建虚拟机实例的消息存到队列中；
- Nova-scheduler从消息队列中接收到消息，开始进行调度，从诸多个计算节点中选择一个节点，并且将"允许在计算节点1上创建虚拟机实例"的信息存放到队列中；
- 计算节点1的Nova-compute获取该信息后再自身节点上开始执行创建虚拟机的操作；
- 创建虚拟机的同时，计算节点可以通过消息队列向Nova-Conductor发送查询数据库的信息的消息，那么Conductor收到该信息后就会去访问数据库并给出回应消息；
通过上面的案例将Nova的组件之间的关系梳理的同时，针对其内部工作原理进行理解。
不过在实际的OpenStack系统运行过程中，Nova计算服务是需要和其他的服务进行交互的，例如通过与认证授权服务Keystone交互从而实现身份权限的识别认证过程，并通过OpenStack的镜像服务Glance为实例提供系统镜像，而用户和云管理员则通过OpenStack的控制面板服务Horizon与Nova进行交互等等。
五、Nova理论总结
本文主要介绍了Nova项目的概念概述、发展历程，详细介绍了Nova中核心组件的概念以及作用，给出了Nova自身的逻辑架构图以及其与块存储服务和网络服务的逻辑架构关系，最后通过一个简单案例介绍Nova内部的工作原理和工作过程。