Graffiti/Architecture

Graffiti 架构概念

从最基本的概念来说，Graffiti 的意图是实现跨服务和项目的更好的元数据协作，以便 OpenStack 用户可以利用增强的平台感知能力。

状态

Graffiti 项目是在亚特兰大（Juno）OpenStack 会议上提出的。它是一个虚拟项目，其所有概念已被采用并实现为多个不同的 OpenStack 项目的一部分。主要工作涉及 Glance、Searchlight 和 Horizon，还包括对 Nova 调度和过滤器的改进。

以下提供遗留概述信息，以帮助理解各个组件如何协同工作。有关更多信息，请参阅 https://wiki.openstack.org/wiki/Graffiti#Current_Status

工作流程和组件

加载您的自定义元数据定义（称为属性类型或能力类型）
1. 到 Graffiti 中央字典
2. 或者配置 Graffiti 插件以包含/代理各个服务提供的现有定义
使用您的属性和能力“标记”云中的资源
让用户使用您想要的属性和能力找到资源

在多个云安装中重复，以实现云能力的可移植性。

基本概念

各种 OpenStack 服务提供技术，可以将低级资源选择抽象到更高一级，例如风味、卷类型或制品类型。这些资源抽象通常允许使用键值对属性形式的“元数据”来进一步专门化和描述每种资源类型的实例。然而，协作这些属性在很大程度上是一个不连接且困难的过程。这通常涉及搜索 wiki 和打开源代码。随着云规模的增长，这变得更加困难。此外，很多时候这些属性可以应用于来自多个不同服务的资源。Graffiti 通过创建以下概念使这更容易
- 能力和需求：Graffiti 概念秉持了云资源可以使用能力的概念来描述，该概念受到今天 OpenStack 的某些部分以及 OASIS TOSCA 等行业规范的影响（请注意，Graffiti 不是编排引擎，它仅协助描述和定位云中的现有资源）。
- 字典：一个通用的 API，供服务、管理员和用户发现和共享他们的元数据词汇。这是创建关于如何描述云提供的各种能力达成共识的基础。它允许为描述和查找资源提供一致的 UI 和 CLI 体验。
- 资源目录：一个通用的 API，用于基于字典（元数据定义）“标记”和搜索现有和新服务中的云内容。
- 资源能力注册表：一个持久的共享存储库，供服务发布有关云资源的信息。这可以由服务选择性地使用，而不是或除了使用它们自己的本地原生存储来描述资源。

用例示例：计算能力

总结：Graffiti 概念提供跨服务和跨环境

元数据定义聚合和管理
资源元数据“标记”聚合
资源元数据搜索聚合

附加细节

以下概述了元数据聚合、资源搜索优化和本地资源注册表概念。

Graffiti API 优势

当我们第一次查看仅 UI 解决方案时，我们发现可以在一定程度上完成存在局限性。但是，如果我们提出将新服务集成或构建到生态系统中的想法，将提供以下额外优势

跨服务搜索的命令行和 REST API
导入/导出跨部署定义的可能性
多节点/HA 部署中定义的通用持久性数据库
私有标签/元数据库。用户/项目将能够拥有自己用于“标记”资源的词汇
创作 - 我们将提供一个创作和管理 UI，用于创建和管理命名空间、能力类型等
资源搜索性能优化。我们希望引入基于跨服务边界的高性能索引机制。

资源搜索优化

想法：

延迟加载。简单的预取机制。在发起会话或首次请求资源类型时进行调用，数据被拉入内存并保存有限的时间。后续搜索都在内存中完成。RBAC 通过令牌传递处理。
主动加载。基本思想是可以在 API 下添加缓存提供程序插件。可索引的资源（其服务所有者支持通知）将通过启动种子和资源事件通知的组合进行索引。例如，Glance 支持在某些镜像更改时发送通知。索引本身可以基于 Elasticsearch，插件将查询转换为 Elasticsearch 的查询和输出。（注意：此概念的大部分已由 Project Searchlight [1] 实现）。

最初提出的 Horizon 概念

这些已在 Horizon 中实现：

Horizon 功能
- 用于管理目录的管理员 UI
  - (管理员 —> 元数据定义) (Kilo)
