一、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 默认的调度器，调度过程分为两步：
通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）
通过权重计算（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。所以提前规划共享存储是关键。