使用 Searchlight 列出实例

https://blueprints.launchpad.net/nova/+spec/list-instances-using-searchlight

为了有效地跨多个 cell 列出实例，Nova 计划集成使用 Searchlight 的支持。 这将是一个可选功能，因为我们将证明这种方法的有效性。

问题描述

在大型部署中，跨多个 cell 列出实例将效率低下，因为计算 API 将不得不查询每个 cell 并应用过滤器，然后用 Python 合并排序结果。 使用像 ElasticSearch (ES) 集群这样的单个全局数据存储，并通过 Searchlight 作为前端将更有效。

用例

作为在 OpenStack 多 cell 环境中的用户，我需要能够快速查看所有我的实例。 我希望能够对它们进行过滤和排序，并在多个 cell 中创建新实例时具有可预测的排序顺序。

提议的变更

为 Nova 添加一个配置选项，该选项将切换计算 API 是否会迭代 cell 以列出实例并合并排序结果，或者查询 Searchlight 并将这些结果转换为适当的计算 API 响应。

这将是可配置的，并且默认情况下将被禁用，因为现有的部署可能未设置为发出版本化的通知或使用 Searchlight，因此最初将没有数据在响应中返回。

注意

当使用 Searchlight 来服务 GET /servers 或 GET /servers/detail 请求时，我们将从 Searchlight 获取所有必要的信息。 不会有任何额外的调用到 nova 数据库，否则这将违背此更改的目的。 我们不会使用 Searchlight 来处理 GET /servers/{server_id}，因为当我们有特定的 server ID 时，我们可以使用 Nova API 数据库中的 InstanceMapping 记录查找它所在的 cell。

错误条件

• 如果配置为使用 Searchlight 但它在服务目录中不可用，或者 Nova 无法访问它，我们将回退到默认路径，这意味着迭代 cell 以列出实例并合并排序结果。 在这种情况下会记录警告，但 API 请求不应该以 500 错误失败。 我们还将设置一个标志，以便在重新启动服务之前，我们不会继续检查，类似于我们在 Newton 中使用 nova.scheduler.client.report.SchedulerReportClient 中的 @safe_connect 装饰器处理 placement API 的方式。

已知问题

• 目前，管理员可以通过计算 REST API 列出已删除的实例。 这是因为当实例在 Nova 中“删除”时，它实际上并没有从数据库中删除。 它被认为是“软删除”，这意味着数据库中的 instances.deleted != 0。 这与 REST API 中的 SOFT_DELETED 状态相混淆，该状态基于 reclaim_instance_interval 配置选项。 有两种方法可以从 REST API 中删除（软）删除的实例

  1. 运行 nova-manage db archive_deleted_rows 命令，它会将（软）删除的实例移动到 shadow_instances 表。

  2. 直接从数据库中清除已删除的实例。 虽然 Nova 不直接支持此操作，但有公开可用的脚本供操作员用于清除数据库。

  这在使用 Searchlight 时会带来问题，因为目前 Searchlight 会在处理 compute.instance.delete.end 通知后删除实例的索引条目。 这有效地意味着，使用现有行为，如果您使用 Searchlight，将无法列出已删除的实例，因为它们将不会存储在 Searchlight 中。 这包括 changes-since 查询参数不再返回已删除的实例，而今天它确实返回。

  考虑到这一点，我们应该提到，今天无法保证可以根据给定云提供商的数据保留/归档/清除策略从计算 REST API 列出已删除的实例。 例如，如果云提供商的策略是在 30 天后归档或清除所有已删除的实例，那么他们已经无法列出超过 30 天前删除的实例。

  我们将不得不与 Searchlight 团队解决此限制。 例如，可能可以添加一个配置选项到 Searchlight 以控制在最终删除已删除实例的索引之前可以存储多长时间。 值得注意的是，ElasticSearch 曾经有一个 _ttl 字段的概念，但该字段在 5.0 中被移除。

  另一种选择是，如果指定了 deleted 或 changes-since 查询参数，我们不使用 Searchlight，而是跨 cell 迭代。 这将不是理想的，因为这意味着我们仍然必须维护两种列出实例的代码路径，但我们可能需要在几个版本中这样做，直到我们可以使 Searchlight 成为必需品，这使我们有时间找到与 Searchlight 更好的解决方案。

• 在更改计算 REST API 服务器响应时，开发人员还必须将这些更改镜像到版本化的通知 InstancePayload 中。 这也给 REST API 中的微版本和 InstancePayload 对象上的版本之间带来了一个问题。 REST API 中的微版本是客户端选择加入的，Nova 将继续尊重旧的微版本。 但是，版本化的通知以最新的可用版本推送出去。

  例如，假设我们在微版本 2.53 中从服务器响应中删除字段“foo”。 计算 API 仍然会在低于 2.53 的微版本请求中返回“foo”字段。 InstancePayload 对象无法删除“foo”字段而不进行主要版本升级，即使这样也会间接破坏计算 API 合同，如果我们正在使用 Searchlight，因为如果从 InstancePayload 对象中删除了“foo”字段，Searchlight 将不会返回带有“foo”字段的服务器响应。 这基本上意味着我们不能在版本化的通知中删除 InstancePayload 中的字段，除非我们还将计算 REST API 中的最小必需微版本提高到我们也在服务器响应中删除字段的程度。

数据迁移

未配置使用 Searchlight 的部署最初将没有必要的信息来开始使用此更改来服务计算 REST API 请求。

