架构

• 目前的 nova 主要由 API、Compute、Condutor、Scheduler 四个核心组件组成。每个组件都可以部署一个或多个来实现横向扩展。
• API ：接收 HTTP 请求，依据请求是长时任务还是短时任务，将请求发送给 Conductor 或者 Compute 。
• Condutor ：处理需要调度的请求，还负责代理 Compute 组件对数据库的访问。
• Scheduler ：为虚拟机实例选择合适的计算节点。
• Compute ：负责与 Hypervisor 进行通信，实现虚拟机的生命周期管理。对各个 Hypervisor 的支持是通过 Virt Driver 框架来实现的。

以虚拟机创建为例：

API服务 监听到客户端发送的 HTTP 请求，然后将其转换成 AMQP 消息；Condutor 服务 通过消息队列接受任务之后，做一些准备工作，再通过消息对列告诉 Scheduler 去选择一个满足要求的计算节点；Condutor 拿到 Scheduler 提供的目标主机之后，会去要求 Compute 服务创建虚拟机。

滚动升级

• 使得系统不必在一个原子操作中完成系统升级，而是分步将系统的每一小部分进行升级，通过多步升级，使得系统的 downtime 减少。

• 在升级过程中，所有的虚拟机都可以继续正常运行。

• nova 只提供了 N 到 N+1 版本的升级，即不提供跨版本升级。

基本步骤：

1. 更新控制节点上的 nova 代码，包括所有依赖。此时，nova 服务进程并没有重启，使用的仍是内存中已经加载的旧代码。
2. 升级数据库的 schema ，添加新的 column 和 table。数据库的 schema 会做向后兼容。
3. 通过友好的方式重启控制节点上所有的 nova 服务进程。在重启前，会先完成所有现有的请求。重启之后，所有控制节点位于 N+1 版本上，所有计算节点仍处于 N 版本上。（唯一的 downtime）
4. 滚动升级计算节点。同样是通过友好的方式终止服务进程，此时集群中会有 N 和 N+1 版本的计算节点。N+1 版本的控制器和服务进程会做好向后兼容。
5. 所有计算节点升级完成之后，发送 SIG_HUP 信号给所有服务进程，使得所有服务进程开始使用新的 RPC 接口进行通信。
6. 运行数据在线升级。

实现滚动升级最重要的三项技术：

1. RPC versioning ：nova 各组件间的通信是通过消息队列实现的，nova 通过对 RPC 接口的版本化来实现兼容性。

2. Conductor ：它代理了 nova-compute 对数据库的访问，为传输的数据对象提供了版本兼容的功能，完成不兼容的对象的自动转换。

3. Versioned Object Model ：每个对象都维护有一个版本号，RPC 请求里会包括这个版本号。数据库内容升级后，如果 nova-compute 没有升级，仍然请求旧版本数据，nova-conductor 将把数据封装成旧版本返回给 nova-compute 。

调度器

默认的调度器是 FilterScheduler。它首先使用指定的一系列 Filter 过滤得到符合条件的主机；然后通过配置的 Weights 对得到的主机列表计算权重并排序，选择最佳的一个。

典型操作

迁移：将虚拟机从一个计算节点转移到另一个节点。

• 冷迁移：在迁移过程中，虚拟机处于不可用状态。新 Flavor 配置等于旧的配置

• Resize：根据需求调整虚拟机的计算能力和资源。新 Flavor 配置必须大于旧的配置。

• 热迁移：在迁移过程中，虚拟机处于正常工作的状态。由于要求虚拟机业务不中断，所以一般都是在新老虚拟机共享存储的条件下进行的。

• Suspend：通知虚拟机挂起，虚拟机内部进行挂起操作。对应 Resume 。

• Pause：Hypervisor 直接从 CPU 调度方面挂起虚拟机，虚拟机本身感知不到。对应 Unpause 。