一、计算服务nova
1.1 概述
nova:计算服务，是openstack最核心的服务之一，负责维护和管理云环境的计算资源
1. openstack原生架构
nova能提供虚拟化功能/资源。
2. 核心服务nova
nova是没有虚拟化的能力，靠的是自己虚拟化驱动，通过驱动和底层虚拟化技术，进行交互和调用操作。
3. 需要keystone、glance、neutron等服务支持，可与这些服务集成。
1.2 nova系统架构
二、组件介绍
1、 API
nova-api
是整个 Nova 组件的门户，接收和响应客户的 API 调用。所有对 Nova 的请求都首先由 nova-api 处理。nova-api 向外界暴露若干 HTTP REST API 接口 在 keystone 中我们可以查询 nova-api 的 endponits。
客户端就可以将请求发送到 endponits 指定的地址，向 nova-api 请求操作。 当然，作为最终用户的我们不会直接发送 Rest AP I请求。 OpenStack CLI，Dashboard 和其他需要跟 Nova 交换的组件会使用这些 API。
Nova-api 对接收到的 HTTP API 请求会做如下处理：
1. 检查客户端传入的参数是否合法有效
2. 调用 Nova 其他子服务的处理客户端 HTTP 请求
3. 格式化 Nova 其他子服务返回的结果并返回给客户端
nova-api 接收哪些请求？
简单的说，只要是跟虚拟机生命周期相关的操作，nova-api 都可以响应。 大部分操作都可以在 Dashboard 上找到。打开Instance管理界面
除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API。 也就是说，如果客户以前使用 Amazon EC2，并且用 EC2 的 API 开发了些工具来管理虚机，那么如果现在要换成 OpenStack，这些工具可以无缝迁移到 OpenStack，因为 nova-api 兼容 EC2 API，无需做任何修改。
2、scheduler调度器
虚机调度服务，负责决定在哪个计算节点上运行虚机。创建 Instance 时，用户会提出资源需求，例如 CPU、内存、磁盘各需要多少。OpenStack 将这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就可以了。
可用的 flavor 在 System->Flavors 中管理。
下面介绍 nova-scheduler 是如何实现调度的。在 /etc/nova/nova.conf 中，nova 通过 driver=filter_scheduler 这个参数来配置 nova-scheduler。
driver=filter_scheduler
Filter scheduler
Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步：
1. 通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）
2. 通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。
Nova 允许使用第三方 scheduler，配置 scheduler_driver 即可。 这又一次体现了OpenStack的开放性。Scheduler 可以使用多个 filter 依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点。
上图是调度过程的一个示例：
1. 最开始有 6 个计算节点 Host1-Host6
2. 通过多个 filter 层层过滤，Host2 和 Host4 没有通过，被刷掉了
3. Host1，Host3，Host5，Host6 计算权重，结果 Host5 得分最高，最终入选
当 Filter scheduler 需要执行调度操作时，会让 filter 对计算节点进行判断，filter 返回 True 或 False。经过前面一堆 filter 的过滤，nova-scheduler 选出了能够部署 instance 的计算节点。
如果有多个计算节点通过了过滤，那么最终选择哪个节点呢？
Scheduler 会对每个计算节点打分，得分最高的获胜。 打分的过程就是 weight，翻译过来就是计算权重值，那么 scheduler 是根据什么来计算权重值呢？
目前 nova-scheduler 的默认实现是根据计算节点空闲的内存量计算权重值： 空闲内存越多，权重越大，instance 将被部署到当前空闲内存最多的计算节点上。
3、nova-compute
nova-compute 是管理虚机的核心服务，在计算节点上运行。通过调用Hypervisor API实现节点上的 instance的生命周期管理。 OpenStack 对 instance 的操作，最后都是交给 nova-compute 来完成的。 nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。
Openstack中虚机默认的保存路径在：/var/lib/nova/instances
通过Driver架构支持多种Hypervisor
Hypervisor是计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM，Xen， VMWare 等。nova-compute 为这些 Hypervisor 定义了统一的接口，Hypervisor 只需要实现这些接口，就可以 Driver 的形式即插即用到 OpenStack 系统中。 下面是Nova Driver的架构示意图：
4、nova-conductor
nova-compute 经常需要更新数据库，比如更新和获取虚机的状态。 出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor。
这样做有两个显著好处：
1. 更高的系统安全性
2. 更好的系统伸缩性
5、其他
nova-console： 用户可以通过多种方式访问虚机的控制台：
nova-novncproxy： 基于 Web 浏览器的 VNC 访问
nova-spicehtml5proxy： 基于 HTML5 浏览器的 SPICE 访问
nova-xvpnvncproxy： 基于 Java 客户端的 VNC 访问
nova-consoleauth： 负责对访问虚机控制台请求提供 Token 认证
nova-cert： 提供 x509 证书支持
6、placementAPI
1. 由外部系统提供(统计外部资源),管理元需要统一的、简单的管理接口来统计系统中资源使用情况，这个接口就是placementAPI
2. 被消费的资源类型是按类进行跟踪的，如计算节点类、贡献存储池类、IP地址类等
7、nova部署架构
经典模式：单节点(单中心节点）,中心化集群/架构
nova负载均衡部署模式:多节点(多个中心节点)
7.1 cell架构
openstack nova集群的规模变大，数据库和消息服务就会出现瓶颈
nova为提高水平扩展及分布式、大规模的部署能力，同时又不增加数据库的消息中间的复杂度，引入cell概念
可看成单元，为支持更大规模的部署
openstacak较大的nova集群分成小的单元
每个单元都又自己的数据库
7.2 单cell架构部署
创建虚拟机---->任务(ID用于定位)
nova-api 接收、响应请求
交给condutor处理/协调
if conductor------->scheduler----->最适合创建虚拟机的节点
if scheduler 调度失败，
then 将调度失败的信息，存放在cell0中
nova-api会读取cell0数据库，获取到失败的信息/原因，返回给客户端
elif scheduler 调度成功 a节点适合，
then conductor 就会将这个任务交割cell1处理(rabbitmq-cell接受、响应)（cell1管理的范围，不仅仅只有一个节点 ABCD ）
rabbitmq-cell ---->conductor-cell----->交给A节点上的compute进行具体创建---->compute 汇报给cell1数据库------->响应给condutor-cell—>rabbitmq-cell–>nova的conductor
nova-conductor 接受到cell的返回之后，保存在api数据库中(保存实例创建成功的信息)
nova-api组件，会读取api数据库，返回/响应给客户端（若想要获取具体信息，则会访问cell数据库)
7.3 多cell架构
是为了给rabbitmq和mariadb进行分压， 加入condutor-cell组件
mariadb---->全部数据变成只保存的全局信息
rabbitmq---->全部交互传递，一些具体执行的任务，直接交给rabbitmq-cell
condutor---->全部任务的协调分配工作---->把具体任务分配给cell（rabbitmq–cell）
8、Nova部署方案
OpenStack 是一个分布式系统，可以部署到若干节点上，那么接下来大家可能就会问：Nova 的这些服务在物理上应该如何部署呢？
对于 Nova，这些服务会部署在两类节点上：计算节点和控制节点。
计算节点上安装了 Hypervisor，上面运行虚拟机。 由此可知：
1. 只有 nova-compute 需要放在计算节点上。
2. 其他子服务则是放在控制节点上的。
下面我们可以看看实验环境的具体部署情况。 通过在计算节点和控制节点上运行
ps -elf | grep nova 来查看运行的 nova 子服务
计算节点compute只运行了nova-compute子服务
控制节点controller运行了若干nova-*子服务
RabbitMQ 和 MySQL 也是放在控制节点上的。其实控制节点上也可以运行 nova-compute。 这实际上也就意味着 controller 既是一个控制节点，同时也是一个计算节点，也可以在上面运行虚机。
这也向我们展示了 OpenStack 这种分布式架构部署上的灵活性： 可以将所有服务都放在一台物理机上，作为一个 All-in-One 的测试环境； 也可以将服务部署在多台物理机上，获得更好的性能和高可用。
另外，也可以用 nova service-list 查看 nova-* 子服务都分布在哪些节点上
从虚机创建流程看 nova-* 子服务如何协同工作
从学习 Nova 的角度看，虚机创建是一个非常好的场景，涉及的 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、界面或命令行通过RESTful API向keystone获取认证信息。
2、keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
3、界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。
4、nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。
5、keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。
6、通过认证后nova-api和数据库通讯。
7、初始化新建虚拟机的数据库记录。
8、nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
9、nova-scheduler进程侦听消息队列，获取nova-api的请求。
10、nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
11、对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
12、nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
13、nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
14、nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）
15、nova-conductor从消息队队列中拿到nova-compute请求消息。
16、nova-conductor根据消息查询虚拟机对应的信息。
17、nova-conductor从数据库中获得虚拟机对应信息。
18、nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
19、nova-compute从对应的消息队列中获取虚拟机信息消息。
20、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
21、glance-api向keystone认证token是否有效，并返回验证结果。
22、token验证通过，nova-compute获得虚拟机镜像信息(URL)。
23、nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
24、neutron-server向keystone认证token是否有效，并返回验证结果。
25、token验证通过，nova-compute获得虚拟机网络信息。
26、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
27、cinder-api向keystone认证token是否有效，并返回验证结果。
28、token验证通过，nova-compute获得虚拟机持久化存储信息。
29、nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。
