openstack-nova

介绍

nova是openstack最核心的服务,负责维护和管理云环境的计算资源。
openstack作为IAAS的云操作系统,虚拟机生命周期管理也就是通过nova来实现的。

用途及功能

  1. 实例生命管理周期;
  2. 管理计算资源;
  3. 网络和认证管理;
  4. rest风格的api;
  5. 异步的一致性通信;
  6. hypervisor透明:支持xen、xenserver/xcp、KVM、UML、VMware、vsphere and hyper-V。

在这里插入图片描述
在上图中可以看到,nova出于openstack架构的中心,其他组件都为nova提供支持:glance为VM提供image cinder和swift分别为VM提供块存储和对象存储neutron为vm提供网络连接。

架构

在这里插入图片描述
nova的架构比较复杂,包含很多组件。这些组件以子服务(后台deamon)的形式运行,可以分为以下几类:

API

nova-api是整个nova组件的门户,接受和响应客户的API调用。所有对nova的请求都先由nova-api处理。nova-api向外界暴露若干HTTP REST API接口。
在keystone中我们可以查询nova-api 的endponits。
在这里插入图片描述
客户端就可以将请求发送到endponits指定的地址,想nova-api请求操作。当然,作为最终用户的我们不会直接发送rest api请求。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,无需做任何修改。
computer core

nova-scheduler
  • nova-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 默认的调度器,调度过程分为两步:

  • 通过过滤器(filter)选择满足条件的计算节点(运行 nova-compute)
  • 通过权重计算(weighting)选择在最优(权重值最大)的计算节点上创建 Instance。

Nova 允许使用第三方 scheduler,配置 scheduler_driver 即可。 这又一次体现了OpenStack的开放性。Scheduler 可以使用多个 filter 依次进行过滤,过滤之后的节点再通过计算权重选出最适合的节点。
在这里插入图片描述
上图是调度过程的一个示例:

  • 最开始有 6 个计算节点 Host1-Host6
  • 通过多个 filter 层层过滤,Host2 和 Host4 没有通过,被刷掉了
  • Host1,Host3,Host5,Host6 计算权重,结果 Host5 得分最高,最终入选

当 Filter scheduler 需要执行调度操作时,会让 filter 对计算节点进行判断,filter 返回 True 或 False。经过前面一堆 filter 的过滤,nova-scheduler 选出了能够部署 instance 的计算节点。

如果有多个计算节点通过了过滤,那么最终选择哪个节点呢?

Scheduler 会对每个计算节点打分,得分最高的获胜。 打分的过程就是 weight,翻译过来就是计算权重值,那么 scheduler 是根据什么来计算权重值呢?

目前 nova-scheduler 的默认实现是根据计算节点空闲的内存量计算权重值: 空闲内存越多,权重越大,instance 将被部署到当前空闲内存最多的计算节点上。

nova-compute

nova-compute 是管理虚机的核心服务,在计算节点上运行。通过调用Hypervisor API实现节点上的 instance的生命周期管理。 OpenStack 对 instance 的操作,最后都是交给 nova-compute 来完成的。 nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。
通过Driver架构支持多种Hypervisor
Hypervisor是计算节点上跑的虚拟化管理程序,虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM,Xen, VMWare 等。nova-compute 为这些 Hypervisor 定义了统一的接口,Hypervisor 只需要实现这些接口,就可以 Driver 的形式即插即用到 OpenStack 系统中。 下面是Nova Driver的架构示意图:
在这里插入图片描述

nova-conductor:

nova-compute 经常需要更新数据库,比如更新和获取虚机的状态。 出于安全性和伸缩性的考虑,nova-compute 并不会直接访问数据库,而是将这个任务委托给 nova-conductor。
在这里插入图片描述

这样做有两个显著好处:

  1. 更高的系统安全性
  2. 更好的系统伸缩性
Interface

nova-console: 用户可以通过多种方式访问虚机的控制台:
nova-novncproxy: 基于 Web 浏览器的 VNC 访问
nova-spicehtml5proxy: 基于 HTML5 浏览器的 SPICE 访问
nova-xvpnvncproxy: 基于 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。 MQ 是 OpenStack 的核心基础组件,我们后面也会详细介绍。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值