掌握 cinder-scheduler 调度逻辑 - 每天5分钟玩转 OpenStack(48)

上一节我们详细讨论了 cinder-api 和 cinder-volume,今天讨论另一个重要的 Cinder 组件 cinder-scheduler。

创建 Volume 时,cinder-scheduler 会基于容量、Volume Type 等条件选择出最合适的存储节点,然后让其创建 Volume。

下面介绍 cinder-scheduler 是如何实现这个调度工作的。

在 /etc/cinder/cinder.conf 中,cinder 通过 scheduler_driver, scheduler_default_filters 和 scheduler_default_weighers 这三个参数来配置 cinder-scheduler。

Filter scheduler

Filter scheduler 是 cinder-scheduler 默认的调度器。

scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler

与 Nova 一样,Cinder 也允许使用第三方 scheduler,配置 scheduler_driver 即可。

scheduler 调度过程如下:

  1. 通过过滤器(filter)选择满足条件的存储节点(运行 cinder-volume)
  2. 通过权重计算(weighting)选择最优(权重值最大)的存储节点。

可见,cinder-scheduler 的运行机制与 nova-scheduler 完全一样。

Filter

当 Filter scheduler 需要执行调度操作时,会让 filter 对计算节点进行判断,filter 返回 True 或者 False。

cinder.conf 中 scheduler_default_filters 选项指定 filter scheduler 使用的 filter,默认值如下:

scheduler_default_filters = AvailabilityZoneFilter, CapacityFilter, CapabilitiesFilter

Filter scheduler 将按照列表中的顺序依次过滤:

AvailabilityZoneFilter

为提高容灾性和提供隔离服务,可以将存储节点和计算节点划分到不同的 Availability Zone 中。例如把一个机架上的机器划分在一个 Availability Zone 中。OpenStack 默认有一个命名为“Nova” Availability Zone 的,所有的节点初始都是放在“Nova”中。用户可以根据需要创建自己的 Availability Zone。

创建 Volume 时,需要指定 Volume 所属的 Availability Zone。

cinder-scheduler 在做 filtering 时,会使用 AvailabilityZoneFilter 将不属于指定 Availability Zone 的存储节点过滤掉。

CapacityFilter

创建 Volume 时,用户会指定 Volume 的大小。CapacityFilter 的作用是将存储空间不能满足 Volume 创建需求的存储节点过滤掉。

CapabilitiesFilter

不同的 Volume Provider 有自己的特性(Capabilities),比如是否支持 thin provision 等。Cinder 允许用户创建 Volume 时通过 Volume Type 指定需要的 Capabilities。

Volume Type 可以根据需要定义若干 Capabilities,详细描述 Volume 的属性。VolumeVolume Type 的作用与 Nova 的 flavor 类似。

Volume Type 在 Admin -> System -> Volume 菜单里管理

通过 Volume Type 的 Extra Specs 定义 Capabilities

Extra Specs 是用 Key-Value 的形式定义。
不同的 Volume Provider 支持的 Extra Specs 不同,需要参考 Volume Provider 的文档。

上图所示的 Volume Type 只有一个 Extra Specs “volume_backend_name”,这是最重要也是必须的 Extra Specs。

cinder-volume 会在自己的配置文件 /etc/cinder/cinder.conf 中设置“volume_backend_name”这个参数,其作用是为存储节点的 Volume Provider 命名。

这样,CapabilitiesFilter 就可以通过 Volume Type 的“volume_backend_name”筛选出指定的 Volume Provider。

不同的存储节点可以在各自的 cinder.conf 中配置相同的 volume_backend_name,这是允许的。因为虽然存储节点不同,但它们可能使用的是一种 Volume Provider。

如果在第一步 filtering 环节选出了多个存储节点,那么接下来的 weighting 环节会挑选出最合适的一个节点。

Weighter

Filter Scheduler 通过 scheduler_default_weighers 指定计算权重的 weigher,默认为 CapacityWeigher。

scheduler_default_weighers = CapacityWeigher

如命名所示,CapacityWeigher 基于存储节点的空闲容量计算权重值,空闲容量最大的胜出。

下一节我们将开始通过各种场景学习 Cinder。

时间: 2024-09-20 21:34:28

掌握 cinder-scheduler 调度逻辑 - 每天5分钟玩转 OpenStack(48)的相关文章

Cinder 组件详解 - 每天5分钟玩转 OpenStack(47)

本节我们将详细讲解 Cinder 的各个子服务. cinder-api cinder-api 是整个 Cinder 组件的门户,所有 cinder 的请求都首先由 nova-api 处理.cinder-api 向外界暴露若干 HTTP REST API 接口.在 keystone 中我们可以查询 cinder-api 的 endponits. 客户端可以将请求发送到 endponits 指定的地址,向 cinder-api 请求操作. 当然,作为最终用户的我们不会直接发送 Rest API 请求

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

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

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

  API 前端服务 每个 OpenStack 组件可能包含若干子服务,其中必定有一个 API 服务负责接收客户请求. 以 Nova 为例,nova-api 作为 Nova 组件对外的唯一窗口,向客户暴露 Nova 能够提供的功能. 当客户需要执行虚机相关的操作,能且只能向 nova-api 发送 REST 请求. 这里的客户包括终端用户.命令行和 OpenStack 其他组件. 设计 API 前端服务的好处在于: 1. 对外提供统一接口,隐藏实现细节 2. API 提供 REST 标准调用服务

Create Volume 操作(Part II) - 每天5分钟玩转 OpenStack(51)

  上一节我们讨论了 Cinder 创建 Volume 的第一部分,cinder-api 的操作,本节继续第二部分,cinder-scheduler 调度工作. cinder-scheduler 执行调度 cinder-scheduler 执行调度算法,通过 Filter 和 Weigher 挑选最优的存储节点 日志为 /opt/stack/logs/c-sch.log. cinder-scheduler 通过 Flow volume_create_scheduler 执行调度工作. 该 Flo

学习 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,方法是将下面的内容传给

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

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

Create Volume 操作(Part I) - 每天5分钟玩转 OpenStack(50)

前面已经学习了 Cinder 的架构和相关组件,从本节我们开始详细分析 Cinder 的各种操作,首先讨论 Cinder 如何创建 volume. Create 操作流程如下: 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(cinder-api)发送请求:"帮我创建一个 volume". API 对请求做一些必要处理后,向 Messaging(RabbitMQ)发送了一条消息:"让 Scheduler 创建一个 volume". Sche

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

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