单元格中检查配额的资源计数

https://blueprints.launchpad.net/nova/+spec/cells-count-resources-to-check-quota-in-api

对于 cellsv2，配额表正在迁移到 API 数据库，作为部署的全局数据。目前，对于实例删除，配额预留是在 API 中进行的，然后在计算节点提交。这是一种分离，将计算单元格与 API 单元格耦合在一起。在 cellsv2 中，我们努力尽可能地将计算单元格与 API 单元格解耦——理想情况下，单元格不应需要在其配置中具有 API 数据库连接。

我们提出了一种新的方法，即在 API 中计算已消耗的资源并将其与配额限制进行检查，而不是当前使用的预留/提交模型，该模型会创建一个预留记录，创建配额使用记录并标记为“in_use”（正在使用）在提交时，然后删除预留记录。

问题描述

当前的配额设计包括预留和提交/回滚。以下是创建期间其工作原理的简化说明：“预留”创建预留记录和使用记录，指示资源“已预留”。“提交”更新使用记录以修改“已预留”字段、“正在使用”字段，并删除预留记录。“回滚”更新使用记录以修改“已预留”字段并删除预留记录。

对于实例删除，资源首先在收到请求时在 API 中预留，然后在计算节点释放资源时稍后提交预留。在 cellsv2 中，这意味着如果保留当前的配额模型，计算单元格将写入 API 数据库以提交配额。如果我们改为在 API 中计算资源以检查配额，那么将来[*]将有可能完全将计算单元格与 API 单元格解耦。

用例

  • 操作员希望将他们的部署划分为单元格，以实现扩展、故障域和构建原因。在划分后，应尽量减少 API 单元格和计算单元格之间的耦合。

提议的变更

将计算消耗的资源以检查配额，而不是当前使用的预留/提交/回滚模型。

  • “预留”、“提交”和“回滚”调用将在所有地方移除。配额检查将改为从 API 数据库读取配额限制，并将其与资源计数进行比较。

  • “预留”调用将被替换为类似“check_resource_count”（检查资源计数）的内容，该内容将查询数据库以获取已消耗的资源，对其进行计数，并在项目无法容纳请求的配额限制时引发 OverQuota 错误。

备选方案

这项工作的最初提议是在 API 中尽可能立即提交配额，这是对此方法的一种替代方案。在 API 中立即提交配额的缺点是，对于失败的调整大小场景，无法完全避免。如果调整大小失败，则必须相应地更新资源消耗在 quota_usages 记录中，而使用资源计数方法，则不需要进行此类更新。

数据模型影响

我们可以删除 API 数据库中的预留和 quota_usages 表，因为它们将不再使用。

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

使用资源计数方法，如果项目在接近其配额限制时争用，则项目可能会消耗比其配额更多的资源。这是因为我们必须在单独的数据库中的实例中汇总已消耗的资源。因此，有可能 API 处的配额检查 Y 通过，而稍后争用的请求 X 也通过配额检查，消耗了项目允许的剩余资源，然后请求 Y 在之后消耗了超过配额限制的资源。

性能影响

在计数核心和内存等资源的情况下，性能将受到不利影响。这是因为目前分配记录中没有存储项目关联。在没有通过放置 API 的有效方法来计算核心和内存的情况下，需要以下方法

  • 按单元格获取所有项目实例，解析 flavor JSON blob 并加总计数。例如

    instance_get_all_by_filters(filters={'project_id': myproj},
                            expected_attrs=['flavor'])

计划与放置 API 子团队合作，以获得通过项目进行资源分配的有效调用，以提高性能。

所有其他资源都应该能够一步到位计数

  • 实例 (ReservableResource)：可以从 API DB 中的 instance_mappings 表中获得。我们也许能够从上述核心/内存查询中创建一个总计，并用它来代替对 instance_mappings 进行新的查询。

  • 安全组 (ReservableResource)：在 2.36 中已弃用，并且在 Nova 中与 Neutron 不进行检查。这在 API 中使用 nova-network 进行检查。安全组位于单元格数据库中，因此这将是从 API 到单元格 DB 的读取以进行检查。

  • 浮动 IP (ReservableResource)：在 2.36 中已弃用，并且在 Nova 中与 Neutron 不进行检查。这在 auto_assign_floating_ip 使用 nova-network 分配浮动 IP 时进行检查。浮动 IP 位于单元格数据库中，因此这将是本地 DB 读取，直到 nova-network 被移除。

  • 固定 IP (ReservableResource)：在 Nova 中与 Neutron 不进行检查。这在 nova-compute 分配/释放固定 IP 时使用 nova-network 进行检查。固定 IP 位于单元格数据库中，因此这将是本地 DB 读取，直到 nova-network 被移除。

  • 元数据项 (AbsoluteResource)：这是允许的图像元数据项数量的限制，并在图像元数据请求传入时进行检查。无需在数据库中计数资源。

  • 注入的文件 (AbsoluteResource)：类似于元数据项。

  • 注入的文件内容字节 (AbsoluteResource)：类似于元数据项。

  • 注入的文件路径字节 (AbsoluteResource)：类似于元数据项。

  • 安全组规则 (CountableResource)：类似于安全组。

  • 密钥对 (CountableResource)：可以从 API DB 中的 key_pairs 表中获得。

  • 服务器组 (ReservableResource)：可以从 API DB 中的 instance_groups 表中获得。

  • 服务器组成员 (CountableResource)：可以从 API DB 中的 instance_group_member 表中获得。

以下是资源类型的说明，摘自 ML 帖子 [1]

  • ReservableResource：可与预留一起使用，资源存储在 DB 中。

  • AbsoluteResource：资源数量未存储在 DB 中。

  • CountableResource：AbsoluteResource 的子类，但资源存储在 DB 中。具有计数函数，将调用该函数以确定资源的当前计数。不打算按项目 ID 计数。

使用新方法，似乎 ReservableResources 应该更改为 CountableResources，并为每个资源提供计数函数。

其他部署者影响

可以弃用“nova-manage project quota_usage_refresh”命令，因为刷新配额将不再是我们要做的事情。

开发人员影响

Nova 开发人员将不再调用配额“预留”、“提交”或“回滚”。相反，他们将在添加消耗配额的新 API 时调用配额“check_resource_count”（检查资源计数）或类似内容。

实现

负责人

主要负责人

melwitt

其他贡献者

无

工作项

  • 在 nova/objects/quota.py 中添加一个名为 check_resource_count 的方法，该方法计算已消耗的资源并在请求超出配额限制时引发 OverQuota 错误。

  • 在所有地方移除预留/提交/回滚。

  • 在文档字符串中将“预留”、“提交”和“回滚”方法标记为 DEPRECATED（已弃用），以防止进一步使用。

依赖项

无

测试

将添加新的单元测试来涵盖新的资源计数场景。

对于大多数情况，这项工作应该对最终用户是透明的，因此现有的单元、功能和集成测试套件应该足以测试所提出的内容。

有一个关于“配额不同步”错误的回归测试的未决审查，可以用作副作用来验证此提议解决了该问题。

文档影响

无

参考资料

历史

修订版

发布名称

描述

Ocata

引入