nova介绍
Nova 负责维护和管理云环境的计算资源,Nova这个模块很重要，可以说是 OpenStack 的最核心的服务模块之一，以至于在 OpenStack 的初期版本里大部分的云系统管理功能都是由该模块负责管理的，只不过后来为了减轻该“车间主任”的压力，也便于功能分配管理，才把虚拟存储、网络等部分分离出来，而使该模块主要负责云虚拟机实例（Compute 或 Instance) 的生成、监测、终止等管理功能。
placement (用于服务追踪的user)
nova 相关进程介绍
Nova 的架构比较复杂，包含很多组件。 这些组件以子服务（后台 deamon 进程）的形式运行，可以分为以下几类：
[root@yun2 log]# openstack compute service list
+----+------------------+------+----------+---------+-------+----------------------------+
| ID | Binary | Host | Zone | Status | State | Updated At |
+----+------------------+------+----------+---------+-------+----------------------------+
| 1 | nova-consoleauth | yun2 | internal | enabled | up | 2019-08-03T02:57:28.000000 |
| 4 | nova-scheduler | yun2 | internal | enabled | up | 2019-08-03T02:57:30.000000 |
| 5 | nova-conductor | yun2 | internal | enabled | up | 2019-08-03T02:57:27.000000 |
| 6 | nova-compute | yun3 | nova | enabled | up | 2019-08-03T02:57:28.000000 |
| 7 | nova-compute | yun2 | nova | enabled | up | 2019-08-03T02:57:32.000000 |
| 8 | nova-compute | yun4 | nova | enabled | up | 2019-08-03T02:57:31.000000 |
+----+------------------+------+----------+---------+-------+----------------------------+服务启动
# 主节点
# systemctl enable openstack-nova-api.service \
openstack-nova-consoleauth.service openstack-nova-scheduler.service \
openstack-nova-conductor.service openstack-nova-novncproxy.service
# systemctl start openstack-nova-api.service \
openstack-nova-consoleauth.service openstack-nova-scheduler.service \
openstack-nova-conductor.service openstack-nova-novncproxy.service
#计算节点
# systemctl enable libvirtd.service openstack-nova-compute.service
# systemctl start libvirtd.service openstack-nova-compute.servicenova-api
nova-api 是nova组件的门户，负责接收和响应客户的API调用；所有对nova的请求都要首先由nova-api处理;在 keystone 中我们可以查询 nova-api 的 endponits：
+-----------+-----------+------------------------------------------------------------------+
| Name | Type | Endpoints |
+-----------+-----------+------------------------------------------------------------------+
| | | |
| nova | compute | RegionOne |
| | | internal: http://yun2:8774/v2.1 |
| | | RegionOne |
| | | public: http://yun2:8774/v2.1 |
| | | RegionOne |
| | | admin: http://yun2:8774/v2.1 |
| | | |
+-----------+-----------+------------------------------------------------------------------+Nova-api 对接收到的 HTTP API 请求会做如下处理：
- 检查客户端传入的参数是否合法有效
- 调用 Nova 其他子服务的处理客户端 HTTP 请求
- 格式化 Nova 其他子服务返回的结果并返回给客户端
nova-scheduler
- nova-scheduler负责虚机调度服务，决定在哪个计算节点上运行虚机;
- 创建 Instance 时，用户会提出资源需求，例如 CPU、内存、磁盘各需要多少；OpenStack 将这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就OK了
- Nova 允许使用第三方 scheduler，配置 scheduler_driver 即可。 这又一次体现了OpenStack的开放性
Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步（调度算法）：
- 通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）
- 通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。
nova-compute
nova-compute 是管理虚机的核心服务，在计算节点上运行。通过调用Hypervisor API实现节点上的 instance的生命周期管理。 OpenStack 对 instance 的操作，最后都是交给 nova-compute 来完成的。 nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。
- Openstack中虚机默认的保存路径在：/var/lib/nova/instances
Hypervisor
- Hypervisor是计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor
- openstack通过Driver架构支持多种Hypervisor;常用的 Hypervisor 有 KVM，Xen， VMWare 等。
- nova-compute 为这些 Hypervisor 定义了统一的接口，Hypervisor 只需要实现这些接口，就可以 Driver 的形式即插即用到 OpenStack 系统中。
下面是Nova Driver的架构示意图：
nova-conductor
nova-conductor主要用于管理数据库；nova-compute 经常需要更新数据库，比如更新和获取虚机的状态。 出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor。
Database
Nova 会有一些数据需要存放到数据库中，一般使用 MySQL。数据库安装在控制节点上(名为nova的库)
Message Queue
在前面我们了解到 Nova 包含众多的子服务，这些子服务之间需要相互协调和通信。为解耦各个子服务，Nova 通过 Message Queue 作为子服务的信息中转站。 所以在架构图上我们看到了子服务之间没有直接的连线，是通过 Message Queue 联系的。
Console Interface
进程 | 作用 |
nova-console | 用户可以通过多种方式访问虚机的控制台 |
nova-novncproxy | 基于 Web 浏览器的 VNC 访问 |
nova-spicehtml5proxy | 基于 HTML5 浏览器的 SPICE 访问 |
nova-xvpnvncproxy | 基于 Java 客户端的 VNC 访问 |
nova-consoleauth | 负责对访问虚机控制台请求提供 Token 认证 |
nova-cert | 提供 x509 证书支持 |
nova创建虚拟机的主要过程
- 首先用户登录 dashboard：访问 dashboard，登录信息由 keystone 查询数据库进行验证通过后，给用户返回一个 token，horizon 拿到 token，登录成功进入 web 界面。
- 点击‘创建云主机’按钮、填写云主机相关配置、点击启动实例后，horizon 拿着三样东西‘创建云主机的请求，云主机相关配置，还有 token 令牌’去找 Nova-api。
- Nova-api 拿到 token 令牌去找 keystone 验证通过后，Nova-api 接受 horizon 创建云主机的请并将配置信息存入数据库。Nova-api 通知 mq 消息队列，mq 在通知 Nova-schedular,由 Nova-schedular 选择适合创建实例的节点，
- Nova-schedular 查找数据库虚机配置信息，并通过调度算法决定Nova-compute；比如决定让 Nova-computeA创建云主机。
- Nova-computeA 接到调度后，请求 Nova-conductor 帮忙将配置信息从数据库提取出来。
- Nova-computeA 拿着 token 去找 glance-api 要镜像。
- Nova-computeA 拿着 token 去找 neutron-server 要网络资源。
- Nova-computeA拿着 token 去找 cinder-api 要存储资源。
- 当 Nova-computeA 拿到所有创建云主机的资源后，就把所有工作交给真正创建虚拟机的 hypervisor 直接进行创建。到此就拥有一台云主机了。
nova创建虚拟机的详细过程
- 界面或命令行通过RESTfullAPI向keystone获取认证信息
- keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
- 界面或命令行通过RESTfullAPI向nova-api发送一个boot instance 的请求，（请求中包含auth-token）
- nova-api 接受请求后向keystone发送认证请求，查看token是否有效（Authentication（认证）和 Authorization（鉴权））
- keystone验证token是否有效，有效返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）
- 通过认证后nova-api和数据库通讯
- 初始化新建虚拟机的数据记录
- nova-api 通过rpc.call 向nova-scheduler请求是否有创建虚拟机的资源（host id）
- nova-scheduler进程侦听消息队列，获取nova-api的请求
- nova-scheduler通过查询nova数据库中的计算资源的情况，并通过调度算法计算符合虚拟机创建的主机
- 对于有符合虚拟机创建的主机，nova-scheduler更新数据库中的虚拟机对应的物理主机信息
- nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息
- nova-compute会从对应的消息队列中获得创建虚拟机请求的消息
- nova-compute通过rpc.call向nova-conductor请求获取虚拟机的消息（Flavor）
- nova-conductor从消息队列中拿到nova-compute请求消息
- nova-conductor根据nova-compute的消息查询虚拟机对应的信息
- nova-conductor从数据库中获取虚拟机对应的信息
- nova-conductor把虚拟机的信息通过消息的方式发送到消息队列中
- nova-compute从对应的消息队列中获取虚拟机的信息
- nova-compute通过keystone的RESTfullAPI拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要的镜像。
- glance-api向keystone认证token是否有效，并返回验证结果
- token验证通过，nova-compute获取虚拟机镜像信息（URL）
- nova-compute 通过keystone的RESTfullAPI拿到认证的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息
- neutron-server向keystone认证token是否有效，并返回验证结果
- token验证通过，nova-compute获取获得虚拟机网络信息
- nova-compute通过keystone的RESTfullAPI拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息
- cinder-api 向keystone认证是否有效，并返回验证结果
- token验证通过，nova-compute获得虚拟机持久化存储信息
- nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机
