Nova架构

架构概览

• Compute
  Service
  Nova 是 OpenStack 最核心的服务，负责维护和管理云环境的计算资源。
• OpenStack
  作为 IaaS 的云操作系统，虚拟机生命周期管理也就是通过 Nova 来实现的。

• Nova
  处于 Openstak 架构的中心，其他组件都为 Nova 提供支持：

  • Glance 为 VM 提供 image
  • Cinder 和 Swift 分别为 VM 提供块存储和对象存储,像AWS上的S3,我们只需要调用对象存储提供的API就可以了，不一定说要把资源全部存储在本地
  • Neutron 为 VM 提供网络连接，提供L2,L3网络，L2指的是二层网络，二层网络中有虚拟交换机，

      而3层网络中有路由，再往上还有dhcp服务，nat服务（这里包括snat,dnat），ACL服务等等。

Nova架构图

服务与服务之间通过api去建立联系的，服务中的组件与组件之间是通过消息队列去建立联系的
这里的AMQP指的是消息队列的一个协议，不同的组件将消息存入消息队列中，然后别的组件去获取对应的消息，然后进行响应的操作。

Nova中的组件简要介绍

• Nova-api

Nova-api是整个nova服务中对外的一个请求接口，对整个nova资源上的管理的命令，都是通过nova-api进行接收的，接收之后nova-api会将消息放入消息队列中，以便于其他组件操作对应的命令。

• Nova-scheduler

Nova-scheduler从消息队列中拿到例如创建一台虚拟机的命令，然后Nova-scheduler会去调度计算节点，指定虚拟机建立在哪个计算节点上（生产环境中，我们的计算节点有很多个，所以Nova-scheduler会去筛选合适的虚拟机去创建镜像，以便于最大程度上调用每一台机器的资源），在选择好合适的计算节点之后，nova-scheduler会将创建虚拟机的指令发往该计算结点，让其创建一个虚拟机。

在对应计算节点创建虚拟机的时候：

• 计算节点会向glance服务请求对应的镜像资源。
• 如果要添加一个云硬盘，计算节点又会向块存储服务去请求资源。
• 如果是想要请求网络资源，例如请求连接到一台路由器上，计算节点就会向neutron服务请求资源。

• hypervisor

在请求到资源之后，真正创建虚拟机的就是我们的hypervisor，它会调用KVM或者vmware等虚拟机底层技术，并不是说nova-compute直接创建的虚拟机，而是调用了底层虚拟化技术去创建的。

• Nova-conductor

当我们创建完虚拟机之后，我们需要向数据库中存储对应虚拟机的元信息，这时候就由Nova-conductor将我们的这些信息存放在我们的database当中。

• Nova-console

这个是提供VNC，让用户通过VNC以远程访问的方式访问我们的虚拟机实例

• Nova-consoleauth

这个是做一些认证方面的内容

Nova组件介绍

Nova的架构比较复杂，包含很多组件。
这些组件以子服务（后台 deamon 进程）的形式运行，可以分为以下几类：

• API
• Compute Core
• Console Interface
• Database
• Message Queue

**

Nova组件—API

nova-api（重要）

• 接收和响应客户的 API 调用。

• 除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API。 也就是说，如果客户以前使用 Amazon EC2，并且用 EC2 的 API 开发了些工具管理虚机，那么如果现在要换成 OpenStack，这些工具可以无缝迁移到 OpenStack，因为 nova-api 兼容 EC2 API，无需做任何修改。

  • 也就是说，AWS平台和Openstack平台可以将共同使用同一种管理NOVA-API的工具，就可以将两个平台的资源整合在一起。

Nova组件—Compute Core

nova-scheduler（重要）

虚机调度服务，负责决定在哪个计算节点上运行虚机,判断哪个节点优先级更高。例如一个节点的CPU空闲，使用率低，那么这时候运行虚拟机的优先级会越高。实际中的优先级判断有很多种公式，不是像负载均衡那样简单。

nova-compute（重要）

管理虚机的核心服务，通过调用
Hypervisor
API 实现虚机生命周期管理，所以真正创建虚拟机的是底层的虚拟化技术（重点）

Hypervisor（重要）

计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。
不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM，Xen， VMWare 等。

nova-conductor(重要)

经常需要更新数据库，比如更新虚机的状态。
出于安全性和伸缩性的考虑，nova-compute
并不会直接访问数据库，而是将这个任务委托给
nova-conductor，这个我们在后面会详细讨论

