openstack-nova

介绍

nova是openstack最核心的服务，负责维护和管理云环境的计算资源。
openstack作为IAAS的云操作系统，虚拟机生命周期管理也就是通过nova来实现的。

用途及功能

1. 实例生命管理周期；
2. 管理计算资源；
3. 网络和认证管理；
4. rest风格的api；
5. 异步的一致性通信；
6. hypervisor透明：支持xen、xenserver/xcp、KVM、UML、VMware、vsphere and hyper-V。

在上图中可以看到，nova出于openstack架构的中心，其他组件都为nova提供支持：glance为VM提供image cinder和swift分别为VM提供块存储和对象存储neutron为vm提供网络连接。

架构

nova的架构比较复杂，包含很多组件。这些组件以子服务（后台deamon）的形式运行，可以分为以下几类：

API

nova-api是整个nova组件的门户，接受和响应客户的API调用。所有对nova的请求都先由nova-api处理。nova-api向外界暴露若干HTTP REST API接口。
在keystone中我们可以查询nova-api 的endponits。

客户端就可以将请求发送到endponits指定的地址，想nova-api请求操作。当然，作为最终用户的我们不会直接发送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，无需做任何修改。
computer core

nova-scheduler

• nova-scheduler：
  虚机调度服务，负责决定在哪个计算节点上运行虚机。创建 Instance 时，用户会提出资源需求，例如 CPU、内存、磁盘各需要多少。OpenStack 将这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就可以了。
  
  可用的FLAVOR在system->flavors中管理
  
  下面介绍 nova-scheduler 是如何实现调度的。在 /etc/nova/nova.conf 中，nova 通过 driver=filter_scheduler 这个参数来配置 nova-scheduler。
  driver=filter_scheduler

Filter scheduler
Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步：

• 通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）
• 通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。

Nova 允许使用第三方 scheduler，配置 scheduler_driver 即可。 这又一次体现了OpenStack的开放性。Scheduler 可以使用多个 filter 依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点。

上图是调度过程的一个示例：

• 最开始有 6 个计算节点 Host1-Host6
• 通过多个 filter 层层过滤，Host2 和 Host4 没有通过，被刷掉了
• Host1，Host3，Host5，Host6 计算权重，结果 Host5 得分最高，最终入选

当 Filter scheduler 需要执行调度操作时，会让 filter 对计算节点进行判断，filter 返回 True 或 False。经过前面一堆 filter 的过滤，nova-scheduler 选出了能够部署 instance 的计算节点。

如果有多个计算节点通过了过滤，那么最终选择哪个节点呢？

Scheduler 会对每个计算节点打分，得分最高的获胜。 打分的过程就是 weight，翻译过来就是计算权重值，那么 scheduler 是根据什么来计算权重值呢？

目前 nova-scheduler 的默认实现是根据计算节点空闲的内存量计算权重值： 空闲内存越多，权重越大，instance 将被部署到当前空闲内存最多的计算节点上。

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 Driver的架构示意图：

nova-conductor：

nova-compute 经常需要更新数据库，比如更新和获取虚机的状态。 出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor。

这样做有两个显著好处：

1. 更高的系统安全性
2. 更好的系统伸缩性

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 的核心基础组件，我们后面也会详细介绍。