词汇表

本页解释了 Watcher 系统中使用的不同术语。

它们按字母顺序排列。

动作

一个 动作 使得 Watcher 能够在 审计 之后转换 集群 的当前状态。

一个 动作 是一个原子任务，它会改变 OpenStack 集群 的目标 受管资源 的当前状态，例如

  • 使用 Nova 将实例从一个计算节点迁移到另一个计算节点

  • 使用 ACPI 等方式更改计算节点的电源级别

  • 使用 Nova 更改计算节点的当前状态（启用或禁用）

在大多数情况下，一个 动作 会触发 OpenStack 现有模块（Nova、Neutron、Cinder、Ironic 等）上的具体命令。

一个 动作 具有生命周期，其当前状态可能是以下之一

提供了一些默认实现，但也可以 开发新的实现，这些实现将在 Watcher 启动时动态加载。

动作计划

一个 动作计划 指定了为满足给定 目标 而应按顺序执行的 动作 流程。它还包含估计的 全局效能 以及一组 效能指标。

当 审计 成功时，Watcher 会生成一个 动作计划。这意味着用于该 审计 的 策略 已经找到一个 解决方案 来实现该 目标。

在 Watcher 的默认实现中，一个动作计划由一系列连续的 动作 (即，属于唯一分支的 动作 工作流) 组成。

但是，Watcher 为其许多组件提供了抽象接口，允许其他实现生成和处理更复杂的 动作计划，这些计划由两种类型的动作项组成

  • 简单的 动作：原子任务，这意味着它不能从 OpenStack 的角度拆分为更小的任务或命令。

  • 复合动作：由多个简单的 动作 按照顺序和/或并行流程组成。

一个 动作计划 可以使用标准的流程模型描述格式来描述，例如 业务流程模型和符号 2.0 (BPMN 2.0) 或 统一建模语言 (UML)。

要查看 动作计划 状态的生命周期和描述，请访问 动作计划状态机。

管理员

管理员 是对 OpenStack 集群具有管理员访问权限的任何用户。该用户允许为租户创建新项目，创建新用户并向每个用户分配角色。

管理员 通常可以远程访问集群的任何主机，以便更改配置并重新启动任何 OpenStack 服务，包括 Watcher。

在 Watcher 的上下文中，管理员 是允许他们运行任何 Watcher 命令的用户角色，例如

管理员 也允许修改任何 Watcher 配置文件并重新启动 Watcher 服务。

审计

在 Watcher 系统中，一个 审计 是优化 集群 的请求。

优化是为了满足给定 集群 上的一个 目标 而完成的。

对于每个 审计，Watcher 系统会生成一个 动作计划。

要查看 审计 状态的生命周期和描述，请访问 审计状态机。

审计范围

审计范围是一组被审计的资源。审计范围应在每个审计模板（包含审计设置）中定义。

审计模板

一个 审计 可以使用相同的设置（目标、阈值等）多次启动。因此，将这些设置保存在某种审计预设对象中是有意义的，该对象被称为 审计模板。

一个 审计模板 至少包含 目标。

它还可能包含一些错误处理设置，指示

以及在发生故障之前应尝试多少次重试（后者也可能很复杂：例如，最终在成功的 动作 上发生多次首次故障的情况）。

此外，一个 审计模板 可能包含与 动作计划 自动化程度相关的设置。一个标志将指示 动作计划 是否将自动启动，或者是否需要 管理员 手动确认。

可用区

请参阅 OpenStack 官方可用区定义。

集群

一个 集群 是一组物理机器，它们提供计算、存储和网络资源，并由相同的 OpenStack 控制节点管理。一个 集群 代表了云提供商能够为其 客户 提供的资源集合。

一个数据中心可能包含多个集群。

集群 可以划分为一个或多个 可用区。

集群数据模型 (CDM)

一个 集群数据模型 (或 CDM) 是 集群 受管资源 的当前状态和拓扑的逻辑表示。

它表示为一组 受管资源（可能是一个简单的树或一个键值对的平面列表），这使得 Watcher 策略 能够在 审计 期间了解不同 资源 之间的当前关系，并能够请求以下信息：

  • 哪些计算节点在一个给定的 审计范围 中？

  • 哪些 实例 托管在一个给定的计算节点上？

  • 计算节点的当前负载是多少？

  • 计算节点的当前可用内存是多少？

  • 两个计算节点之间的网络链路是什么？

  • 给定网络链路上的可用带宽是多少？

  • 给定 实例 的给定虚拟磁盘上的当前可用空间是多少？

  • 给定 实例 的当前状态是什么？

  • …

一言以蔽之，该数据模型使 策略 能够了解

