Nova是OpenStack最早的两块模块之一，另一个是对象存储Swift。作为OpenStack云中的计算组织控制器，Nova处理OpenStack云中实例（Instances）生命周期的所有活动。这样使得Nova成为一个负责管理计算资源、网络、认证、所需可扩展性的平台。但是，Nova并不具备虚拟化能力，相反它使用Libvirt API来与被支持的Hypervisors交互。Nova通过一个与Amazon Web Services（AWS）EC2 API兼容的Web Services API来对外提供服务。
1）Nova主要组件
Nova在组成架构上是由Nova-Api、Nova-Sheduler、Nova-Compute等一些关键组件构成，这些组件都各司其职，具体关系如图10-8所示。
（1）APIServer（Nova-API）
图10-8 Nova主要组件
APIServer对外提供一个与云基础设施交互的接口，也是外部可用于管理基础设施的唯一组件。管理使用EC2 API，通过Web Services调用实现。然后APIServer通过消息队列（Message Queue）轮流与云基础设施的相关组件通信。作为EC2 API的另外一种选择，OpenStack也提供一个内部使用的OpenStack API。
（2）Message Queue（Rabbit MQ Server）
OpenStack节点之间通过消息队列使用AMQP（Advanced Message Queue Protocol）完成通信。Nova通过异步调用请求响应，使用回调函数在收到响应时触发。因为使用了异步通信，不会有用户长时间卡在等待状态。这是有效的，因为许多API调用预期的行为都非常耗时，例如加载一个实例，或者上传一个镜像。
（3）Compute Worker（Nova-Compute）
Compute Worker处理管理实例生命周期，通过Message Queue接收实例生命周期管理的请求，并承担操作工作。一个典型生产环境的云部署中有一些Compute Worker，一个实例部署在哪个可用的Compute Worke上取决于调度算法。
（4）Network Controller（Nova-Network）
Network Controller处理主机地网络配置，它包括IP地址分配、为项目配置VLAN、实现安全组、配置计算节点网络。
（5）Volume Workers（Nova-Volume）
Volume Workers用来管理基于LVM（Logical Volume Manager）的实例卷。Volume Workers有卷的相关功能，例如新建卷、删除卷、为实例附加卷、为实例分离卷等。卷为实例提供一个持久化存储，因为根分区是非持久化的，当实例终止时对它所作的任何改变都会丢失。当一个卷从实例分离或者实例终止（这个卷附加在该终止的实例上）时，这个卷保留着存储在其上的数据。当把这个卷重附加载相同实例或者附加到不同实例上时，这些数据依旧能被访问。
一个实例的重要数据几乎总是要写在卷上，这样可以确保能在以后访问。这个对存储的典型应用需要数据库等服务的支持。
（6）Scheduler（Nova-Scheduler）
调度器Scheduler把Nova-API调用映射为OpenStack组件。调度器以名为Nova-Schedule的守护进程运行，通过恰当的调度算法从可用资源池获得一个计算服务。Scheduler会根据诸如负载、内存、可用域的物理距离、CPU构架等作出调度决定。Nova Scheduler实现了一个可插入式的结构。
当前Nova-Scheduler实现了一些基本的调度算法。
·随机算法：计算主机在所有可用域内随机选择。
·可用域算法：跟随机算法相仿，但是计算主机在指定的可用域内随机选择。
·简单算法：这种方法选择负载最小的主机运行实例。负载信息可通过负载均衡器获得。
2）Nova工作流程
Nova-API对外统一提供标准化接口，各子模块，如计算资源、存储资源和网络资源子模块，通过相应的API接口服务对外提供服务，如图10-9所示。
图10-9 Nova运行架构(www.xing528.com)
图10-9中的WSGI就是Nova-API。API接口操作DB实现资源数据模型的维护，通过消息中间件，通知相应的守护进程（如Nova-Compute等）实现服务接口。API与守护进程共享DB数据库，但守护进程侧重维护状态信息、网络资源状态等。守护进程之间不能直接调用，需要通过API调用，如Nova-Compute为虚拟机分配网络，需要调用Network-API，而不是直接调用Nova-Network，这样易于解耦合。
下面以创建虚拟机为例，分析Nova的不同关键子模块之间的调用关系。因为启动一个新的实例（Instance），涉及OpenStack Nova里很多组件共同协作。
①通过调用Nova-API创建虚拟机接口，Nova-API对参数进行解析以及初步合法性校验。调用Compute-API创建虚拟机VM接口，Compute-API根据虚拟机参数（CPU、内存、磁盘、网络、安全组等）信息，访问数据库创建数据模型虚拟机实例记录（创建1个虚拟机实例）。
②接下来需要调用具体的物理机实现虚拟机部署，在这里就会涉及调度模块Nova-Scheduler。Compute-API通过RPC的方式将创建虚拟机的基础信息封装成消息发送至消息中间件指定消息队列“Scheduler”。
③Nova-Scheduler订阅了消息队列“Scheduler”的内容，接收到创建虚拟机的消息后进行过滤。根据请求的虚拟资源，即flavor的信息，选择一台物理主机部署，如物理主机A，Nova-Scheduler将虚拟机的基本信息、所属物理主机信息发送至消息中间件指定消息队列“Compute.物理机A”。
④物理机A上Nova-Compute守护进程订阅消息队列“Compute.物理机A”，接到消息后，根据虚拟机基本信息开始创建虚拟机。
⑤Nova-Compute调用Network-API分配网络IP。
⑥Nova-Network接收到消息后，从fixedIP表（数据库）里拿出一个可用IP，Nova-Network根据私网资源池，结合DHCP，实现IP分配和IP地址绑定。
⑦Nova-Compute通过调用Volume-API实现存储划分，最后调用底层虚拟化Hypervisor技术，部署虚拟机。
3）Nova物理部署方案
前面已介绍Nova由很多子服务组成，同时也知道OpenStack是一个分布式系统，可以部署到若干节点上，那么Nova的这些服务在物理上应该如何部署呢？
从功能上看，Nova平台有两类节点：控制节点和计算节点，其角色由安装的服务决定。控制节点包括网络控制Network、调度管理Scheduler、API服务、存储卷管理Nova-Volume等，计算节点主要提供Nova-Compute服务。节点之间使用AMQP作为通信总线，只要将AMQP消息写入特定的消息队列中，相关的服务就可以获取该消息进行处理。由于使用了消息总线，因此服务之间是位置透明的，可以将所有服务可以部署在同一台主机上，即All-in-One（一般用于测试），也可以根据业务需要，将其分开部署在不同的主机上。
用在生产环境Nova平台配置一般有3种类型：
（1）最简配置
最简配置至少需要两个节点，除了Nova-Compute外所有服务都部署在一台主机里，这台主机进行各种控制管理，即控制节点，如图10-10所示。
（2）标准配置
控制节点的服务可以分开在多个节点，标准的生产环境推荐使用至少4台主机来进一步细化职责。控制器、网络、卷和计算职责分别由一台主机担任，如图10-11所示。
（3）高级配置
很多情况下（比如为了高可用性），需要把各种管理服务分别部署在不同主机（比如分别提供数据库集群服务、消息队列、镜像管理、网络控制等），形成更复杂的架构，如图10-12所示。
图10-10 OpenStack双节点架构
图10-11 OpenStack多节点架构
这种配置上的弹性得益于Nova选用AMQP作为消息传递技术，更准确地说，Nova服务使用远程过程调用（RPC）彼此进行沟通。AMQP代理（可以是RabbitMQ或Qpid）位于任两个Nova服务之间，使它们以松耦合的方式进行通信。因此不单API服务器可以和服务进行通信，服务之间也可以相互通信，如计算服务和网络服务、卷服务进行通信以获得必要的资源。每一个Nova服务（Compute、Scheduler等）在初始化时会创建两个消息队列，其路由选择关键字分别为“NODE-TYPE.NODE-ID”（如Compute.）和“NODE-TYPE”（如Compute）。后者则接收一般性消息，而前者则只接收发给特定节点的命令，例如执行“euca-terminateinstance”。很明显，该命令只应发送给运行该实例的某个计算节点。无论是哪一种生产配置模式，都允许用户根据需要添加更多的计算节点，由N台服务器执行计算任务。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
