十分钟到你了解OpenStack--nova组件
简介
nova 是OpenStack 最核心的服务，负责维和和管理云环境的计算资源。OpenStack作为Iaas 的云操作系统，虚拟机生命周期管理也是通过 Nova 来实现的
一、Nova 介绍
1、用途与功能
- 实例生命周期管理
- 管理计算资源
- 网络和认证管理
- REST 风格的 API
- 异步的一致性通信
- Hypervisor 透明：支持Xen,XenServer/XCP,KVM, UML,VMware vSphere and Hyper-V
在上图中可以看到， Nova 处于 OpenStack 架构的中心，其他组件都为 Nova 提供支持：Glance 为 VM 提供image Cinder 和 swift 分别为 VM 提供块存储和对象存储 Neutron 为 VM 提供网络连接。
Nova 架构如下
nova 架构比较的复杂，包含很多组件。这些组件以子服务 （后台 deamon 进程）的形式运行，可以分为以下几类：
API：
nova-api
是整个nova 组件的门户，接收和响应客户的 API 调用，所有对 Nova 的请求都首先有 nova-api 处理。nova-api 向外界暴露若干 HTTP REST API 接口 在keystone 中我们可以查询 nova-api 的 endpoints
[root@node1 ~]# openstack endpoint list | grep nova
2173c915a1044e8a821bae1a0c021fd7 | RegionOne | nova | compute | True | admin | http://node1:8774/v2.1 | | e795ed786f5442ccb5768afe99b10f6b | RegionOne | nova | compute | True | internal | http://node1:8774/v2.1 | | fa76111a5b56461d97adbfdf066ceeb1 | RegionOne | nova | compute | True | public | http://node1:8774/v2.1 |
客户端就可以将请求发送Rest API 请求。OpenStack CLI，Dashboard 和其他需要跟 Nova 交换的组件会使用这些 API
Nova-api 对接收到的 HTTP API 请求会做如下处理：
1. 检查客户端传入的参数是否合法有效
2. 调用 Nova 其他子服务的处理客户端 HTTP 请求
3. 格式化 Nova 其他子服务返回的结果并返回给客户端
nova-api 接收哪些请求？
简单的说，只要是跟虚拟机生命周期相关的操作，nova-api 都可以响应。 大部分操作都可以在 Dashboard 上找到。打开Instance管理界面
除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API。 也就是说，如果客户以前使用 Amazon EC2，并且用 EC2 的 API 开发了些工具来管理虚机，那么如果现在要换成 OpenStack，这些工具可以无缝迁移到 OpenStack，因为 nova-api 兼容 EC2 API，无需做任何修改。
Compute Core：
a）nova-scheduler：
虚机调度服务，负责决定在哪个计算节点上运行虚机。创建 Instance 时，用户会提出资源需求，例如 CPU、内存、磁盘各需要多少。OpenStack 将这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就可以了。
下面介绍 nova-scheduler 是如何实现调度的。在 /etc/nova/nova.conf 中，nova 通过 driver=filter_scheduler 这个参数来配置 nova-scheduler。
Filter scheduler
Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步：
1. 通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）
2. 通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。
Nova 允许使用第三方 scheduler，配置 scheduler_driver 即可。 这又一次体现了OpenStack的开放性。Scheduler 可以使用多个 filter 依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点。
b）nova-compute：
nova-compute 是管理虚机的核心服务，在计算节点上运行。通过调用Hypervisor API实现节点上的 instance的生命周期管理。 OpenStack 对 instance 的操作，最后都是交给 nova-compute 来完成的。 nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。
通过Driver架构支持多种Hypervisor
Hypervisor是计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM，Xen， VMWare 等。nova-compute 为这些 Hypervisor 定义了统一的接口，Hypervisor 只需要实现这些接口，就可以 Driver 的形式即插即用到 OpenStack 系统中。
nova-conductor：
nova-compute 经常需要更新数据库，比如更新和获取虚机的状态。 出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor。
这样做有两个显著好处：
1. 更高的系统安全性
2. 更好的系统伸缩性
Console Interface：
nova-console： 用户可以通过多种方式访问虚机的控制台：
nova-novncproxy： 基于 Web 浏览器的 VNC 访问
nova-spicehtml5proxy： 基于 HTML5 浏览器的 SPICE 访问
nova-xvpnvncproxy： 基于 Java 客户端的 VNC 访问
nova-consoleauth： 负责对访问虚机控制台请求提供 Token 认证
nova-cert： 提供 x509 证书支持
Database：
Nova 会有一些数据需要存放到数据库中，一般使用 MySQL。数据库安装在控制节点上。 Nova 使用命名为 “nova” 的数据库。
Message Queue：
在前面我们了解到 Nova 包含众多的子服务，这些子服务之间需要相互协调和通信。为解耦各个子服务，Nova 通过 Message Queue 作为子服务的信息中转站。 所以在架构图上我们看到了子服务之间没有直接的连线，是通过 Message Queue 联系的。
OpenStack 默认是用 RabbitMQ 作为 Message Queue。 MQ 是 OpenStack 的核心基础组件，我们后面也会详细介绍。
二、 Nova 组件是如何协同工作的
对于 Nova，这些服务会部署在两类节点上：计算节点和控制节点
计算节点上安装了 Hypervisor，上面运行虚拟机。 由此可知：
1. 只有 nova-compute 需要放在计算节点上。
2. 其他子服务则是放在控制节点上的。
从虚机创建流程看 nova-* 子服务如何协同工作
1.客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我创建一个虚机”
2.API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个虚机”
3.Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A
4.Scheduler 向 Messaging 发送了一条消息：“在计算节点 A 上创建这个虚机”
5.计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚机。
6.在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问
