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

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 中立即提交配额的缺点是，对于失败的调整大小场景，无法完全避免。如果调整大小失败，则必须相应地更新配额_usages 记录中的资源消耗，而使用资源计数方法，则不需要进行此类更新。

数据模型影响

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

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

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

性能影响

在计算核心和内存的资源时，性能将受到不利影响。这是因为目前 placement 中没有项目/用户关联的分配信息。在没有通过 placement API 的有效方法来计算核心和内存的情况下，需要以下方法

  • 按单元获取所有实例，并加总 vcpus 和 memory_mb 计数。例如

    instance_get_all_by_filters(filters={'deleted': False,
                                     'project_id': myproj})

这种方法也有一个缺点，即当单元宕机时，无法计算实例、核心和内存。这意味着当单元宕机时，实例、核心和内存的使用情况不包含宕机单元中的资源，从而有可能在可用单元中分配新资源，并在宕机单元恢复时超出配额。在实践中，在多单元成为可能之前，这在单单元情况下不应该成为问题。

计划是在 placement 中添加项目/用户关联的分配信息，并添加基于项目/用户查询分配信息的功能。当可用查询时，单元中核心和内存的计数将替换为对 placement 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 分配浮动 IP 时与 nova-network 检查。浮动 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

引入

Pike

重新提出