Uber 介绍了他们如何在区域故障期间确保其 OpenSearch 部署持续运行。其实现方式是利用 OpenSearch 内置的分片分配机制以及基于 Odin 容器编排平台的自有隔离组系统。通过这种方式，该公司既能在故障期间保持查询能力，又能维持数据摄取能力。这种设计可以容忍整个区域故障外加一个节点故障，同时保持法定节点数并避免数据丢失。
Uber 希望解决一个问题：物理区域中的节点数量经常不均衡。这一问题扰乱了 OpenSearch 的分配感知逻辑，通常导致集群处于黄色状态且存在未分配的分片。当区域容量不均衡时，将分片放置映射到物理区域会导致磁盘偏斜和热点节点。出现这种情况的原因在于，OpenSearch 的重新平衡机制期望每个感知属性都拥有数量均等的节点池。
Uber 的解决方案是引入隔离组（IG），作为物理故障域与 OpenSearch 放置逻辑之间的逻辑层。每个 IG 都保证拥有相等的节点数量，无论其下有多少个物理区域，而且，节点在硬件更换之后仍然会保留其 IG 成员身份。Uber 的大多数服务（包括 OpenSearch）运行着 3 个 IG，因此，单个区域恰好映射到一个 IG，而且区域故障最多只会导致约三分之一的容量丢失。每个索引至少运行 2 个副本（共计 3 个分片副本），每个 IG 各占一个，这样便提供了应对单个组丢失的基础级容错能力。
更棘手的问题在于故障发生期间会发生什么。在默认情况下，OpenSearch 会在发现分片副本缺失时利用剩余的节点快速重新平衡。这可能会导致磁盘 I/O、CPU 和网络过载，从而危及正常运行区域的稳定性。Uber 通过强制分片分配感知机制解决了这一问题。集群在初始化时便配置了所有预期的 IG 属性值，而不仅仅是当前可见的那些。当某个 IG 缺失时，OpenSearch 会检测到这一问题。它不会为其他组过度地分配资源，因此受影响的分片将保持未分配状态。这会导致集群状态变为黄色，而非触发大规模的重新平衡风暴。只有当故障 IG 的节点恢复正常，或者运维人员显式更新感知配置后，分片才会被重新分配。
分片分配感知
Uber 使用 5 个集群管理节点作为法定节点数，而非通常的 3 个。这与 OpenSearch 的 cluster.auto_shrink_voting_configuration 设置相兼容。当某个区域发生故障时，最多可能导致 2 个管理节点失效，剩余 3 个；此时，投票配置会自动缩减至这 3 个节点，并以 3 选 2 的法定节点数选举出新的主节点。随后若再发生单节点故障，仍然会剩余 2 个节点，足以维持法定节点数并保持集群的可写状态，而标准的 3 管理节点配置则无法应对这种情况。
Uber 报告称，IG 抽象层修复了黄色状态和分片分配失败的问题。这些问题源于物理区域大小不均。如今，分片分配率达到了 100%，集群健康状态始终为绿色。该方案还解决了与分区不对称相关的磁盘偏斜和热点节点效应。这种方法适用于 Uber 所有 Tier 3 及以上级别的 OpenSearch 和 Elasticsearch 集群。它基于 OpenSearch 的分片分配感知和投票配置缩减等功能构建，不需要自定义搜索引擎或分支版本。
运行多区域 OpenSearch 或 Elasticsearch 集群的工程师不需要使用 Uber 专有的 Odin 工具，即可采用“强制感知”模式。其关键要求包括：节点在一组明确声明的固定感知属性值上均匀分布；至少有 3 个分片副本可以一对一映射到故障域；实现了奇数个集群管理节点（5 个而非 3 个）投票且可以自动缩减。该设计可以应对“区域故障加节点故障”的连续故障场景。
Uber 的方法反映了行业内广泛存在的一种趋势，侧重于将故障域感知能力嵌入数据层，而非仅依赖基础设施层面的故障转移。Uber 在 Apache Pinot 中采用了类似的隔离组模型，将隔离组 ID 映射到副本组池。这种架构可以确保当某个区域完全故障时，分段副本仍然能正常运行。
原文链接：https://www.infoq.com/news/2026/07/uber-opensearch-zone-failure/
