openstack Nova模块概览

服务器

浏览数:34

2019-11-2

背景

本文更多的是基于代码层面对openstack nova服务进行简单概述的。

概念

Nova是Openstack最核心的服务模块,负责管理和维护云计算环境的计算资源,负责整个云环境虚拟机生命周期的管理。
Nova位于Openstack架构的中心,其他服务或者组件(比如Glance、Cinder、Neutron等)对它提供支持,另外它本身的架构也比较复杂,包括很多组件:

  • API
  • Compute Core
  • DB
  • Console Interface
  • MQ

下面就这些组件及组件间如何协同工作来一一展开,不过在介绍这些之前,我们有必要了解一下Nova的设计思想。

设计思路

nova架构.png

其实,这种架构思路也是openstack的通用设计思路,比如cinder/neutron基本上也是采用这种设计思路来的。

API

负责接收客户端请求,nova-api 作为 Nova 组件对外的唯一窗口,向客户暴露 Nova 能够提供的功能。当客户端需要执行虚机操作,客户端只能通过这些Rest API来完成,另外,这里的客户端指的是终端用户、命令行和 OpenStack 其他组件。

Nova Scheduler

当上面API的请求可以在多台实例或者节点上完成时,Scheduler可以根据当时的资源情况选择最合适的实例或者节点来执行请求。

Worker

Nova Worker其实质就是计算节点的nova-compute服务,前面Scheduler负责分发任务,而它则是负责执行任务。

Driver框架

在计算节点运行虚机,那必须要有Hypervisor来支持,而计算节点会支持多种Hypervisor(包括KVM, Hyper-V, VMWare, Xen, Docker, LXC等),nova-compute为Hypervisor定义统一接口,只要这些hypervisor实现了这些接口,就可以 以driver 的形式即插即用到 OpenStack 中,这样在技术上保持先进性,具有很强的竞争力,同时又不会造成厂商锁定(Lock-in),具有很大的灵活和开放性。

DB

通过数据库来维护Nova虚机的状态信息,比如MySQL会有Nova撞门的数据库。

MQ

在openstack这样的分布式系统中,一般程序的调用都是采用异步调用处理的,而nova各组件间的协同工作是通过消息队列来实现的,默认采用RabbitMQ。

一般工作流程

用户发送一个nova http请求或者服务,通常都会遵循下面的流程:


工作流程图

大概解释一下:

  • 用户发送http请求至nova api,nova api会把这个请求放到mq;
  • nova scheduler从消息队列里获取到请求,开始决定由哪个计算节点去执行请求,后把结果存放到消息队列里;
  • nova compute从消息队列里知道了由哪个节点去执行请求后,分派该节点去执行用户请求并返回结果至消息队列;
  • 具体执行过程中产生的一些中间态信息(比如虚机的运行状态、bdm信息等)通过nova conductor保存到数据库;

故障分析

当我们实际在虚机上进行操作时,可能会碰到各种各样的问题,这时我们可以分析nova的日志来解决,一般情况下日志会存放到/var/log/nova/目录下边,如果不够详尽,我们还可以通过修改nova配置文件(/etc/nova/nova.conf)打开debug开关来得到更详细的日志信息。

作者:VienFu