大型集群的弹性
编辑大型集群的弹性编辑
节点共享公共基础设施（例如网络互连或电源）的情况并不罕见。如果是这样，您应该计划此基础设施的故障，并确保此类故障不会影响太多节点。通常的做法是将共享某些基础设施的所有节点分组到区域中，并计划一次性发生任何整个区域的故障。
Elasticsearch 期望节点到节点的连接可靠、延迟低且带宽充足。许多 Elasticsearch 任务需要节点之间进行多次往返。缓慢或不可靠的互连可能会对集群的性能和稳定性产生重大影响。
例如，每次往返增加几毫秒的延迟会很快累积成明显的性能损失。不可靠的网络可能会出现频繁的网络分区。Elasticsearch 会尽快自动从网络分区中恢复，但您的集群在分区期间可能部分不可用，并且需要花费时间和资源来重新同步任何丢失的数据并在分区恢复后重新平衡自身。从故障中恢复可能涉及在节点之间复制大量数据，因此恢复时间通常取决于可用带宽。
如果您已将集群划分为区域，则每个区域内的网络连接通常比区域之间的连接质量更高。确保区域之间的网络连接质量足够高。将所有区域都放置在单个数据中心内，每个区域都有自己的独立电源和其他支持基础设施，您将获得最佳效果。您也可以将集群扩展到附近的数据中心，只要每个数据中心对之间的网络互连足够好。
运行健康的 Elasticsearch 集群没有特定的最低网络性能要求。理论上，即使节点之间的往返延迟为数百毫秒，集群也能正常工作。实际上，如果您的网络速度如此慢，那么集群性能将非常差。此外，缓慢的网络通常不可靠，足以导致导致不可用期的网络分区。
如果您希望数据在相距较远或连接不佳的多个数据中心中可用，请在每个数据中心部署一个单独的集群，并使用跨集群搜索或跨集群复制将集群链接在一起。这些功能旨在即使集群到集群的连接不如每个集群内的网络可靠或性能好，也能正常运行。
在丢失了整个区域的节点后，设计良好的集群可能仍然可以运行，但容量会大大降低。您可能需要配置额外的节点才能在处理此类故障时恢复集群的正常性能。
为了抵御整个区域的故障，重要的是每个分片在多个区域中都有一个副本，这可以通过将数据节点放置在多个区域中并配置分片分配感知来实现。您还应确保客户端请求发送到多个区域的节点。
您应该考虑所有节点角色，并确保每个角色在两个或多个区域中冗余拆分。例如，如果您使用摄取管道或机器学习，您应该在两个或多个区域中拥有摄取或机器学习节点。但是，主节点的放置需要更加小心，因为弹性集群需要至少两个中的三个主节点才能正常运行。以下部分探讨了跨多个区域放置主节点的选项。
双区域集群编辑
如果您有两个区域，您应该在每个区域中拥有不同数量的主节点，以便节点数量较多的区域包含大多数主节点，并且能够在另一个区域丢失的情况下存活。例如，如果您有三个主节点，那么您可以将它们全部放在一个区域中，或者您可以将两个放在一个区域中，将第三个放在另一个区域中。您不应该在每个区域中放置相同数量的主节点。如果您在每个区域中放置相同数量的主节点，那么这两个区域都没有自己的多数。因此，集群可能无法在任何一个区域丢失的情况下存活。
带仲裁节点的双区域集群编辑
上面描述的双区域部署可以容忍其中一个区域的丢失，但不能容忍另一个区域的丢失，因为主节点选举是基于多数的。您无法配置双区域集群，使其能够容忍任何一个区域的丢失，因为这在理论上是不可能的。您可能期望，如果任何一个区域发生故障，Elasticsearch 可以从剩余区域中选举一个节点作为主节点，但无法区分远程区域的故障和区域之间连接的丢失。如果两个区域都能够进行独立的选举，那么连接丢失会导致脑裂问题，因此会导致数据丢失。Elasticsearch 避免了这种情况，并通过不从任何区域中选举节点作为主节点来保护您的数据，直到该节点可以确定它拥有最新的集群状态，并且集群中没有其他主节点。这可能意味着在连接恢复之前根本没有主节点。
您可以通过在两个区域中的每一个区域中放置一个主节点，并在独立的第三个区域中添加一个额外的主节点来解决此问题。额外的主节点充当仲裁节点，用于在两个原始区域彼此断开连接的情况下。额外的仲裁节点应该是一个专用的仅投票主节点，也称为专用仲裁节点。专用仲裁节点不需要像其他两个节点那样强大，因为它没有其他角色，不会执行任何搜索，也不会协调任何客户端请求，也不会被选举为集群的主节点。
您应该使用分片分配感知来确保每个区域中都有每个分片的副本。这意味着如果另一个区域发生故障，任何一个区域都将保持完全可用。
所有主节点，包括仅投票节点，都在发布集群状态更新的关键路径上。集群状态更新通常独立于性能关键型工作负载（例如索引或搜索），但它们涉及管理活动，例如索引创建和滚动、映射更新以及故障后的恢复。这些活动的性能特征是每个主节点上存储速度以及集群中所有节点之间网络互连的可靠性和延迟的函数。因此，您必须确保集群中节点可用的存储和网络足够好，以满足您的性能目标。