Nova组件—Console Interface

nova-console

用户可以通过多种方式访问虚机的控制台：
nova-novncproxy，基于 Web 浏览器的 VNC 访问 nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问 nova-x*vncproxy，基于 Java 客户端的 VNC 访问

nova-consoleauth

负责对访问虚机控制台请亲提供
Token
认证

nova-cert

提供 x509 证书支持

Database

• Nova
  会有一些数据需要存放到数据库中，一般使用
  MySQL。
• 数据库安装在控制节点上。

• Nova 使用命名为 “nova” 的数据库。
  

  Message Queue

• Nova 包含众多的子服务，这些子服务之间需要相互协调和通信。
• 为解耦各个子服务，Nova 通过 Message Queue 作为子服务的信息中转站，它们都通过 Message Queue 联系。

• OpenStack 默认是用 RabbitMQ 作为 Message Queue。
  

  Nova 组件如何协同工作

• 计算节点：只有nova-compute组件

  • 使用ps -elf | grep nova-*查看组件
• S nova 1252 1 2 80 0 - 415689 ep_pol 11:31 ? 00:00:06 /usr/bin/python2 /usr/bin/nova-compute

• S root 1668 1397 0 80 0 - 28206 pipe_w 11:36 pts/0 00:00:00 grep --color=auto nova-*

• 控制节点：若干个nova-*子服务，RabbitMQ、MySQL

  • 使用ps -elf | grep nova-*查看组件
• S nova 982 1 4 80 0 - 100562 ep_pol 11:31 ? 00:00:02 /usr/bin/python2 /usr/bin/nova-novncproxy --web /usr/share/novnc/
• S nova 983 1 7 80 0 - 93841 ep_pol 11:31 ? 00:00:04 /usr/bin/python2 /usr/bin/nova-consoleauth
• S nova 985 1 10 80 0 - 107396 poll_s 11:31 ? 00:00:06 /usr/bin/python2 /usr/bin/nova-api
• S nova 988 1 7 80 0 - 94395 ep_pol 11:31 ? 00:00:04 /usr/bin/python2 /usr/bin/nova-scheduler
• S nova 995 1 7 80 0 - 93364 poll_s 11:31 ? 00:00:04 /usr/bin/python2 /usr/bin/nova-conductor
• S nova 1325 990 0 80 0 - 81175 poll_s 11:31 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
• S nova 1326 990 0 80 0 - 97559 poll_s 11:31 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
• S nova 1331 990 0 80 0 - 81175 poll_s 11:31 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
• S nova 2004 995 6 80 0 - 95227 ep_pol 11:31 ? 00:00:01 /usr/bin/python2 /usr/bin/nova-conductor
• S nova 2005 995 6 80 0 - 95598 ep_pol 11:31 ? 00:00:01 /usr/bin/python2 /usr/bin/nova-conductor
• S nova 2011 985 4 80 0 - 109014 ep_pol 11:31 ? 00:00:00 /usr/bin/python2 /usr/bin/nova-api
• S nova 2012 985 4 80 0 - 109014 ep_pol 11:31 ? 00:00:00 /usr/bin/python2 /usr/bin/nova-api
• S nova 2015 985 4 80 0 - 109138 ep_pol 11:31 ? 00:00:00 /usr/bin/python2 /usr/bin/nova-api
• S nova 2016 985 3 80 0 - 109138 ep_pol 11:31 ? 00:00:00 /usr/bin/python2 /usr/bin/nova-api

• S root 2037 1875 0 80 0 - 28207 pipe_w 11:32 pts/0 00:00:00 grep --color=auto nova-*

• 如果控制节点上也运行nova-compute，意味着它还充当计算节点，充分展示Openstack分布部署的灵活性。

从虚机创建流程看nova子服务如何协同工作

①  客户向 API（nova-api）发送请求（创建VM）
②  API
对请求认证授权后，向
Messaging（RabbitMQ）发送消息
③  Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A
④  计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚机。
⑤  在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。

（以上仅仅是nova-*子服务之间的协同工作，创建VM（镜像，网络，存储等等））

Openstack通用设计思路

• API前端服务
• Scheduler调度服务
• Worker工作服务
• Driver框架
• Messaging服务
• Database

我们如果将这些服务和组件的作用以及互相的联系能够讲清楚，就很ok了。

API前端服务

