OpenStack 通用设计思路 - 每天5分钟玩转 OpenStack(25)

 

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 非常容易扩展:

  1. 当计算资源不够了无法创建虚机时,可以增加计算节点(增加 Worker)
  2. 当客户的请求量太大调度不过来时,可以增加 Scheduler

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 中。 下面是 nova driver 的架构示意图

在 nova-compute 的配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪种 Hypervisor 的 driver

在我们的环境中因为是 KVM,所以配置的是 Libvirt 的 driver。

不知大家是否还记得我们在学习 Glance 时谈到:
OpenStack 支持多种 backend 来存放 image。
可以是本地文件系统,Cinder,Ceph,Swift 等。

其实这也是一个 driver 架构。
只要符合 Glance 定义的规范,新的存储方式可以很方便的加入到 backend 支持列表中。

再后面 Cinder 和 Neutron 中我们还会看到 driver 框架的应用。

Messaging 服务

在前面创建虚机的流程示意图中,我们看到 nova-* 子服务之间的调用严重依赖 Messaging。
Messaging 是 nova-* 子服务交互的中枢。

以前没接触过分布式系统的同学可能会不太理解为什么不让 API 直接调用Scheduler,或是让Scheuler 直接调用 Compute,而是非要通过 Messaging 进行中转。
这里做一些解释。

程序之间的调用通常分两种:同步调用和异步调用。

同步调用

API 直接调用 Scheduler 的接口就是同步调用。
其特点是 API 发出请求后需要一直等待,直到 Scheduler 完成对 Compute 的调度,将结果返回给 API 后 API 才能够继续做后面的工作。

异步调用

API 通过 Messaging 间接调用 Scheduler 就是异步调用。
其特点是 API 发出请求后不需要等待,直接返回,继续做后面的工作。
Scheduler 从 Messaging 接收到请求后执行调度操作,完成后将结果也通过 Messaging 发送给 API。

在 OpenStack 这类分布式系统中,通常采用异步调用的方式,其好处是:

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

在后面各章节,我们都能看到 Messaging 的应用。

Database

OpenStack 各组件都需要维护自己的状态信息。
比如 Nova 中有虚机的规格、状态,这些信息都是在数据库中维护的。
每个 OpenStack 组件在 MySQL 中有自己的数据库。

小结

Nova 是 OpenStack 中最重要的组件,也是很典型的组件。
Nova 充分体现了 OpenStack 的设计思路。
理解了这种思路,再来学习 OpenStack 的其他组件就能够举一反三,清晰容易很多。

我们在后面 Cinder 和 Neutron 的学习中还会回顾这些设计思路。

时间: 2024-10-23 21:50:24

OpenStack 通用设计思路 - 每天5分钟玩转 OpenStack(25)的相关文章

Nova 组件如何协同工作 - 每天5分钟玩转 OpenStack(24)

Nova 物理部署方案 前面大家已经看到 Nova 由很多子服务组成,同时我们也知道 OpenStack 是一个分布式系统,可以部署到若干节点上,那么接下来大家可能就会问: Nova 的这些服务在物理上应该如何部署呢? 对于 Nova,这些服务会部署在两类节点上:计算节点和控制节点. 计算节点上安装了 Hypervisor,上面运行虚拟机. 由此可知: 1. 只有 nova-compute 需要放在计算节点上. 2. 其他子服务则是放在控制节点上的. 下面我们可以看看实验环境的具体部署情况. 通

写在最前面 - 每天5分钟玩转 OpenStack(1)

<每天5分钟玩转 OpenStack>是一个 OpenStack 教程,这是第 1 篇. 这个教程有下面两个特点: 系统讲解 OpenStack 从架构到各个组件:从整体到细节逐一讨论 重实践并兼顾理论 主要从实际操作的角度带着大家学习 OpenStack.   为啥要写这个? 简单回答是:因为OpenStack 学习难度大,但如果掌握了价值会很大 先做一个自我介绍吧. 本人网名CloudMan,在 IT 这个行当已经摸爬滚打了十多年,05年之前是搞上层应用开发的,那时候 Java 比较火,所

