Compute Service Nova 是 OpenStack 最核心的服务，负责维护和管理云环境的计算资源。虚拟机的生命周期也是通过 Nova 来实现的。
一、Nova 架构
1. API
- nova-api
接收和响应客户的 API 调用
2. Compute Core
nova-scheduler
虚拟机调度服务，负责决定在哪个计算几点上运行虚拟机。nova-compute
管理虚拟机的核心服务，通过调用 Hypervisor API 实现虚拟机生命周期管理。Hypervisor
计算节点上的虚拟化管理程序，虚拟机管理最底层的程序。nova-conductor
nova-compute 经常需要操作数据库来更新虚拟机的状态。出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托个 nova-conductor 来完成。
3. Console Interface
nova-console
访问虚拟机的控制台：
nova-novncproxy：基于 Web 游览器的 VNC 访问。
nova-spicehtml5proxy：基于 HTML5 游览器的 SPICE 访问。
nova-xvpnvncproxy：基于 Java 客户端的 VNC 访问。nova-consoleauth
负责对访问虚拟机控制台请求提供 Token 认证。nova-cert
提供 X509 证书支持
4. Database
一般使用MySQL。
表信息如下：内容较多隐藏了一部分，下面是查看方法。
root@controller:~# su - stack
stack@controller:~$ mysql
mysql> use nova
mysql> show tables;
+--------------------------------------------+
| Tables_in_nova |
+--------------------------------------------+
| agent_builds |
| aggregate_hosts |
.......
5. Message Queue
OpenSack 默认使用的是 RabbitMQ 作为 Message Queue。有关 RabbitMQ 查看 RabbitMQ原理和使用场景以及模式
二、部署方案
1. 首先来查看 Nova 模块的运行情况
- 计算节点
root@compute:~# ps -e | grep nova
28197 pts/3 00:00:02 nova-compute
- 控制节点
root@controller:~# ps -e | grep nova
20973 pts/7 00:05:46 nova-api
27075 pts/13 00:05:46 nova-conductor
27968 pts/13 00:01:59 nova-conductor
27969 pts/13 00:01:58 nova-conductor
28051 pts/14 00:00:44 nova-scheduler
28541 pts/15 00:00:19 nova-novncproxy
29180 pts/16 00:00:47 nova-consoleaut
29741 pts/17 00:03:27 nova-compute
可以发现在控制节点中运行了很多 nova 进行，其中包括 compute 进行。在计算节点中只有 compute。controller 即是控制节点，又是计算节点。
这说明了 OpenStack 这种分布式架构部署上的灵活性：
- 可以将所有服务器放在一台物理机上，作为一个 All-in-One 的测试环境
- 可以将服务部署到多台物理机上，获得更好的性能和高可用。
也可以使用 nova service-list 查看 nova 服务分布
root@controller:/opt/stack# nova service-list
+----+------------------+------------+----------+---------+-------+----------------------------+-----------------+
| Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+----+------------------+------------+----------+---------+-------+----------------------------+-----------------+
| 3 | nova-conductor | controller | internal | enabled | up | 2019-03-09T04:35:04.000000 | - |
| 4 | nova-scheduler | controller | internal | enabled | up | 2019-03-09T04:35:05.000000 | - |
| 5 | nova-consoleauth | controller | internal | enabled | up | 2019-03-09T04:35:04.000000 | - |
| 6 | nova-compute | controller | nova | enabled | up | 2019-03-09T04:35:00.000000 | - |
| 7 | nova-compute | compute | nova | enabled | up | 2019-03-09T04:35:02.000000 | - |
+----+------------------+------------+----------+---------+-------+----------------------------+-----------------+
三、OpenStack Nova 设计思路
1. API 前端服务
每个 OpenStack 组件可能包含若干子服务，其中必定有一个 API 服务负责接收客户请求。这里的客户包括终端用户、命令行和 OpenStack 其他组件。
设计 API 前端服务的优点：
- 对外提供统一接口，隐藏实现细节。
- API 提供 REST 标准调用服务，便于与第三方系统集成。
- 可以通过多个 API 服务实例轻松实现 API 的高可用。
2. Scheduler 调度服务
Nova 由多个计算节点，当需要创建虚拟机时，nova-scheduler 会根据计算节点当时的资源使用情况选择一个最适合的计算节点来运行云主机。
比如：调度服务是一个开发团队的项目经理，当接到新的开发任务时，项目经理会评估任务的难度，考虑团队成员目前的工作负荷和技能水平，然后将任务分配给最合适的开发人员。
3. Worker 工作服务
调度服务只管分配工作，真正执行任务的是 Worker 工作服务。
在 Nova 中，Worker 就是 nova-comput。
将 Scheduler 和 Worker 从职能上进行划分使得 OpenStack 很容易扩展
- 当计算资源不够时，可以添加计算几点（增加 Worker）
- 当客户请求量太大调度不过来时，可以添加 Scheduler
4. Driver 框架
OpenStack 的计算节点支持多种 Hypervisor。包括KVM、Hyper-V、VMWare、Xen、Docker、LXC等。
nova-compute 为这些 Hypervisor 定义了统一的接口，Hypervisor 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。
在 nova-compute 的配置文件 /etc/nova/nova.conf 中。由 compute_driver 配置项指定该计算节点使用那种 Hypervisor 的 driver。
compute_driver = libvirt.LibvirtDriver
在 Glance 模块中，OpenStack 支持多种 backend 来存放 image，如：本地系统、Cinder、Ceph、Swift等。这其实也是一个 driver 框架。
5. Messaging 服务
为什么使用分布式。
程序之间调用分为两种：同步调用和异步调用
同步调用
API 直接调用 Scheduler 的接口就是同步调用。特点是 API 发出请求后需要一直等待，直到 Scheduler 完成对 Compute 的调度，将结果返回给 API 后 API 才能够继续后面的工作。异步调用
API 通过 Messaging 间接调用 Scheduler 就是异步调用。特点是 API 发出请求后不需要等待，直接返回，继续做后面的事。
Scheduler 从 Messaging 接收到请求后执行操作，完成后将结果返回给 Messaging 发送给 API。
OpenStack 分布式系统采用异步调用的好处：
解耦各子服务
子服务不需要知道其他服务在哪运行，只需要发消息给 Messaging 就可。提高性能
异步调用使调用者无需等待结果返回。这样可以执行更多操作。提供系统吞吐量。提高伸缩性
子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提供可用性的同时也提高整个系统的伸缩性。而这种变化不会影响其他子服务。
5. Database
每个组件都需要维护自己的状态信息。这些信息都是存放在数据库中。
四、Nova 组件的详细说明
1. nova-api
nova-api 是整个 Nova 组件的门户，所有对 Nova 的请求都先由 nova-api 处理。nova-api 向外界暴露若干 HTTP REST API 接口。
nova-api 对接到的请求做如下处理：
- 检查客户端传入的参数是否合法有效。
- 调用 Nova 其他子服务的处理客户端 HTTP 请求。
- 格式化 Nova 其他子服务返回的结果并返回给客户端。
nova-api 接收只和虚拟机生命周期相关的操作。如下图中的所有操作：
2. nova-scheduler
在创建 Instance 时用户可以选择 flavor（实例类型） 来设置虚拟机的CPU，内存等。用户也可以自定义 flavor 的内容。
flavor 位置如下图：
如何实现调度：
（1）Filter scheduler
Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分两部：
- 通过过滤器（filter）选择满足条件的计算节点
- 通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。
配置：
scheduler_driver = filter_scheduler
（2）Filter
在 /ect/nova/nova.conf 中 scheduler_default_filters 选项用于配置 scheduler 可用的 filter， 默认是所有 nova 自带的 filter 都可以用来过滤操作。
配置：
scheduler_default_filters = RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,DifferentHostFilter
以下逐个介绍过滤器的意义：
-
RetryFilter
ReryFilter 作用是刷掉之前已经调度过的节点。
RetryFilter 通常作为第一个 filter
假设 A，B，C 三个节点都用过了过滤，最终 A 因为权重值最大被选中执行操作。
但是由于一些原因在 A 上执行的操作失败了。
默认情况下，nova-scheduler 会重新执行过滤操作。这个时候 RetryFilter 就会将 A 直接刷掉，避免操作再次失败。
-
AvailabilityZoneFilter
为了提高容灾性和提供隔离服务，可以将计算节点划分到不同 Availability Zone 中。
在创建虚拟机时需要指定 Availability Zone。nova-scheduler 在做 filtering 时，会使用 AvailabilityZoneFilter 将不属于 Availability Zone 的计算节点过滤掉。
OpenStack 默认有一个 Availability Zone 叫 nova，用户也可以自己创建。位置如下图：
-
RamFilter
RamFilter 将不能满足 flavor 内存需求的计算节点过滤掉。
nova 内存超分配置：默认值1.5
ram_allocation_ratio = 1.5
意义：如果计算节点内存有 10GB，OpenStack 则会认为他有 15GB（10 * 1.5）的内存
-
DiskFilter
DiskFilter 将不能满足 flavor 磁盘需求的计算节点过滤。
nova 磁盘超分配置： 默认值 1.0
disk_allocation_ratio = 1.0
-
CoreFilter
CoreFilter 将不能满足 flavor vCPU 需求的计算节点过滤。
nova vCPU超分配置：默认 16.0
cpu_allocation_ratio = 16.0
意义：一个有 8CPU 的计算节点，在 nova-scheduler 在调度时认为他有 128 个 vCPU。
在 nova-scheduler 默认使用 filter 中是没有 CoreFilter 的。如果需要将 CoreFilter 加入到 nova.conf 配置文件中去。
-
ComputeFilter
ComputeFilter 保证只有 nova-scheduler 服务正常工作的计算节点，才能被 nova-scheduler 调度。
-
ComputeCapabilitiesFilter
ComputeCapabilitiesFilter 根据计算节点的特性来筛选
举例：节点有 X8664 和 ARM 框架，如果想将 Instance 指定部署到 X8664 架构的节点上，就可以利用 ComputeCapabilitiesFilter。
在 flavor 的 Metadata 中，有一个 Compute 的 Capabilities 来设置过滤信息。如下图：
-
ImagePropertiesFilter
ImagePropertiesFilter 根据所选 Image 的属性来筛选匹配的计算节点。
image 中也有 metadata 用来指定属性。在创建镜像时可以设置。如下图：
以上设置，ImagePropertiesFilter 在调度时只会筛选出 kvm 节点。
-
ServerGroupAntiAffinityFilter
ServerGroupAntiAffinityFilter 可以尽量将 Instance 分散部署到不同节点上。
例：有三个 Instance 分别是 ins1、ins2、ins3，计算节点A、B、C
分散部署操作：
（1）创建一个 anti-affinity 策略的 server group "group-1"
root@controller:~# nova server-group-create --policy anti-affinity group-1
（2）依次创建 Instance，将 ins1、ins2、ins3 放到 group-1 中
root@controller:~# nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1
root@controller:~# nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2
root@controller:~# nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst3
创建 Instance 时，如果没有指定 server group，ServerGroupAntiAffinityFilter 不会做任何过滤。
-
Weight
空闲内存越多，权重越大，Instance 将被部署到当前空闲内存最多的计算节点上。
（3）日志
/etc/nova/nova.conf 中 debug = True。后创建虚拟机，在 nova 的日志中可以查看到创建流程，以及过滤过程，权重的计算。
日志文件：/opt/stack/logs/n-sch.log （非 devstack 安装日志 /var/log/nova/scheduler.log）
3. nova-compute
nova-compute 在计算节点运行，负责管理节点上 Instance。
OpenStack 对 Instance 的操作，最后都是交给 nova-compute 来完成的。
nova-compute 与 Hypervisor 一起实现 OpenStack 对 Instance 生命周期的管理。
支持多种 Hypervisor
在 /opt/stack/nova/nova/virt 目录下可查看到 OpenStack 源码中已经自带了几个 Hypervisor 的 Driver。
root@controller:/opt/stack/nova/nova/virt# ll
drwxr-xr-x 2 stack stack 4096 Feb 23 18:45 hyperv/
drwxr-xr-x 4 stack stack 4096 Feb 23 19:07 libvirt/
drwxr-xr-x 2 stack stack 4096 Feb 23 18:45 vmwareapi/
drwxr-xr-x 3 stack stack 4096 Feb 23 18:45 xenapi/
每个计算节点只能运行一种 Hypervisor 。在 计算节点的 nova-compute 的配置文件 /etc/nova/nova.comf 中配置所对应的 compute_driver 即可。
nova-compute 的功能
(1) 定期向 OpenStack 报告计算节点的状态
(2) 实现 Instance 生命周期的管理
- Instance 创建过程分为 4 步：
a. 为 Instance 准备资源
b. 创建 Instance 的镜像文件
首先判断 image 是否下载到计算节点（如果没下，从 Glance 下载 image）。
然后将其作为backing file 创建 Instance 的镜像文件。
注意：image 指的是 Glance 上保存的镜像，作为 instance 运行模板。
镜像文件指的是 Instance 启动盘所对应的文件。
二者的关系是：image 是镜像文件的 backing file。image 不会变，而镜像文件会发生变化。
c. 创建 Instance 的 XML 定义文件
XML 保存在目录 /opt/stack/data/nova/instances/fle.... 中，命名为 libvirt.xml
d. 创建虚拟机网络并启动虚拟机
4. nova-conductor
nova-compute 需要获取和更新数据库中 Instance 的信息。
但是 nova-compute 并不会直接访问数据库，而是通过nova-conductor 实现数据的访问。
五、OpenStack 日志
1. 日志位置
devstack 日志统一放在 /opt/stack/logs 中。
root@controller:/opt/stack/logs# ls
c-api.log n-api.log q-l3.log
c-api.log.2019-03-09-152514 n-api.log.2019-03-09-152514 q-l3.log.2019-03-09-152514
c-sch.log n-cauth.log q-meta.log
c-sch.log.2019-03-09-152514 n-cauth.log.2019-03-09-152514 q-meta.log.2019-03-09-152514
c-vol.log n-cond.log q-svc.log
c-vol.log.2019-03-09-152514 n-cond.log.2019-03-09-152514 q-svc.log.2019-03-09-152514
dstat-csv.log n-cpu.log screen
dstat.log n-cpu.log.2019-03-09-152514 stack.sh.log
dstat.log.2019-03-09-152514 n-dhcp.log stack.sh.log.2019-03-09-152347
g-api.log n-novnc.log stack.sh.log.2019-03-09-152347.summary.2019-03-09-152347
g-api.log.2019-03-09-152514 n-novnc.log.2019-03-09-152514 stack.sh.log.2019-03-09-152514
g-reg.log n-sch.log stack.sh.log.2019-03-09-152514.summary.2019-03-09-152514
g-reg.log.2019-03-09-152514 n-sch.log.2019-03-09-152514 stack.sh.log.summary
horizon.log placement-api.log worlddump-2019-02-23-084143.txt
horizon.log.2019-03-09-152514 placement-api.log.2019-03-09-152514 worlddump-2019-02-23-084728.txt
key-access.log q-agt.log worlddump-2019-02-23-085240.txt
key-access.log.2019-03-09-152514 q-agt.log.2019-03-09-152514 worlddump-2019-03-09-072414.txt
key.log q-dhcp.log
如：nova-* 各个子服务的日志是以 n- 开头：
- n-api.log 是 nova-api 的日志
- n-cpu.log 是 nova-compute 的日志
- n-cond.log 是 nova-conductor 的日志
- n-sch.log 是 nova-scheduler 的日志
Glance 的日志是 g- 开头：
- g-api.log 是 glance-api 的日志
- g-reg.log 是 glance-registry 的日志
Cinder 的日志是 c- 开头
Neutron 的日志是 q- 开头
对于其他非 devstack 安装的 OpenStack 日志一般放在 /var/log/xxx/ 目录下。
2. 日志格式
<时间><日志登记><代码模块><日志内容><源代码位置>
- 时间，日志记录的时间
- 日志等级，有 INFO WARNING ERROR DEUBG 等
- 代码模块，当前运行的模块
- Request ID，日志记录联系不同的操作，为了便于区分和增加可读性，每个操作都被分配唯一的 Request ID。
- 日志内容，记录当前正在执行的操作和结果等重要信息
- 源代码位置，日志代码的位置，包括方法名，源代码文件的目录位置和行号
示例：
2019-03-10 16:59:15.588
DEBUG
nova.compute.api
[req-89caccca-ecf0-40f2-a9e3-b2638cc49427 demo admin]
[instance: cb00bd21-908f-4f05-b367-553c6c548f58] Going to try to stop instance from (pid=29543) force_stop
/opt/stack/nova/nova/compute/api.py:2282
时间：2019-03-10 16:59:15.588
日志登记：DEBUG
代码块是：nova.compute.api
Request ID：[req-89caccca-ecf0-40f2-a9e3-b2638cc49427 demo admin]
内容：[instance: cb00bd21-908f-4f05-b367-553c6c548f58] Going to try to stop instance from (pid=29543)
代码位置：force_stop /opt/stack/nova/nova/compute/api.py:2282
下一节介绍 OpenStack Cinder 模块