一、Nova介绍
Nova是OpenStack Compute的代号，是OpenStack的重要组成部分，也是IaaS的重要组成部分，它负责维护和管理OpenStack的计算资源，虚拟机生命周期管理也就是通过Nova来实现的。
Nova是无共享、基于消息的架构，所以的Nova组件都可以在多台服务器上分布式运行，这就意味着大多数组件与组件之间的通信都需要消息队列，在G版之前，Nova所有组件都会与数据库通信，这样的集中数据库访问在小规模环境下是个不错的选择，但对大集群来说则会产生安全问题，每个节点都具有数据库访问权限，一旦一台服务器被攻破，这个云环境将完全暴露在外，在G版之后，nova-compute所有数据操作均通过消息队列交由nova-conductor来写入或读取数据库，这样就避免了直接访问数据库，提高了安全性，也更加灵活。
二、Nova主要组件
Nova由很多子服务组成，同时我们也知道OpenStack是一个分布式系统，对于Nova这些服务会部署在两类节点上，计算节点和控制节点，计算节点上安装了Hypervisor，上面运行虚拟机，只有nova-compute需要放在计算节点上，其他子服务则是放在控制节点上的。
1、nova-api
nova-api服务作为Nova组件对外的唯一窗口，接收和响应用户的API请求，当客户需要执行虚机相关的操作，能且只能向nova-api发送REST API请求，这里的客户包括终端用户、命令行和openstack其他组件。
nova-api服务支持OpenStack Compute API，Amazon EC2 API，还有一个Admin API用于用户进行一些管理操作。
2、nova-api-metadata
nova-api-metadata主要接收虚拟机的元数据请求，通常在带有nova-network的多主机模式下才会使用。
3、nova-compute
nova-compute在计算节点上运行，它是一个工作进程(worker deamon)，通过hypervisor APIs来创建或者关闭虚拟机实例，这个过程相当的复杂，总的来说，它从队列服务接收消息之后，然后启动虚拟机并在数据库中更新状态。
nova-compute的功能可以分为两类，一定时向OpenStack报告计算节点的状态，二实现instance生命周期的管理。
4、nova-placement-api
主要追踪每个提供者的库存和使用量情况，比如追踪计算节点的资源，存储池的使用情况以及IP的分配情况等等。
5、nova-scheduler
如果有多个实体都能够完成任务，那么通常会有一个scheduler负责从这些实体中挑选出一个最合适的来执行操作，nova-scheduler就是处理队列中的请求，然后会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机，会通过消息中间件rabbitMQ向选定的计算节点发出launch instance的命令。
调度服务就好比是一个开发团队中的项目经理，当接到新的开发任务时，项目经理会评估任务的难度，考察团队成员目前的工作负荷和技能水平，然后将任务分配给最合适的开发人员。
6、nova-conductor
nova-compute需要获取和更新数据库中instance的信息，但nova-compute并不会直接访问数据库，而是通过nova-conductor实现数据的访问。在巨大的集群中，nova-conductor可以水平扩展，但是不要部署在计算节点上。
如此设计的好处是让集群更高的系统安全性和更好的系统伸缩性。
7、nova-cert
一个Nova的证书服务，提供 x509 证书支持，用于兼容AWS。
8、nova-consoleauth
负责对访问虚机控制台请亲提供Token认证。
9、nova-novncproxy
提供基于Web浏览器的VNC访问。
10、nova-spicehtml5proxy
提供基于HTML5浏览器的SPICE访问。
11、nova-xvpvncproxy
提供基于Java客户端的VNC访问。
12、The queue
在前面我们了解到Nova包含众多的子服务，这些子服务之间需要相互协调和通信，为解耦各个子服务，Nova通过Message Queue作为子服务的信息中转站，所以在架构图上我们看到了子服务之间没有直接的连线，它们都通过Message Queue联系。
13、SQL database
Nova会存放一些云平台的状态数据在数据库中，比如可用虚拟机类型、虚拟机是否使用中、网络的使用状态以及项目等。
三、Nova各组件如何协调工作
客户（可以是OpenStack最终用户，也可以是其他程序）向API（nova-api）发送请求：“帮我创建一个虚机”；
API对请求做一些必要处理后，向Messaging（RabbitMQ）发送了一条消息：“让Scheduler创建一个虚机”；
Scheduler（nova-scheduler）从Messaging获取到API发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A ；
Scheduler向Messaging发送了一条消息：“在计算节点 A 上创建这个虚机”
计算节点 A 的Compute（nova-compute）从Messaging中获取到Scheduler发给它的消息，然后在本节点的Hypervisor上启动虚机；
在虚机创建的过程中，Compute如果需要查询或更新数据库信息，会通过Messaging向Conductor（nova-conductor）发送消息，Conductor负责数据库访问。
四、Nova支持的Hypervisor
nova-compute运行在计算节点上，通过插件形式对Hypervisor进行管理，当前的版本(Ocata)，对各种主流的虚拟化平台都提供了支持，典型地通过XenAPI/vCenter API/Libvirt等所提供的插件接口执行虚拟机的创建、终止、迁移等生命周期管理。
五、nova-cell
从G版开始，Nova为了增加横向扩展以及分布式、大规模(地理位置级别)部署能力，同时又不增加数据库和消息中间件的复杂度，引入了cell概念。
cell的功能允许我们以更加灵活的分布式的方式实现对OpenStack Compute云的缩放，而不需要更加复杂的技术，只需数据库和消息队列等。它的目的是支持更大规模的部署。
当启用了这个功能的时候，OpenStack Compute云中的主机会被分组，称作cell。cell的结构是树的形式。top-level级别的cell中的主机运行一个nova-api服务，但是可以没有nova-compute服务。每一个子cell应该运行常规OpenStack云计算中所有nova-*类型的服务，除了nova-api服务。我们可以把一个cell树结构看成一个正常的OpenStack Compute部署，因为在这个树中的每个cell中都有自己的数据库服务和消息队列服务。
nova-cells服务处理cell之间的通信，并选择一个cell用于建立新的实例。这个服务将会被每个cell所需要的。cell之间的通信是可插拔的，目前cell之间的通信只是通过RPC服务来实现的。
采用cell服务实现了cell的调度和主机节点的调度是相互分离的。nova-cells服务首先会选择一个cell（目前实现的是随机选择，将来会添加过滤/权重功能，还可以基于广播获取的capacity/capabilities等参数）。一旦合适的cell被选择，且建立新的实例的请求到达了这个cell的nova-cells服务之上，这个cell将会发送建立新的实例的请求到这个cell的主机调度器。
cell的特征：
目的是支持更大规模的部署； cell的结构是树的形式； top-level级别的cell（API cell）中的主机运行nova-api服务，可以没有nova-compute服务，不感知底层物理主机以及虚拟化； 子cell无nova-api服务； 每一个子cell应该运行常规OpenStack云计算中所有nova-*类型的服务，除了nova-api服务； 树中的每个cell中都有自己的数据库服务和消息队列服务； 从设计上来讲cell之间的通信是可插拔的，也就是未来会支持多种消息通信框架，目前cell之间的通信只是通过RPC服务来实现的； 采用cell服务实现了cell的调度和主机节点的调度是相互分离的； 在建立新的实例时，nova-cells服务选择cell，目前实现的是随机选择，将来会添加过滤/权重功能，还可以基于广播获取的capacity/capabilities等参数； 在默认的情况下cell功能是禁用的。
上图是三个cell级联的情况，其中API Cell收到请求后，通过nova-cell提供的调度算法，通过消息队列将消息转发到Child Cell节点，在Child Cell节点做与API Cell同样的工作，选择一个Grandchild Cell并继续转发，在Grandchild节点上做真正的主机调度工作，选择主机创建虚拟机。
上面的情况下，Grandchild Cell需要将自己连接的资源信息定时上报给Child Cell以提供调度功能使用，同样ChildCell也要自己知道的资源信息上报给API Cell使用，这样，每层调度时只需拿自己掌握的资源信息即可，实现每层解耦。
本文出自 “运维点滴记录” 博客，请务必保留此出处http://wzlinux.blog.51cto.com/8021085/1962230
原文地址：http://wzlinux.blog.51cto.com/8021085/1962230
