OpenStack Nova hacking和读书笔记

本文深入探讨了OpenStack Nova的核心组件和服务,包括Nova API、Compute、Conductor和Scheduler。Nova通过无共享架构,利用消息队列实现模块间的解耦通信。文章详细阐述了Nova API的执行过程,Nova Conductor的角色以及数据库访问,以及Nova Scheduler的调度策略。此外,还介绍了Nova Compute如何管理虚拟机状态和Virt Driver,特别是LibVirt + KVM及VMwareVCDriver的集成。
摘要由CSDN通过智能技术生成

OpenStack Nova 设计与实现

1. Nova

OpenStack采用一种无共享的、基于消息队列的架构,解耦的各模块组合在一起构成了一个统一的IaaS云。
这里写图片描述

Nova是OpenStack生态中最重要的一个核心组件,管理云生态中的计算功能,控制着一个个虚拟机的状态变迁与生老病死,管理着主机之间的资源分配等等。相比于其他的OpenStack项目,Nova的功能已经相当完备和稳定,很多厂商都会在部署时候直接使用Nova的发行版本,然后针对自身需求对网络和存储进行二次开发。

Nova的服务简介

这里写图片描述

目前Nova主要有API、Compute、Conductor、Scheduler四个核心服务所组成,它们之间通过AMQP消息队列通信。(一般来说,OpenStack的项目间是通过RESTful来通信的,项目内部不同的服务进程是通过消息总线进行通信的。这样既可以保证各项目的对外提供服务的接口可以被不同的客户端高效支持,又可以保证项目内部通信接口的可扩展性和可靠性,以支持大规模的部署)。

  • API是进入Nova的Http接口。
  • Compute是用于与VMM交互来运行虚拟机并管理虚拟机声明周期的(通常是一个主机host运行一个compute服务)。
  • Scheduler从资源池中选择最合适的计算节点来创建新的虚拟机实例。
  • Conductor为数据库访问提供一层安全保障。设计目标是希望设计数据库的操作的都通过Conductor。

Oslo项目

oslo是OpenStack通用库,包括了众多不需要重复发明的“轮子”。主要的作用就是把OpenStack里面通用的架构抽象提取出来形成一个代码库,和其他的第三方Python库一样,只需要在项目中import对应的库就行了。Oslo库包括很多的子项目,下面列举一些进行简单的介绍:

  • Cliff(Command Line Formulation Framework):可以用来帮助构建命令行程序。主程序只负责基本的命令行参数的解析,然后调用各个子命令去执行不同的操作。
  • oslo.config:用于接续命令行和配置文件中的配置选项,是oslo的第一个项目。
  • oslo.db:针对SQLAlchemy访问的抽象。
  • oslo.i18n:对Python gettext模块的封装,主要用于字符串的翻译和国际化。
  • oslo.messaging:为OpenStack各个项目使用RPC和事件通知提供一套统一的接口。
  • stevedore:运行时动态载入代码。
  • oslo.policy:负责policy的验证和rules的管理。
  • oslo.rootwrap:让其他OpenStack服务以root身份执行shell命令。一般来说OpenStack的服务都是以非特权用户的身份运行的。
  • oslo.test:提供单元测试的基础框架。

Nova 的源码结构

以下是简略版的Nova项目地图,详细版的可以参考
https://github.com/openstack/nova.git

├——etc
     └—— nova            --Nova配置文件
├——nova
     ├—— api     --Nova API服务
          ├——ec2       --EC2 API支持
          ├——openstack    --OpenStack API
     ├——cmd      --各个Nova服务的入口程序
     ├——compute     --Nova compute服务
     ├——conductor    --Nova Conductor服务
     ├——db                   --数据库操作
     ├——image            --Glance接口抽象
     ├——objects          -- Object Module
     ├——scheduler     --Nova scheduler服务
     ├——tests              --单元测试
     ├——virt                 --Hypervisor driver
     ├——volume --Cinder接口抽象
├——setup.cfg               --项目源码地图

Setup.cfg

setup.cfg文件是浏览OpenStack代码中最依仗的文件,可以引导我们去认识一个新的项目,并了解它的代码结构。
入口点是entry_points这个section,这里会定义各个服务的入口点和定义资源所对应的代码目录等:
nova服务全集

Nova的其他服务

Nova除了上面的四个主要服务之外,还提供很多其他的服务:

  • Nova-all:用于启动所有的nova服务的辅助脚本
  • Nova-cells:Cell模块允许用户在不影响现有的OpenStack云环境的前提下,增强横向扩展、大规模部署能力。Cell模块启动以后,OpenStack云环境通过添加子cell的方式进行拓展。Nova-cells负责各个cell之间的通信,以及为一个新的虚拟机实例选择合适的cell,所以每个cell都需要运行nova-cells服务。详细参考链接
    Figure 1  Regions、Cells、Availability Zones、Host Aggregates的概念

  • Nova-cert:管理X509证书。

  • Nova-manage:提供很多与Nova的维护和管理相关的功能。
  • Nova-novncproxy:Nova提供了novncproxy代理支持用户通过vnc访问虚拟机。
  • Nova-rootwrap:用于在OpenStack运行过程中以root身份运行某些shell命令。

2. Nova API

Nova API是访问和使用Nova服务的唯一途径。作为一个中间角色,Nova API把客户端的请求传达给Nova服务,待Nova服务处理完成以后再将处理结果返回客户端。
Nova API是被要求保持高度的稳定,名称以及返回的数据结构都不能轻易的改变。目前在Liberty版本中使用的Nova API版本是v2.1。学习Nova API的设计思路与执行过程,有助于我们对OpenStack有更好的理解。

Nova API的目录结构

这里写图片描述

对于OpenStack来说,每个API都对应着一种资源,在OpenStack共定义两种类型的资源,核心资源与扩展资源。

  • 核心资源:云平台中最基础的资源,如image,servers,volume,ips等。
  • 扩展资源:扩展资源如keypair,cell,floatingIP等。

Nova API执行过程

这里写图片描述

Nova API的执行过程主要包括3个阶段:
1. novaclient将用户命令转换成标准的HTTP请求
2. Paste Deploy将请求路由到具体的WSGI Application
3. WSGI Application将请求路由

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值