在 Glance 中实现统一的 Keystone 配额

https://blueprints.launchpad.net/glance/+spec/glance-unified-quotas

目前 Glance 缺乏按租户的配额功能,而其他 OpenStack 项目早已具备此功能。特别是由于 Glance 是一个可运行云的关键项目,并且涉及消耗昂贵的资源,因此配额对于运营商正确限制使用量是必要的。正如最近的 PTG 中提到的,公有云会为每种资源收费,因此按租户的限制可能不太重要。然而,私有云通常不会对使用情况计费,而是依赖于预付配额来共享资源。这项工作旨在为 Glance 实现配额。

问题描述

Glance 没有按租户的配额。

  • 作为私有云的运营商,我需要能够为租户定义配额,以避免他们消耗无限的资源,因为我不对他们使用的每个资源收费。

  • 作为云的运营商,我拥有不同规模的客户,并希望使用按租户的配额来为失控的使用提供“安全阀”限制。仅有一个适用于所有用户的全局值不足以为不同规模的租户提供合理的限制。

提议的变更

Keystone 已经实现了一种称为“统一限制”的功能,允许运营商在 Keystone 中定义默认和按租户的配额限制。默认情况下,“扁平”模型提供了一个非常基本的单租户单限制结构,但更复杂的层次结构也是可能的。可以使用 Keystone 的客户端 (openstackclient) 实用程序来注册、设置和更新每个租户的限制。

通过利用此 Keystone 功能,Glance 无需定义新的 API 和客户端支持来允许运营商设置限制,也不需要构建持久性模型来存储它们、清理它们等。相反,Glance 可以从 Keystone 查询限制值,并将其与当前/建议的使用量进行比较,以确定是否应允许特定的资源消耗。实际上,Glance 只需要执行配额,而不需要存储或管理它们。限制由 oslo_limit 库自动且按请求从 Keystone 获取,因此配额更改会立即生效。

使用此模型添加新的配额限制相对容易。虽然将来可以添加更多限制,但此规范涵盖了添加以下限制所需的工作

  • image_size_total:租户所有未删除镜像消耗的存储限制。具有多个位置的镜像将计算多次使用量。以兆字节 (MiB) 为单位。将在镜像上传路径以及导入路径中执行此限制,这些路径是用户实际消耗更多存储的 API。

  • image_stage_total:租户所有处于 uploadingimporting 以及任何其他瞬态导入相关状态的镜像消耗的存储限制。为了捕获复制镜像所用的空间,我们还将包括具有非零 os_glance_importing_to_stores 项目列表的活动镜像。以兆字节 (MiB) 为单位。将在镜像暂存路径中执行此限制。

  • image_count_total:租户拥有的所有未删除镜像的总数限制。以镜像数量为单位。将在镜像创建路径中执行此限制。

  • image_count_uploading:租户当前处于 uploadingsavingimporting 以及任何其他与上传或导入相关的瞬态状态中的镜像总数限制。为了捕获正在复制的镜像,我们将包括具有非零 os_glance_importing_to_stores 项目列表的活动镜像。以镜像数量为单位。将在镜像上传和暂存路径中执行此限制,并为可以在任何给定时间将外部数据添加到系统中的镜像数量提供限制。

由于 Glance API 工作程序的暂存区域可能比通用镜像存储更受限制,因此这些配额是分开的。运营商可能希望为用户提供大量的镜像存储空间,该存储空间由复杂且分布式的后端支持。然而,暂存区域实际上是“临时空间”,用于镜像导入过程,并且可能受到更严格的限制(API 工作器上的本地磁盘)。通过允许暂存区域的单独配额,运营商可以提供许多 TiB 的通用镜像存储空间,同时限制用户一次执行的导入操作数量。这有助于避免用户暂存大量镜像数据,然后将其长时间留在那里。如果不需要暂存配额,则在 Keystone 中将其设置为 -1 会向 oslo_limit 信号表明它应该是“无限制的”。通过允许单独的计数和大小暂存配额,运营商可以限制镜像数据的数量,或者限制正在进行的操作的数量。

对于与存储相关的限制,此版本的初始修订将仅在相关的长期存储使用操作开始时执行配额。这样做的好处是简单且可预测,但会使配额执行“软”,即用户必须超过限制后才会停止。现有的全局限制在用户提前提供大小时作为“硬”阈值执行,并且如果超出限制,可以中断长期网络操作。好处是友好的用户不允许超过他们的限制,尽管未提供大小的用户(例如在流式传输镜像时)仍然需要在操作完成后检查限制。当前行为的缺点是,如果用户在 900GiB 时超过 1TiB 限制,他们将浪费时间和网络带宽,然后整个流将被丢弃。由于全局限制旨在阻止大规模过度使用并且对于任何租户来说都足够大,因此它们不太可能被正常命中。此处描述的按租户限制更有可能被定期命中,因此选择了软行为。在传输期间或之后以硬限制执行它们可以在后续工作中完成。

