为周期性维护添加 nova-audit 服务

https://blueprints.launchpad.net/nova/+spec/nova-audit

Nova 是一个分布式系统，这意味着事情会以奇怪的方式失败，并且跨多个系统存储的数据会与实际状态不同步。主机和实例来来去去，以及网络连接、消息总线和数据库。最近，我们获得了一些“修复 $事物”例程，操作员可以周期性地或按需运行这些例程，以同步各种服务和数据存储的状态，以解决或防止问题。这些任务的数量对于普通操作员来说已经不堪重负，并且每个周期跟踪新任务是不现实的 [1]。

问题描述

如上所述，我们有越来越多的维护任务需要在各种场景中运行。在大多数情况下，这些任务是幂等的，即使在一切正常的情况下也可以安全运行。操作员需要一个单一的机制来执行这些维护任务和修复活动，这些任务可以在后台周期性地运行，对运行时性能的影响最小，除了希望在不一致性问题变得严重到需要人工干预之前修复它们。

用例

作为操作员，我希望 Nova 尽可能地自我修复，以最大限度地减少需要人工干预的支持事件数量。

作为用户，我希望 Nova 尽可能地自我修复，以避免因瞬态问题而需要联系支持，这在非高峰时段可能不可能或代价高昂。

提议的变更

我们已经将这些维护活动中的许多编码为一次性命令 [2]，可以在识别问题后按需运行。由于它们中的大多数无害或代价不高，因此我们应该能够周期性地运行这些命令，以尝试自动修复问题，然后再让操作员介入。

本规范提出一个新的二进制文件，名为 nova-audit，用于封装这些任务。理想情况下，它应该以多种方式使用

  • 作为单例守护进程，根据其对系统和需求的潜在影响，以不同的间隔周期性地运行任务。

  • 作为可以从 cron 或其他方式计划或执行的一次性“修复”命令。

  • 作为纯粹审计潜在问题的守护进程或一次性命令，但不进行任何更改。

将添加一个新的配置部分 [audit]，其中包含每个任务的计时器和默认值。

我们当前可以集成的修复/同步/修复/清理任务

heal_allocations

此任务检查 Nova 中实例的 Placement 中分配的一致性。它对 Placement 和 Nova 数据库的运行时性能有影响。许多实例意味着它可能应该每个周期检查一个实例，但周期时间可能很短。

sync_aggregates

此任务检查 Nova 和 Placement 之间的主机聚合是否匹配。它对于某些调度器活动是必需的，但并非所有情况都如此。它对 Placement 和 Nova 数据库的运行时性能有影响。许多主机意味着它可能应该每个周期检查一个聚合。聚合通常变化不频繁，因此较长的周期时间（一小时或更长）可能合理。

map_instances

此任务检查实例是否具有合适的映射到单元。它对 Nova 数据库的运行时性能有影响。许多实例意味着它可能应该每个周期检查一个实例，但周期时间相对较短。或者，最好一次检查一个单元，频率非常低，例如每天一次。

discover_hosts

此任务确保新注册的超visor 主机映射到适当的单元。它对 Nova 数据库有运行时影响，但有一种有效的方法可以查询未映射的主机，因此可以相对频繁地运行，例如每十分钟。

注意

已经有一种机制可以在调度器服务中周期性地运行此命令，应该弃用并替换为 nova-audit。

archive_deleted_rows

此任务将主数据库表中的已删除数据存档到影子表中。它对 Nova 数据库的运行时性能有影响，既有负面影响（在运行时），也有正面影响（在运行后）。有些人从不运行此命令，因此每天或每周一次的周期时间应该足够了。这还需要一个参数来限制存档更改的范围到日期范围，默认情况下为周期时间的倍数。

注意

这（以及其他）可能需要一个配置元素来控制其执行仅在某些小时或天数之间。

purge

此任务完全从影子表中删除数据。它对 Nova 数据库的运行时性能有影响，但它只是从仅在 archive_deleted_rows 操作期间访问的表中删除数据。实际上，这可能应该在存档过程后直接运行，可能具有不同的年龄范围。

heal_instance_mappings (提议)

此任务扫描 API 数据库中孤立的实例映射，这些映射在单元中没有构建请求或匹配的实例。它对 Nova API 和单元数据库的运行时性能有影响，但仅查找没有单元 ID 的映射。它受飞行中实例构建数量加上孤儿数量的限制，这应该很小。因此，可以相对频繁地运行此命令，例如每十分钟。

备选方案

我们可以什么都不做。人们今天正在管理复杂性，因此我们可以选择让他们继续。

我们可以消除该提案的守护进程和调度性质，并仅提供一个统一的接口来运行这些命令——一个单独的地方来查找所有周期性维护任务，与 nova-manage 执行的设置类型的事情分开。

我们可以将其集成到 nova-manage 本身中，在“maintenance”子命令或类似命令下。

数据模型影响

无。

REST API 影响

无。

安全影响

无。

通知影响

没有。您可以认为发送关于审核活动的通知会很有用，但这样做需要对该实用程序进行更多的设置和配置，以及对消息总线和凭据的连接。如果需要，我们可以在以后实现它。

其他最终用户影响

无。

性能影响

由于审核的后台性质和任何清理操作，将会有一些运行时性能影响。缓解措施是不运行它，调整间隔时间更长，或在需要时以一次性模式运行它。

其他部署者影响

部署者将不得不学习和部署新的命令/服务。希望这能完全抵消长期内管理和维护 Nova 的复杂性降低。

开发人员影响

添加的新维护任务需要以幂等和高效的方式完成，并根据为这些命令定义的接口进行操作。

升级影响

将添加一个新的二进制文件，这将对升级产生一些影响。任何现有的周期性维护作业，这些作业调用 nova-manage 执行各种任务，都需要转换为新的命令。我们对 nova-manage 中现有的事情拥有的接口可以被弃用，但可以维护很长一段时间，以避免破坏现有的部署。

注意

像 db archive_deleted_rows 这样的特定任务可能仍然存在于 nova-manage 中。

实现

负责人

主要负责人

danms

功能联络人

功能联络人

danms

工作项

  • 创建一个新的 nova-audit 命令并定义调度机制和内部接口。

  • 创建新的配置部分和项目。

  • 实现连接器以将我们现有的任务集成到新的命令中。

  • 修改 nova-next 作业，以便在 tempest 运行后以一次性模式运行审核命令，理想情况下删除现有的存档/清除调用。

依赖项

无。

测试

守护进程和内部架构的单元和功能测试，以及对实际任务进行持续测试的需求。像我们今天为存档/清除所做的那样，在 nova-next 作业中以一次性运行。

文档影响

操作员文档，关于新命令、如何部署它以及关于影响和建议间隔的每个旋钮的文档。

参考资料

历史

修订版

发布名称

描述

Ussuri

引入