在 Watcher 项目中，我们旨在为每个 目标 提供一些通用且基本的 集群数据模型，这些模型可用于相关的 策略，通过一种基于插件的机制，称为集群数据模型收集器（或 CDMC）。这些 CDMC 负责加载和保持与其关联的 CDM 的最新状态，通过监听事件以及定期从头开始重建它们。它们也直接可从策略类访问。这些 CDM 用于

  • 简化针对给定 策略 的新 策略 的开发，当已经存在一些与相同 目标 关联的现有 策略 时

  • 避免在几个与相同 目标 关联的 策略 中重复相同的代码

  • 提高给定 目标 的不同 策略 之间的一致性

  • 避免与任何外部 集群数据模型 产生强耦合（建议的数据模型充当枢纽数据模型）

在 Watcher 助手工具中，可能存在各种 通用和基本的集群数据模型，每种模型都针对实现给定的 目标 而进行调整

  • 例如，对于旨在优化网络 资源 的 目标，策略 可能需要知道哪些 资源 正在相互通信。

  • 而对于旨在优化热量和功率条件的 目标，策略 可能需要知道每个计算节点在机架中的位置以及每个机架在机房中的位置。

但是，请注意，如果建议的数据模型不符合开发人员的需求，只要 策略 能够为请求的 目标 产生 解决方案，开发人员可以使用他/她自己的 集群数据模型。例如，开发人员可以依赖 Nova 数据模型来优化一些计算资源。

集群数据模型 可以持久化在任何合适的存储系统中（SQL 数据库、NoSQL 数据库、JSON 文件、XML 文件、内存数据库等）。目前，正在后台构建和维护一个内存模型，以加速策略的执行。

控制器节点

请阅读 OpenStack 官方对控制器节点的定义。

在许多配置中，Watcher 将驻留在控制器节点上，即使它可以潜在地托管在专用机器上。

计算节点

请阅读 OpenStack 官方对计算节点的定义。

客户

客户 是订阅云提供商服务的个人或公司。客户可能在同一个 集群 上托管多个 项目，或者分散在不同的集群上。

在私有云环境中，客户 是同一组织内的不同组（不同的部门、项目团队、分支机构等）。云基础设施包括精确跟踪每个客户的服务使用情况的能力，以便将其返还给他们，或者至少向他们报告。

目标

目标 是人类可读、可观察和可衡量的最终结果，具有一个要实现的目标。

以下是一些 目标 的示例

  • 最小化能源消耗

  • 最小化计算节点的数量（整合）

  • 平衡计算节点之间的工作负载

  • 最小化许可成本（某些软件的许可模式基于部署软件的插槽或核心数量）

  • 找到在给定主机组（可能是整个可用区）上进行计划维护的最适当时间：电源更换、冷却系统更换、硬件修改等。

主机聚合

请阅读 OpenStack 官方对主机聚合的定义。

实例

一个正在运行的虚拟机，或者处于已知状态的虚拟机，例如挂起，可以像硬件服务器一样使用。

受管理资源

受管理资源 是 受管理资源类型 在具有特定属性和依赖于其他 受管理资源（关系）的拓扑中的一个实例。

例如，受管理资源 可以是一个托管在 计算节点 上的虚拟机（即 实例），并通过网络链路（也表示为 集群数据模型 中的 受管理资源）连接到另一个虚拟机。

受管理资源类型

受管理资源类型 是 集群 的硬件或软件元素，Watcher 系统可以对其进行操作。

以下是一些 受管理资源类型 的示例

它可以是 OpenStack HEAT 中定义的可用资源类型的官方列表 中的任何一种。

效能指标

效能指标是单个值，用于指示给定 策略 产生的 解决方案 的表现如何。这些效能指标特定于给定的 目标，通常用于计算结果 行动计划 的 全局效能。

在 Watcher 中，这些效能指标与它们相关的目标一起指定。当执行与目标相关的策略时，它会产生一个包含目标指定的效能指标的解决方案。该解决方案，已被 Watcher 规划器 转换为行动计划，其指标和全局效能将被存储，并且现在可以通过 Watcher API 访问。

效能规范

效能规范是与每个 目标 关联的合同，定义了实现相关目标时策略应在其 解决方案 中提供的各种 效能指标。 确实，由策略提出的每个解决方案在计算其 全局效能 之前，都会根据此合同进行验证。

优化效能

优化效能 是根据约束和 SLA 衡量实现 目标 的程度的客观度量，这些约束和 SLA 由 客户 定义。

效能的评估方式取决于要实现的目标。

当然，只要 行动计划 仍然相关（即 集群 的当前状态没有发生变化，以至于需要启动新的 审计），效能才有效。

