跨区域搜索¶
SearchLight 目前的目标是与 nova、glance、cinder 等一起作为 Openstack 控制平面的部署。一直以来都有很多兴趣让 SearchLight 索引和搜索 Openstack 区域之间的资源。
问题描述¶
典型的生产 Openstack 部署可以通过 扩展 和弹性提供多种方式，其中一些适用于所有服务，而另一些则特定于支持该功能的服务。
可用区 提供了一种在多台机器上分配资源（虚拟机、网络）的能力，这些机器可能位于独立的机架中，并具有独立的电源。可用区在资源数据中表示，并且已经是 SearchLight 进行索引的一部分。
区域 可以在地理位置上提供隔离（例如不同的数据中心）。在单个 Openstack 部署中运行多个区域的唯一要求是配置 Keystone 以在区域之间共享数据（例如使用主-主数据库复制）。所有其他服务彼此隔离，但 Keystone 能够提供每个区域中 nova-api 部署的 URL。Keystone 令牌通常不限定于特定区域；Horizon 当前将区域更改视为一项繁重的工作，因为它意味着刷新应在所选区域中可见的仪表板和面板。
多云 提供完全隔离，使得每个云完全独立，互不了解。Horizon 也支持这种模式（令人困惑的是，也将每个云称为“区域”），但更改“区域”需要登录到新区域。
Nova 单元 是 Nova 特有的功能，允许在单个区域内进行水平扩展。单元 以一种对用户来说基本透明的方式，将计算 API 扩展到多个数据库和消息队列。由于单元侧重于性能而非弹性，因此与此功能（尽管可能是另一个功能的基础）没有直接关系，因此本文档不考虑单元。
对于使用多个区域的部署，能够搜索聚合数据可以提供价值。虚构的 Region-A 中的 Nova 部署不知道虚构的 Region-B 中的资源，因此用户必须向每个区域发出请求才能获取信息。这使得 Horizon 有些笨拙（更改区域会触发重新加载页面以更改上下文，尽管身份验证状态会保留）。
这些是多区域云的潜在部署选项。以下选项按工作量和复杂性递增的顺序呈现。相对性能已注明。
像 Keystone 一样部署 Searchlight。API 端点可以存在于两个区域中。数据将在区域之间复制（通过某种外部过程 - Elasticsearch 明确不支持或不建议将集群拆分到地理位置上）；SearchLight 索引将写入其本地集群，查询将针对本地集群运行。所有区域感知资源都将附加一个区域 ID。最佳性能，最困难的维护，零客户端复杂性。
SearchLight 将在每个位置运行，但数据不会在位置之间复制（类似于 nova 和 glance 的工作方式）。为了允许跨区域搜索，Elasticsearch 配置了一个 tribe 节点，充当联合搜索节点；索引操作始终在本地执行。对 tribe 节点上的别名进行的搜索将充当对连接到 tribe 节点的集群中该别名的搜索。最差性能（与最慢的节点一样糟糕，但单个区域搜索可以优化），更易于维护，零客户端复杂性。
在两个区域中分别运行 Searchlight；要么让客户端显式地向两个区域发出查询，要么让 Searchlight 的 API 将请求回显到其他区域。这可能会强制按区域隔离结果（这可能是一个好的结果）。可变性能（可以根据可用性接收结果），最容易维护，复杂性推送到客户端。
应该注意的是，选项 1 和 2 提供了相似的功能体验；搜索将显示针对单个 API 端点运行，并返回多个区域中的数据（适当的排序和分页）。选项 3 将每个区域视为单独的区域；分页和排序将应用于每个区域的结果。即使在那个层面上，也需要做出决定，实际需要什么；UI 是否应该按区域隔离结果，或者合并视图更可取？
提议的变更¶
在奥斯汀的 Newton 会议上讨论后（在会议上提出了下面的替代方案），一致认为统一视图可能非常有用，但需要充分了解安全影响并进行更多测试。考虑到 Newton 的工作量，普遍的看法是可以通过客户端充分支持此功能。
因此，我们将记录使用 tribe 节点运行 Searchlight 的方法以及它带来的网络影响。我们还将向所有映射中添加 region_name。
这可能会在后续版本中扩展。
备选方案¶
为了启用使用 tribe 节点来支持多个区域的搜索
设置带有 Searchlight 的标准 devstack
部署配置为 多区域 的第二个 devstack（我在第二个本地 VM 上设置了它）
确保
searchlight.conf包含正确的region-name在身份验证凭据部分确保 Elasticsearch 集群名称不同（
cluster.name: region-one）检查
searchlight-manage是否可以在每个区域中正确索引在第一个 devstack VM 上的不同端口上设置一个 tribe 节点（同样使用不同的集群名称）。我使用了手动主机发现
配置一个从 tribe 节点运行的单独的 searchlight-api。对别名的搜索将返回两个集群的结果
这种技术将遇到导致我们禁用 多索引支持 的相同问题；如果索引映射不同，将导致错误。解决方案（正如我怀疑的那样）是确保即使没有将数据索引到给定的索引，索引之间的映射也是相同的。
除了设置 Elasticsearch 之外，这里需要的工作是让 searchlight-api 使用 tribe 节点（可能在每个区域中），而不是侦听器使用的集群（或者根据搜索上下文，两者都使用）。此更改相对较小。我们还需要让所有资源都感知区域（这是一种明智的更改），并确保 Searchlight 本身意识到自己的区域（这也是一种明智的更改）。
参考资料¶
Openstack 扩展 https://docs.openstack.org/openstack-ops/content/scaling.html
Elasticsearch ‘tribe’ 节点：https://elastic.ac.cn/guide/en/elasticsearch/reference/current/modules-tribe.html