• 每个 OpenStack 组件可能包含若干子服务，其中必定有一个 API 服务负责接收客户请求。
• 以 Nova 为例，nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。 当客户需要执行虚机相关的操作，能且只能向 nova-api 发送 REST 请求。 这里的客户包括终端用户、命令行和 OpenStack 其他组件。

• 设计 API 前端服务的好处在于：

  • 1. 对外提供统一接口，隐藏实现细节
  • 2. API 提供 REST 标准调用服务，便于与第三方系统集成
  • 3. 可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 nova-api 进程 。

Scheduler调度服务

• 对于某项操作，如果有多个实体都能够完成任务，那么通常会有一个 scheduler 负责从这些实体中挑选出一个最合适的来执行操作。
• 在前面的例子中，Nova 有多个计算节点。 当需要创建虚机时，nova-scheduler 会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机。
• 调度服务就好比是一个开发团队中的项目经理，当接到新的开发任务时，项目经理会评估任务的难度，考察团队成员目前的工作负荷和技能水平，然后将任务分配给最合适的开发人员。
• 除了 Nova，块服务组件 Cinder 也有 scheduler 子服务，后面我们会详细讨论。

Worker工作服务

• 调度服务只管分配任务，真正执行任务的是 Worker 工作服务。

• 在 Nova 中，这个 Worker 就是 nova-compute 了。 将 Scheduler 和 Worker 从职能上进行划分使得 OpenStack 非常容易扩展：（这样就让我们的云系统扩展性变得非常高）

  • ①  当计算资源不够了无法创建虚机时，可以增加计算节点（增加 Worker）
  • ②  当客户的请求量太大调度不过来时，可以增加 Scheduler

Nova cells的引入

• 降低数据库和消息队列的访问瓶颈

解决数据库瓶颈的办法就是将数据库进行解耦，原先是nova将整个服务的数据信息都存储在nova数据库中，而现在类似于将nova数据库进行分割，将关于nova-api的信息单独的分割出来，这样就可以让nova-api直接去访问这部分的数据库，但是整个nova数据依旧是由conductor去访问。

Driver框架

• OpenStack 作为开放的 Infrastracture as a Service 云操作系统，支持业界各种优秀的技术。
  这些技术可能是开源免费的，也可能是商业收费的。 这种开放的架构使得 OpenStack 能够在技术上保持先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。
• 那 OpenStack 的这种开放性体现在哪里呢？ 一个重要的方面就是采用基于 Driver 的框架。
• 以 Nova 为例，OpenStack 的计算节点支持多种 Hypervisor。 包括 KVM, Hyper-V, VMWare, Xen, Docker,
  LXC 等。

• Nova-compute 为这些 Hypervisor 定义了统一的接口，hypervisor 只需要实现这些接口，就能以 driver 的形式即插即用到 OpenStack 中
  

  Driver框架图

  
  
  nova-compute提供了一个统一的标准，所有的虚拟化技术都要实现这个标准然后才能接入openstack中。

补充：现在主流都是KVM虚拟化技术，2015年前后是KVM和Xen在竞争，2015年之后由于KVM被红帽收购到内核标准当中所以KVM就比较多了。

Messaging服务

Messaging是nova-*子服务交互的中枢，作为信息中转站。
为什么不能让API直接调用Scheduler，Scheduler直接调用Compute呢？

• 同步调用：

  • ①API直接调用Scheduler的接口
  • ②API发送请求后需要一直等待，直到Scheduler完成对compute的调度，将结果返回
• 异步调用：

• ①API通过Messaging间接调用Scheduler

  • ②API发送请求后不需要等待，继续工作
  • ③Scheduler从Messaging接收到请求后执行调度操作，完成结果也通过Messaging返回给API

所以在Openstack这类分布式系统中，通常采用异步调用的方式，其好处是：

• ①解耦各子服务：子服务不需要知道其他服务在哪里运行，只需要发送消息给Messaging 就能完成调用。
• ②提高性能：异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。
• ③提高伸缩性：子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。

Database

• OpenStack 各组件都需要维护自己的状态信息。
• 比如 Nova 中有虚拟机的规格、状态（虚拟机的运行，暂停），这些信息都是在数据库中维护的。（比如购买云主机时，配置为1CPU，2G内存，40G存储，1兆带宽等等，这些信息就是虚拟机的规格信息）
• 每个 OpenStack 组件在 MySQL 中有自己的数据库