学习 OpenStack 的方法论 - 每天5分钟玩转 OpenStack(150)

作为 OpenStack 的核心教程,我们已经到了最后总结的部分. OpenStack 目前已经有好几十个模块,本教程讨论的是最最重要的核心模块:Keystone,Nova,Glance,Cinder 和 Neutron.请大家看下图: 此图截自 https://www.openstack.org/software/project-navigator/,这是 OpenStack 官方定义的 6 个 Core Service.每个模块都会从三个维度来衡量: ADOPTION - 采用度 MATUR

cloud-init 典型应用 - 每天5分钟玩转 OpenStack(174)

本节介绍几个 cloud-init 的典型应用:设置 hostanme,设置用户初始密码,安装软件.  设置 hostname cloud-init 默认会将 instance 的名字设置为 hostname.但这样不太方便,有时希望能够将二者分开,可利用 cloud-init 的set_hostname 模块实现.set_hostname 它会查询 metadata 中 hostname 信息,默认值就是 instance 的名字.我们可以指定自己的 hostname,方法是将下面的内容传给

Neutron 架构 - 每天5分钟玩转 OpenStack(67)

前面我们讨论了 Neutron 的基本概念,今天我们开始分析 Neutron 的架构. Neutron 架构 与 OpenStack 的其他服务的设计思路一样,Neutron 也是采用分布式架构,由多个组件(子服务)共同对外提供网络服务. Neutron 由如下组件构成: Neutron Server对外提供 OpenStack 网络 API,接收请求,并调用 Plugin 处理请求. Plugin处理 Neutron Server 发来的请求,维护 OpenStack 逻辑网络的状态, 并调用

搭建 OpenStack 实验环境 - 每天5分钟玩转 OpenStack(16)

在学习 OpenStack 各服务之前,让我们先搭建起一个实验环境. 毋庸置疑,一个看得到摸得着而且允许我们随便折腾的 OpenStack 能够提高我们的学习效率. 因为是我们自己学习用的实验环境,CloudMan 推荐使用 DevStackhttp://docs.openstack.org/developer/devstack/DevStack 丰富的选项让我们能够灵活地选取和部署想要的 OpenStack 服务,非常适合学习和研究. 部署拓扑 首先我们来设计 OpenStack 的部署拓扑.

虚拟化 - 每天5分钟玩转 OpenStack(2)

  OpenStack是云操作系统,要学习OpenStack,首先需要掌握一些虚拟化和云计算的相关知识. 虚拟化 虚拟化是云计算的基础.简单的说,虚拟化使得在一台物理的服务器上可以跑多台虚拟机,虚拟机共享物理机的 CPU.内存.IO 硬件资源,但逻辑上虚拟机之间是相互隔离的. 物理机我们一般称为宿主机(Host),宿主机上面的虚拟机称为客户机(Guest). 那么 Host 是如何将自己的硬件资源虚拟化,并提供给 Guest 使用的呢?这个主要是通过一个叫做 Hypervisor 的程序实现的.

Neutron 功能概述 - 每天5分钟玩转 OpenStack(65)

从今天开始,我们将学习 OpenStack 的 Networking Service,Neutron.Neutron 的难度会比前面所有模块都大一些,内容也多一些.为了帮助大家更好的掌握 Neutorn,CloudMan 也会分析地更详细一些. Neutron 概述 传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备:而云环境下的网络已经变得非常复杂,特别是在多租户场景里,用户随时都可能需要创建.修改和删除网络,网络的连通性和隔离已经不太可能通过手工配置来保证了. 如何快速响

Migrate Instance 操作详解 - 每天5分钟玩转 OpenStack(40)

Migrate 操作的作用是将 instance 从当前的计算节点迁移到其他节点上. Migrate 不要求源和目标节点必须共享存储,当然共享存储也是可以的. Migrate 前必须满足一个条件:计算节点间需要配置 nova 用户无密码访问. 下面是 Migrate instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-scheduler 执行调度 nova-scheduler 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤.