基础设施故障对 Amazon OpenSearch Service 中分片的影响

亚马逊开放搜索服务 是一种托管服务，可以轻松地在 AWS 云中大规模保护、部署和操作 OpenSearch 和旧版 Elasticsearch 集群。 Amazon OpenSearch Service 为您的集群预置所有资源、启动它并自动检测和替换故障节点，从而减少自我管理基础设施的开销。 该服务通过提供最新版本的 OpenSearch、支持 19 个版本的 Elasticsearch（1.5 到 7.10 版本）以及由OpenSearch Dashboards 和 Kibana（1.5 到 7.10 版本）。

在最新的服务软件版本中，我们已将分片分配逻辑更新为负载感知，以便在任何节点发生故障时重新分配分片时，该服务不允许幸存节点因先前托管在故障节点上的分片而过载。 这对于多可用区域提供一致且可预测的集群性能尤为重要。

如果您想了解有关分片分配逻辑的更多背景知识，请参阅 揭秘 Elasticsearch 分片分配.

挑战

Amazon OpenSearch Service 域在节点数量均匀分布在配置的可用区中，并且分片总数均匀分布在所有可用节点上，没有任何一个索引的分片集中在任何一个上时，被称为“平衡”域节点。 此外，OpenSearch 有一个名为“区域感知”的属性，启用后可确保主分片及其对应的副本分配在不同的可用区中。 如果您拥有多个数据副本，则拥有多个可用区可提供更好的容错性和可用性。 如果域向外扩展或向内扩展或在节点出现故障期间，OpenSearch 会自动在可用节点之间重新分配分片，同时遵守基于区域感知的分配规则。

虽然分片平衡过程确保分片在可用区之间均匀分布，但在某些情况下，如果单个区域出现意外故障，分片将重新分配给幸存的节点。 这可能会导致幸存的节点不堪重负，从而影响集群的稳定性。

例如，如果三节点集群中的一个节点出现故障，OpenSearch 会重新分配未分配的分片，如下图所示。 这里“P”代表主分片副本，而“R”代表副本分片副本。

域的这种行为可以分为两部分来解释——故障期间和恢复期间。

失败期间

跨多个可用区部署的域在其生命周期中可能会遇到多种类型的故障。

完全区域故障

由于各种原因，集群可能会丢失单个可用区以及该可用区中的所有节点。 今天，该服务尝试将丢失的节点放置在剩余的健康可用区中。 该服务还尝试在剩余节点中重新创建丢失的分片，同时仍遵循分配规则。 这可能会导致一些意想不到的后果。

• 当受影响区域的分片重新分配到健康区域时，它们会触发分片恢复，这会增加延迟，因为它会消耗额外的 CPU 周期和网络带宽。
• 对于 n-AZ、n-copy 设置，(n>1)，剩余的 n-1 个可用区分配有第 n 个分片副本，这可能是不可取的，因为它会导致分片分布偏斜，这也可能导致跨节点的不平衡流量。 这些节点可能会过载，从而导致进一步的故障。

部分防区故障

如果出现部分区域故障或域仅丢失可用区中的部分节点，Amazon OpenSearch Service 会尝试尽快替换故障节点。 但是，如果更换节点的时间太长，OpenSearch 会尝试将该区域未分配的分片分配到可用区中的幸存节点。 如果该服务无法替换受影响的可用区中的节点，它可能会将它们分配到其他已配置的可用区中，这可能会进一步扭曲分片在区域内和区域内的分布。 这又会产生意想不到的后果。

• 如果域上的节点没有足够的存储空间来容纳额外的分片，则域可能会被写阻塞，从而影响索引操作。
• 由于分片的倾斜分布，域也可能在节点间经历倾斜的流量，这会进一步增加读取和写入操作的延迟或超时。

修复工具

今天，为了维持所需的域节点数，Amazon OpenSearch Service 在剩余的健康可用区中启动数据节点，类似于上面故障部分中描述的场景。 为了确保在此类事件发生后在所有可用区之间正确分配节点，需要 AWS 进行人工干预。

发生了什么变化

为了改进整体故障处理并最大限度地减少故障对域运行状况和性能的影响，Amazon OpenSearch Service 正在执行以下更改：

• 强制区意识：OpenSearch 有一个预先存在的分片平衡配置，称为强制感知，用于设置需要分配分片的可用区。 例如，如果您有一个名为区域的感知属性并在中配置节点 zone1 和 zone2，您可以使用强制感知来防止 OpenSearch 在只有一个区域可用时分配副本：

cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2

使用此示例配置，如果您启动两个节点 node.attr.zone 设置 zone1 并创建一个包含五个分片和一个副本的索引，OpenSearch 创建索引并分配五个主分片但没有副本。 副本仅分配一次节点 node.attr.zone 设置 zone2 是可用的。

Amazon OpenSearch Service 将在 Multi-AZ 域上使用强制感知配置，以确保仅根据区域感知规则分配分片。 这将防止运行状况良好的可用区节点上的负载突然增加。

• 负载感知分片分配：Amazon OpenSearch Service 将考虑配置容量、实际容量和总分片副本等因素，以根据每个节点的预期平均分片数计算是否有任何节点因更多分片而过载。 当任何节点分配的分片计数超出此限制时，它将阻止分片分配。

备注 任何未分配的 小学 仍然允许在过载节点上进行复制，以防止集群发生任何即将发生的数据丢失。