一旦部署了 Searchlight 并正在使用来自 Nova 的版本化的通知，新的实例操作将被索引。 但是，任何现有的实例数据都需要传输到 Searchlight。

因此，在配置 nova-api 使用 Searchlight 之前，部署者必须执行从 Nova 到 Searchlight 的现有实例的大量索引。 可以通过发出

searchlight-manage index sync --type OS::Nova::Server

这将告诉 Searchlight 调用计算 REST API 以列出现有实例并使用结果填充服务器索引。 有关更多详细信息，请参阅 Searchlight 文档中的 大量索引。

备选方案

无。

数据模型影响

无。

REST API 影响

虽然这将改变 GET /servers 和 GET /servers/detail 响应的生成方式，但应该不会对这些 API 的合同产生用户可见的更改。 这将通过 Tempest 测试来强制执行。

还应该注意的是，ElasticSearch 支持 分页，并且 Searchlight 在很大程度上与 ElasticSearch 兼容，因此它支持按页/大小分页。 您也可以通过使用 OpenStack “marker” 方法按 id 排序来完成它。

安全影响

这将需要部署一个 ElasticSearch 集群，并用项目 Searchlight 作为前端，这意味着服务目录中的另一个端点和潜在的服务用户。 ES 集群需要有适当的访问控制。 这也意味着启用通知，以便 Nova 版本化的通知可以馈送到 Searchlight ES 集群。

通知影响

无。 虽然此解决方案依赖于使用 Nova 中的版本化的通知，但我们没有为通知本身提出任何更改。

其他最终用户影响

无。 此更改应该对最终用户是透明的。

性能影响

此更改的目的是提高在多 cell 部署中列出实例的性能。 但是，实际性能将取决于 ElasticSearch 集群的性能如何。

其他部署者影响

• 配置 Nova 以发出版本化的通知。

• 设置 Searchlight，包括服务目录所需的任何服务用户和端点以及后端数据存储，例如 ElasticSearch。

• 现有的部署需要一定的时间才能将现有的实例数据馈送到 Searchlight，然后才能将计算 API 切换到使用它。 有关更多详细信息，请参阅上面的 数据迁移 部分。

开发人员影响

开发人员必须确保对计算 REST API 的任何更改需要返回响应中的新字段，这些新字段也存在于发送到 Searchlight 的版本化的通知中。

根据 Searchlight 如何实现对版本化的通知的支持，开发人员可能还需要更新索引映射以公开新字段。 但是，我们也许可以使用在 json-schema-for-versioned-notifications 蓝图 中完成的工作来自动化 Searchlight 中的操作。 如果我们不能或最终不使用 Searchlight 中的版本化的通知模式，那么这将创建一个安装/升级顺序依赖关系，即 Searchlight 必须在 nova-api 之前安装/升级。

让我们通过一个场景来了解在有人在计算 REST API 响应中添加新字段时会发生什么。 我们还需要将其放入版本化的通知有效负载中，以便 Searchlight 获得它。 关于模式的要点是，如果通知也发送模式，那么 Searchlight 可以动态地使用该模式，否则您必须静态地更新 Searchlight 以了解新字段。

以静态情况为例，如果有人在计算 API 的服务器响应中添加一个新字段，并且假设它不在实例表中（它是数据库中的新列），那么步骤是

1. 将字段添加到 nova DB 中的实例表。

2. 将字段添加到 Instance 对象。

3. 将字段添加到 InstancePayload 对象。

4. 将模式更改添加到 Searchlight 以获取新字段。

5. 通过微版本将新字段添加到计算 REST API 响应。

这意味着您必须先升级 Searchlight，然后才能升级 nova-api 以从 REST API 中获取新字段。

实现

负责人

主要负责人

Zhenyu (Kevin) Zheng (Kevin_Zheng)

其他贡献者

Matt Riedemann (mriedem)

工作项

• 获取一个正常工作的开发环境，Searchlight 在其中定期运行并使用 Nova 的通知。

• 将条件路径添加到计算 API get_all 流中，如果 Nova 配置为这样做，则查询 Searchlight 以获取数据。

• 可能需要在代码中添加某种转换实用程序代码，以将 Searchlight 响应转换为 nova.objects.InstanceList 对象，该对象将返回给 REST API 处理程序。

• 将 Searchlight 集成并配置 Nova 以在 gate-tempest-dsvm-neutron-nova-next-full-ubuntu-xenial-nv 作业中发出版本化的通知以进行测试。

• 安装指南更改，以解释在 Nova 中设置 Searchlight 的方法。

依赖项

• 为了与现有的计算 REST API 保持一致，此更改依赖于蓝图 additional-notification-fields-for-searchlight，以获取 Searchlight 所需的信息。

• 此更改还依赖于 Searchlight 添加对 Nova 版本化的通知的支持，该支持在 blueprint nova-versioned-notifications 中跟踪。

测试

• 计算 API 中更改的单元测试。

• 此更改的大部分测试工作是将 Searchlight 集成到 gate-tempest-dsvm-neutron-nova-next-full-ubuntu-xenial-nv 作业中，启用版本化的通知，然后按照此规范中描述的方式使用 Searchlight 列出实例。 该作业上的完整 Tempest 运行将显示我们是否与 API 响应具有一致性。

• 当我们设置了多 cell CI 作业时，我们可能也会对该作业进行相同的更改，以实现高效的实例列出操作。

文档影响

需要更新 计算管理员指南，以讨论如何启用此功能。 安装、操作和架构指南也可能需要更新。

参考资料

无。

历史

修订版

发布名称	描述
Pike	引入