- 用于将元数据关联到不同资源的窗口小部件
  - (下方每个行项目上的更新元数据操作)
  - 管理员 -> 镜像 (Juno)
  - 管理员 -> 风味 (Kilo)
  - 管理员 —> 主机聚合 (Kilo)
  - 项目 —> 镜像 (Liberty)
  - 项目 —> 实例 (Mitaka)
- 启动时添加元数据的能力
  - 项目 —> 启动实例 (ng 启动实例启用) (Mitaka)

遗留信息：

我们相信 Graffiti 概念可以通过可重用的窗口小部件在 Horizon 中实现，我们可以将这些窗口小部件插入 Horizon 以及对启动实例向导等屏幕的更改。这些窗口小部件将提供“标记”能力和 TBD：资源上的需求的能力。它们还将能够基于资源能力和属性生成过滤器查询。

术语说明

我们认为“元数据”是一个有点难以接近的术语，因此我们一直在探索“能力”的概念。能力可以简单地被认为是一个命名的“标签”，它可能包含或不包含属性。想法是用户可以简单地将能力“标记”到各种云资源，例如镜像、卷、主机聚合、风味等。对于最终用户来说，数据存储的确切机制对他们来说是隐藏的。某些资源类型可能不支持具有属性的能力/标签。

概念演示视频

为了探索和解释这些想法，HP 和 Intel 创建了演示 POC 代码下运行的概念的演示视频。样式仅代表录制演示时的某个时间点，并且已经发生了变化。

演示视频 - 概念概述

概念流程原型

建议的基本流程是，我们将能够在任何我们想要能够“标记”能力的资源管理屏幕上添加一个窗口小部件。例如，镜像、卷、风味和主机聚合屏幕都是不错的选择。目标是唯一需要的自定义是使用该窗口小部件的代码将有关正在标记的资源/资源类型的信息发送到 API。资源类型被发送到 API，然后 API 返回适用于该类型资源的适用能力。

启动实例示例

̈ - 注意：标记其他资源类型和搜索它们也可以类似地工作。

样式原型

我们一直在玩各种样式原型，但不确定什么有意义或可以接受。可以实现 Horizon 中的传统外观和感觉，但我们也不确定 Horizon 今天是否有处理树状浏览的良好示例。以下是我们创建的一些原型。

Graffiti 概念原型

建议的 Horizon 组件架构

我们希望在 Horizon 中有一种通用的方法来支持“标记”简单的命名标签和键值对，这些标签也支持整体 Graffiti 概念。在建议的架构中，我们将通过直接在 Horizon 中使用一个薄的 API 插件层来支持 Horizon 获得 Graffiti 概念的价值，而无需在部署环境中部署完整的“字典”和“资源目录”API。这将为 Horizon 提供现在的好处，而无需让新的 Graffiti 服务被孵化或被其他项目采用（我们正在积极寻求输入和建议）。这些窗口小部件将构建为使用外部服务 API 提供的通用简单的“资源语法”工作。

整个概念可以通过 Horizon 服务器上的一个轻量级文件系统提供程序以轻量级的方式运行，该文件系统允许直接从文件系统或已经提供模式或标签的服务读取字典定义文件。这足以用于单节点部署或通过配置管理提供程序管理以确保跨 Horizon 节点定义一致性的部署。

如果提供了完整的“字典”/“资源目录”服务 API，窗口小部件即使在添加新的资源类型和元数据定义到系统中时也无需更改。它们仍然转到 Horizon Graffiti 组件，该组件将添加插件以与适当的中央“字典”/“资源目录”服务端点通信，该端点将提供全部优势。

仅 Horizon 解决方案的局限性

如上所述并在下图中所示，窗口小部件和概念可以在 Horizon 中部分构建，而无需更改现有服务。但是，存在一些需要外部服务工作才能解决的限制。

Horizon 目前的设计是一个无状态服务器。唯一可以存在任何持久数据的地方是选择在服务器上数据库中存储会话信息。Horizon 的默认设置使用签名 cookie 来维护会话数据并避免数据库要求。
Horizon 服务器上没有特权帐户运行，因此无法构建仅管理员可以获取的持久数据存储。具有此特权会话的持久性会创建许多安全问题。
Horizon 可以设置为 HA 方式，这将需要多个 Horizon 服务器上的重复数据库或专用于 Horizon 数据库后端的另一个服务器。
最初讨论的范围只是冰山一角，当范围超出启动用例时，范围超出仅对 Horizon 有用的范围。隔离在 Horizon 中是有限制的。