一、nova介绍

nova是openstack 最核心的服务，负责维护和管理云环境的计算资源。 管理 VM 的生命周期

二、nova架构

nova 的架构比较复杂，包含很多组件。

这些组件以子服务（后台 deamon 进程）的形式运行，可以分为以下几类：

1、API

nova-api：接收和响应客户的 API 调用。

2、Computer Core

1）nova-scheduler：管理虚机的核心服务，通过调用 Hypervisor API 实现虚机生命周期管理

2）nova-compute：管理虚机的核心服务，通过调用Hypervisor API实现虚机圣母那个周期管理

3）Hypervisor：计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM，Xen， VMWare 等

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

3、Console Interface

1）nova-console：用户可以通过多种方式访问虚机的控制台

（1）nova-novncproxy：基于Web浏览器的VNC访问

（2）nova-apicehtml5proxy：基于Html5浏览器的SPICE访问

（3）nova-x***vncproxy：基于JAVA客户端的VNC访问

2）nova-consoleauth：负责对访问虚机控制台请求提供Token认证

3）nova-cert：提供x590证书支持

4、DateBase

1）mysql：Nova 会有一些数据需要存放到数据库中，一般使用 MySQL。

5、消息队列

1）Nova 包含众多的子服务，这些子服务之间需要相互协调和通信。为解耦各个子服务，Nova 通过 Message Queue 作为子服务的信息中转站。

三、nova物理部署方案

对于 Nova，这些服务会部署在两类节点上：计算节点和控制节点。

计算节点上安装了 Hypervisor，上面运行虚拟机。nova-compute 也需要放在计算节点上。

控制节点上安装了nova的其他子服务。

mysql单独部署。

四、从虚机创建流程看 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 负责数据库访问。

五、子服务详解

1、nova-api

nova-api会对接收到的 HTTP API 请求(跟虚拟机生命周期相关的操作)会做如下处理：

1）检查客户端传人的参数是否合法有效

2）调用 Nova 其他子服务的处理客户端 HTTP 请求

3）格式化 Nova 其他子服务返回的结果并返回给客户端

2、nova-conductor

在操作虚机的过程中nova-compute 需要获取和更新数据库中 instance 的信息。 为了不让其直接访问数据库，而是通过nova-conductor访问。

这样做有两个显著好处：

1）更高的系统安全性

2）更好的系统伸缩性

3、nova-scheduler

nova-scheduler的作用是选择在哪个计算节点上启动instance；

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

1. 通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）

2. 通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。

2）filter

RetryFilter：刷掉之前已经调度过的节点

AvailabilityZoneFilter：为提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone中

RamFilter： 将不能满足 flavor 内存需求的计算节点过滤掉

DiskFilter： 将不能满足 flavor 磁盘需求的计算节点过滤掉

CoreFilter： 将不能满足 flavor vCPU 需求的计算节点过滤掉

ComputeFilter： 保证只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler调度。

3）Weight

经过前面一堆 filter 的过滤，nova-scheduler 选出了能够部署 instance 的计算节点。 如果有多个计算节点通过了过滤，那么最终选择哪个节点呢？

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

4、nova-compute

nova-compute 在计算节点上运行，负责管理节点上的 instance。nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。

nova-compute 的功能可以分为两类：

定时向 OpenStack 报告计算节点的状态；

实现 instance 生命周期的管理（launch、shutdown、reboot、suspend、resume、terminate、resize、migration、snapshot等）；

nova-compute 创建 instance 的过程可以分为 4 步：

（1）为 instance 准备资源

分配内存、磁盘空间和 vCPU 网络资源

（2）创建 instance 的镜像文件

首先将该 image 下载到计算节点(没有命中缓存的时候)

然后将其作为 backing file(可能需要格式转化) 创建 instance 的镜像文件。

（3）创建 instance 的 XML 定义文件

（4）创建虚拟网络并启动虚拟机

六、虚机管理的场景

如上图所示，我们把对 Instance 的管理按运维工作的场景分为两类：常规操作和故障处理。

1、常规操作中，Launch、Start、Reboot、Shut Off 和 Terminate 都很好理解。 下面几个操作重点回顾一下：

Launch：新建一个instance。

Start：instance启动

Reboot：instance重启（软重启和硬重启）

软重启：只是重启操作系统，整个过程中，instance依然处于运行状态；

硬重启：是重启instance，相当于关机后在重启；

Shut Off：instance关机

Terminate：instance删除

Resize：通过应用不同的 flavor 调整分配给 instance 的资源。

Lock/Unlock：可以防止对 instance 的误操作。

Pause/Suspend/Resume：暂停当前 instance，并在以后恢复。

Pause 和 Suspend 的区别在于 Pause 将 instance 的运行状态保存在计算节点的内存中，而 Suspend 保存在磁盘上。

Pause 的优点是 Resume 的速度比 Suspend 快；缺点是如果计算节点重启，内存数据丢失，就无法 Resume 了，而 Suspend 则没有这个问题。

Snapshot：备份 instance 到 Glance。产生的 image 可用于故障恢复，或者以此为模板部署新的 instance。

2、故障处理有两种场景：计划内和计划外。

1）计划内是指提前安排时间窗口做的维护工作，比如服务器定期的微码升级，添加更换硬件等。

对于计划内的故障处理，可以在维护窗口中将 instance 迁移到其他计算节点。涉及如下操作：

Migrate：将 instance 迁移到其他计算节点。迁移之前，instance 会被 Shut Off，支持共享存储和非共享存储。

Live Migrate：与 Migrate 不同，Live Migrate 能不停机在线地迁移 instance，保证了业务的连续性。也支持共享存储和非共享存储（Block Migration）

Shelve/Unshelve Shelve 将 instance 保存到 Glance 上，之后可通过 Unshelve 重新部署。

Shelve 操作成功后，instance 会从原来的计算节点上删除。

Unshelve 会重新选择节点部署，可能不是原节点。

2）计划外是指发生了没有预料到的突发故障，比如强行关机造成 OS 系统文件损坏，服务器掉电，硬件故障等。

计划外的故障按照影响的范围又分为两类：Instance 故障和计算节点故障

（1）Instance 故障只限于某一个 instance 的操作系统层面，系统无法正常启动。可以使用如下操作修复instance：

Rescue/Unrescue：用指定的启动盘启动，进入 Rescue 模式，修复受损的系统盘。成功修复后，通过 Unrescue 正常启动 instance。

Rebuild：如果 Rescue 无法修复，则只能通过 Rebuild 从已有的备份恢复。Instance 的备份是通过 snapshot 创建的，所以需要有备份策略定期备份。

（2）计算节点故障：无法与节点的nova-compute通信，其上运行的所有instance都会受到影响。这个时候可以使用如下操作修复instance：

Evacuate：利用共享存储上 Instance 的镜像文件在其他计算节点上重建 Instance。所以提前规划共享存储是关键。