同样，为了解决手动恢复问题（如上文恢复部分所述），Amazon OpenSearch Service 也对其内部扩展组件进行了更改。 有了更新的更改，Amazon OpenSearch Service 将不会在剩余的可用区中启动节点，即使它经历了前面描述的故障场景也是如此。

可视化当前和新行为

例如，Amazon OpenSearch Service 域配置有 3 个可用区、6 个数据节点、12 个主分片和 24 个副本分片。 该域跨 AZ-1、AZ-2 和 AZ-3 进行配置，每个区域中有两个节点。

当前分片分配：
分片总数：12 个主 + 24 个副本 = 36 个分片
可用区数：3
每个区域的碎片数（区域感知为真）：36/3 = 12
每个可用区的节点数：2
每个节点的分片数：12/2 = 6

下图提供了域设置的可视化表示。 圆圈表示分配给节点的分片数。 Amazon OpenSearch Service 将为每个节点分配六个分片。

在部分区域故障期间，当 AZ-3 中的一个节点发生故障时，故障节点将分配给剩余的区域，并且该区域中的分片将根据可用节点重新分配。 经过上述改动后，集群不会在节点故障后创建新节点或重新分配分片。

在上图中，随着 AZ-3 中的一个节点丢失，Amazon OpenSearch Service 将尝试在同一区域中启动替换容量。 但是，由于某些中断，该区域可能会受损并且无法启动替换。 在这种情况下，该服务会尝试在另一个健康区域中启动不足容量，这可能会导致可用区之间的区域不平衡。 受影响区域上的分片被填充到同一区域中的幸存节点上。 但是，对于新行为，该服务将尝试尝试在同一区域启动容量，但会避免在其他区域启动容量不足的容量以避免不平衡。 分片分配器还将确保幸存的节点不会过载。

同样，如果 AZ-3 中的所有节点都丢失，或者 AZ-3 受损，Amazon OpenSearch Service 会在剩余的可用区中调出丢失的节点，并在节点上重新分配分片。 但是，在新的更改之后，Amazon OpenSearch Service 既不会将节点分配到剩余区域，也不会尝试将丢失的分片重新分配到剩余区域。 Amazon OpenSearch Service 将等待恢复发生，并等待域在恢复后返回到原始配置。

如果您的域没有配备足够的容量来承受可用区丢失，您的域的吞吐量可能会下降。 因此，强烈建议在调整域大小时遵循最佳实践，这意味着要预置足够的资源来承受单个可用区故障造成的损失。

目前，一旦域恢复，该服务就需要手动干预来平衡可用区之间的容量，这也涉及到分片移动。 然而，有了新的行为，在恢复过程中不需要干预，因为受影响区域的容量返回，分片也自动分配给恢复的节点。 这确保了剩余资源上没有竞争优先级。

你可以期待什么

在您将 Amazon OpenSearch Service 域更新到最新的服务软件版本后，已更新的域 配置了最佳实践 即使在可用区中丢失一个或多个数据节点后，也将具有更可预测的性能。 节点中分片过度分配的情况将会减少。 提供足够的容量以容忍单个区域故障是一种很好的做法

在此类意外故障期间，您有时可能会看到域变黄，因为我们不会将副本分片分配给过载的节点。 但是，这并不意味着在配置良好的域中会丢失数据。 我们仍将确保在中断期间分配所有初选。 有一个自动恢复，它将负责平衡域中的节点并确保在故障恢复后分配副本。

更新您的 Amazon OpenSearch Service 域的服务软件，以将这些新更改应用于您的域。 有关服务软件更新过程的更多详细信息，请参见 Amazon OpenSearch 服务文档.

结论

在这篇文章中，我们了解了 Amazon OpenSearch Service 最近如何改进逻辑以在区域中断期间跨可用区分布节点和分片。

此更改将帮助服务确保在节点或区域故障期间更一致和可预测的性能。 在处理写入和读取期间，域不会看到任何增加的延迟或写入块，这些延迟过去有时会由于节点上分片的过度分配而更早出现。

关于作者

布赫塔瓦汗 是 Amazon OpenSearch Service 的高级软件工程师。 他对分布式和自治系统很感兴趣。 他是 OpenSearch 的积极贡献者。

安舒阿加瓦尔 是 Amazon Web Services 的 AWS OpenSearch 高级软件工程师。 她热衷于解决与构建可扩展且高度可靠的系统相关的问题。

舒利亚·杜塔·比斯瓦斯 是一名软件工程师，在 Amazon Web Services 从事 AWS OpenSearch 方面的工作。 他热衷于构建高度弹性的分布式系统。

里沙布纳哈塔 是一名软件工程师，在 Amazon Web Services 从事 OpenSearch 方面的工作。 他着迷于解决分布式系统中的问题。 他是 OpenSearch 的积极贡献者。

兰吉思·拉马钱德拉 是在 Amazon Web Services 从事 Amazon OpenSearch 服务的工程经理。

乔恩汉德勒 是高级首席解决方案架构师，专攻 AWS 搜索技术——Amazon CloudSearch 和 Amazon OpenSearch Service。 他常驻帕洛阿尔托，帮助众多客户正确部署搜索和日志分析工作负载并使其正常运行。

• SEO 支持的内容和 PR 分发。 今天得到放大。
• 柏拉图区块链。 Web3 元宇宙智能。 知识放大。 访问这里。
• Sumber: https://aws.amazon.com/blogs/big-data/impact-of-infrastructure-failures-on-shard-in-amazon-opensearch-service/