例如，如果 目标 是降低能源消耗，则 效能 将使用几个 效能指标（KPI）计算

  • 能源节约百分比（必须尽可能高）

  • SLA 违规 数量（必须尽可能低）

  • 虚拟机迁移数量（必须尽可能低）

所有这些指标都在给定的时间范围内计算，该时间范围是执行整个 行动计划 所花费的时间。

效能还使 管理员 可以客观地比较针对相同目标和相同 集群 工作负载的不同 策略。

项目

项目 代表 OpenStack 中的“所有权”的基本单位，即 OpenStack 中的所有 资源 都应由特定的 项目 拥有。在 OpenStack Identity 中，项目 必须由特定的域拥有。

请阅读 OpenStack 官方对项目的定义。

评分引擎

评分引擎 是一个可执行文件，具有明确的输入、明确的输出，并执行纯粹的数学任务。也就是说，计算不依赖于其运行的环境 - 它会在任何地方产生相同的结果。

由于构建特定数据模型（因此是评分引擎）可能使用多种算法，因此评分引擎的使用方式可能会有所不同。元信息字段应包含给定评分引擎的用户可能需要的任何信息。

SLA

SLA 代表服务级别协议。

资源在合同中由 客户 和云提供商协商确定。

大多数时候，该合同由两份文件组成

  • SLA：服务级别协议

  • SLO：服务级别目标

请注意，SLA 比 SLO 更通用，因为前者规定了要提供的服务、支持方式、时间、地点、成本、性能和相关各方的责任，而 SLO 侧重于更可衡量的特征，例如可用性、吞吐量、频率、响应时间或质量。

您还可以阅读 维基百科关于 SLA 的页面，它提供了很好的定义。

SLA 违规

当与给定 客户 签订的 SLA 无法在官方合同文件中规定的时间范围内由云提供商遵守时，就会发生 SLA 违规。

SLO

服务级别目标 (SLO) 是服务提供商和 客户 之间 SLA 的关键要素。SLO 约定为衡量服务提供商的性能的一种方式，并概述为避免双方因误解而发生争议的一种方式。

您还可以阅读 维基百科关于 SLO 的页面，它提供了很好的定义。

解决方案

解决方案 是 策略（即算法）执行的结果。每个解决方案由许多信息组成

一个 解决方案 与一个 行动计划 不同，因为它包含由一个 策略 产生的非计划性 行动 列表。换句话说，解决方案 中的行动列表尚未被 观察者规划器 重新排序。

请注意，某些算法（即 策略）可能会生成多个 解决方案。这引发了确定应该应用哪个 解决方案 的问题。

可以设想两种处理方法

策略

一个 策略 是一种算法实现，能够为给定的 目标 找到一个 解决方案。

可能有多个潜在的策略能够实现相同的 目标。这就是为什么可以配置为每个目标应该使用哪个特定的 策略。

某些策略可能提供更好的优化结果，但可能需要更多时间才能找到最佳的 解决方案。

观察者应用器

该组件负责执行由 观察者决策引擎 构建的 行动计划。

有关此组件的更多详细信息，请参阅：系统架构。

观察者数据库

此数据库存储所有观察者领域对象，这些对象可以由观察者 API 或观察者 CLI 请求

  • 审计模板

  • 审计

  • 行动计划

  • 行动

  • 目标

这里的观察者领域是“优化 OpenStack 系统提供的某些资源”。

有关此组件的更多详细信息，请参阅 系统架构。

观察者决策引擎

该组件负责计算一组潜在的优化 行动，以实现 审计 的 目标。

它首先从相关的 审计模板 中读取 审计 的参数，并了解要实现的目标。

然后，它根据 Watcher 为此 目标 的配置方式选择最合适的 策略。

然后执行 策略，并生成一组 行动，这些行动由 观察者规划器 随时间安排（即，它生成一个 行动计划）。

有关此组件的更多详细信息，请参阅 系统架构。

观察者规划器

观察者规划器 是 观察者决策引擎 的一部分。

此模块接收由 策略 生成的 行动 集合，并构建工作流的设计，定义如何随时间安排这些不同的 行动，以及每个 行动 的先决条件是什么。

为了防止在应用 行动计划 时 集群 过载，必须随时间安排 行动。例如，重要的是不要同时迁移太多实例，以免网络拥塞降低 SLA，影响 客户。

为了避免安全问题，例如对核心 OpenStack 服务的拒绝服务攻击，也必须随时间安排 行动。

提供了一些默认实现，但可以 开发新的实现，这些实现将在启动时由 Watcher 动态加载。

有关此组件的更多详细信息，请参阅 系统架构。