PC 调度器

注意：该蓝图似乎已被放弃，最后编辑时间为 2011 年。

• Launchpad 条目：NovaSpec:foo 或 SwiftSpec:foo
• 创建:
• 贡献者:

总结

云计算调度器需要实现基础设施的核心策略，以便有效地管理数据中心环境中的工作负载。诸如将工作负载与计算资源匹配、管理电源和散热环境、基于安全需求和最佳服务级别协议（例如服务质量）进行调度决策等策略，对于最佳数据中心利用率至关重要。工作负载放置还需要满足网络和存储能力施加的任何要求。该蓝图描述了一个旨在满足这些要求的调度器。

发布说明

该调度器最初将作为一个简单的引擎与默认策略插件集成。然后，该简单调度器可以通过利用存储在 DataBase 系统中的策略和约束来扩展为更复杂的插件。

原理

该蓝图提出了一项将强大的、功能丰富的调度器整合到 OpenStack 中，以实现最佳工作负载放置和生命周期管理的努力。

用户故事

大型数据中心运营商需要在复杂环境中使用的核心功能。功能应该从密集工作负载放置开始，然后转向涉及电源、散热、安全和 SLA 的考虑因素。

前提条件

1. 该调度器是分布式的（意味着每个实例都是无状态的），并共享一个用于当前状态的通用存储。该通用存储还用于保存策略和约束。
2. 需要可替换的模块来支持用于策略和约束评估的各种算法。例如，不能在所有情况下使用单一算法。例如，不同的客户希望更加重视电源与 QoS，或者相反。

设计

基于策略和约束的调度器 (PCS) 将是一个插件，用于扩展当前 Nova 调度器的功能。PCS 将与网络和卷控制器协同工作，以提供强大、可靠、可信和透明的调度决策。PCS 不仅需要工作，其算法还必须提供可重复、可靠、快速、可预测和一致的结果。

关键需求

• 基于策略和约束的调度器属性
  • 调度器是分布式的（每个实例都是无状态的），共享用于系统范围数据库中状态、策略和约束的通用存储。
  • 允许从子调度器或工作者向上汇总到所有调度层的数据
  • 调度器应该能够将工作负载放置请求发送到子调度器或工作者
  • 所有操作都经过记录
• 策略/约束数据库属性
  • 策略和约束存储在版本控制的数据库中
  • 数据库支持回滚和更改日志
• 输入
  • 服务器/区域可以可选地通信能力、资源可用性级别和对策略属性的支持。调度器应将这些信息存储在策略/约束数据库中。
  • 策略是根据实例需求形成的，例如？安全实例？、?灵活网络实例？等。
  • 策略可以导致在区域内形成服务器组，以服务于该策略
  • 数据库中的主机硬件信息允许将调度器策略转移到硬件策略（如果适用）。
  • 工作负载特征
  • 属性数据：计算、安全/信任、电源、网络、存储和 QoS
  • 约束：电源上限
  • 代表工作负载需求的工作负载元数据（由客户或云服务提供商提供，并且可能由 CSP 验证）
• 决策
  • PCS 引擎使用通用的策略/约束数据库
  • 未通告能力的 Worker/Server/区域默认为标准调度器操作
  • 子调度器必须响应工作负载放置请求（接受/拒绝）
  • 子调度器必须解释工作负载放置请求。请求可能包括策略和工作负载元数据
  • 调度器必须能够根据 Worker/子调度器指示重新放置工作负载。
  • Worker/子调度器可以指示重新放置工作负载的请求，基于受支持的策略。
• 策略类型（可扩展）
  • 性能（为实现最佳性能选择正确的计算元素）
  • 信任（将工作负载放置在受信任服务器和受信任环境中：节点或区域）
  • 电源（为实现最佳电源利用率而放置工作负载，动态电源调整，电源上限）
  • 散热（管理数据中心温度）
  • SLA / QoS（将工作负载放置在最有可能交付承诺的性能和可用性的计算元素上）
• 行动
  • 基于服务器/区域信息和工作负载特征的新工作负载放置基于策略和约束
  • 工作负载迁移基于服务器/区域信息和策略约束。
  • 如果集群平衡是要求，工作负载可以在 ServerGroup 内迁移
  • 工作负载可以基于主机健康状况迁移
  • 工作负载可以被移动（或终止）基于由调度器或工作者触发的重新平衡事件
  • 支持“如果怎样”模式，以评估建议的策略/约束数据库更改的影响
  • 电源
    • 子调度器可以发送电源/散热警报
    • 调度器可以基于警报迁移工作负载
    • 调度器可以与电源控制模块通信，请求可用工作及其电源状态（开、节流、待机或关机）

调度器图表 attachment:pc_sched.png

元素

• 基于策略和约束 (P&C) 的调度器：这是调度器的核心元素，与 OpenStack 调度器接口。此块托管可插拔的 Resolver 和 DB 元素。
• P&C Resolver：这个可插拔的元素实现特定的 P&C 算法。此块将要评估的操作作为输入，使用现有的 P&C 数据库和现有数据来满足 P&C 评估的数据需求。输出是针对正在评估的操作的放置和配置的具体建议。
• P&C DB：这个可插拔的模块托管策略和约束的数据存储。目标是将模式和存储细节与解决方案的其余部分隔离。
• 主机数据库：有关主机硬件的信息，以允许针对特定硬件策略和警报结构
• 用于指定映射到实例需求的工作负载特征的工作负载特征类
• 数据收集：此模块从环境中收集数据（包括服务器、存储、网络、设施、工作负载等），这些数据是评估给定操作所必需的。
• 管理员：这些元素用于配置数据收集并根据需要调整策略和约束。

基本流程

• 要放置和配置的工作负载被呈现给基于 P&C 的调度器以及其需求（UE：元数据格式？？）。
• P&C 调度器验证请求并将请求交给 P&C resolver。
• 假设基础设施所有者之前已经填充了数据中心（散热、用户等）的 P&C 要求。
• 收集适用于此工作负载的 P&C。
• 收集预先评估并存储在数据库中的工作负载特征
• 收集通告的主机特征
• 收集评估此 P&C 所需的数据。
• 评估。记录评估结果。
• 生成建议。

实现

本节应描述实施所讨论更改的行动计划（“如何”）。可以包括诸如

UI 变更

应涵盖对 UI 的要求更改或实施此功能的特定 UI

代码变更

代码变更应包括需要更改的内容的概述，并且在某些情况下甚至包括具体细节。

迁移

包括

• 数据迁移（如果有）
• 从旧 URL 到新 URL 的重定向（如果有）
• 如何引导用户使用新的操作方式（如果需要）。

测试/演示计划

这不必在规范接近 Beta 之前添加或完成。

未解决的问题

这应该突出显示需要在进一步的规范中解决的任何问题，而不是规范本身的问题；因为任何存在问题的规范都无法获得批准。

BoF 议程和讨论

使用本节记录 BoF 期间的笔记；如果将其保留在批准的规范中，请用于总结讨论内容并记录任何被拒绝的选项。

---