遵守这些限制将基于配置选项。默认情况下,配额限制将被禁用,这将最容易地促进升级。禁用时,与今天的情况没有区别。启用后,Glance 将从 Keystone 获取限制,并期望运营商已按照规定注册它们,并对其使用情况执行限制。我认为最终让默认情况下启用它可能更有意义,并最终完全删除该旋钮。显然,如果更可取,我们可以无限期地保留该旋钮。

备选方案

另一种选择是完全不做任何事情。Glance 这么长时间以来都没有配额,所以我们可以不添加它们,而是依赖于今天的全局资源限制。

另一种选择是在 Glance 本身实现配额,而不利用 Keystone 统一限制功能。这将需要新的 API、客户端支持和数据库模型。它还将违背更广泛的社区努力,即在 Keystone 中定义所有配额限制。

我们还可以决定软配额不够好,并采取以下路径之一来获取硬配额

  • 开始要求 API 客户端在上传时声明镜像大小,以便我们可以准确地从一开始就进行配额检查。

  • 重构 oslo-limit 以暴露限制的详细信息,并在重构的 Image.set_data() 包装器中使用它,以便在超出限制时在传输过程中停止数据传输。

这些都是构建在此规范中提出的工作之上的未来工作的候选者。

数据模型影响

如果这样做,则无需存储任何额外值。我们已经存储了镜像大小,这是我们在存储相关限制的执行时需要计算的内容。由于 Keystone 存储实际的按租户配额限制值,因此我们不需要存储它们。

REST API 影响

这将引入更多获得 HTTP 413 限制错误的方式,但由于现有限制已经有可能获得这些错误,因此实际上没有变化。

未来的工作应该添加一个配额使用 API,以便客户端可以检查其限制的消耗情况。

安全影响

这将提高系统的整体安全性,因为资源限制可以根据每个租户进行定制,而不是仅依赖于对所有人来说都足够大的全局限制。

通知影响

无。

其他最终用户影响

不需要客户端更改。实际用户可能会注意到行为变化,这与运营商能够对其强制执行比以前更小的配额有关(这是这项工作的目标)。

性能影响

查询 Keystone 的限制对于租户来说并非免费的,并且会引入一些依赖性和延迟。但是,这种交互(特别是与 Keystone 的交互)无论如何都在所有 API 使用的关键路径中。至少最初,将提供一个配置选项以启用此行为,默认情况下禁用。

其他部署者影响

运营商需要在启用执行之前在 Keystone 中定义 Glance 值的已注册和实际限制。这是通过使用 openstack 客户端在 keystone 中使用默认值注册它们来完成的。然后可以使用类似机制设置单个用户的配额。所有这些都可以在 Glance 侧启用执行之前和之后完成。

从 Wallaby 或更早版本升级的运营商无需在升级过程中执行任何特定操作,因为默认情况下执行已关闭。如果运营商希望在升级后使用配额,他们可以在任何时候注册配额并在配置中启用 Glance 执行。

开发人员影响

无。

实现

负责人

主要负责人

danms

工作项

  • 引入从 Keystone 查询和检查限制的基础设施。

  • image_size_total 配额执行添加到上传和导入。

  • image_stage_total 配额执行添加到暂存。

  • image_count_total 配额执行添加到创建。

  • image_count_uploading 配额执行添加到暂存和上传。

  • 弄清楚如何处理显示为零大小的 ceph 快照。

  • 添加 tempest 支持限制和测试这些配额。

  • 实施在 devstack 中配置这些配额并在作业中集成测试。

  • 添加操作员文档以解释如何启用、配置和使用这些配额。

依赖项

  • 这将需要我们将 oslo_limit 添加为依赖项。

  • 这将需要 devstack 支持进行测试

  • Tempest 测试将是必需的,因为 Keystone 和 Glance 之间的交互对于确保正确性至关重要。

测试

单元和功能测试将在树中直接进行。Tempest 测试将通过为租户设置一个小的限制,然后上传几个镜像来确保我们跨越每个限制来提供。

文档影响

由于 Glance 中还没有按租户的配额,因此需要更新文档以添加覆盖范围。运营商需要知道在 Keystone 中配置哪些限制,如何配置,以及如何在 Glance 中启用执行。运营商还需要了解基于大小的配额的软限制性质,以及 Glance 愿意接受无限制上传如何影响配额执行。

参考资料