设计弹性
edit设计为弹性
edit像Elasticsearch这样的分布式系统被设计成即使某些组件发生故障也能继续工作。只要存在足够多的良好连接的节点来接管它们的责任，即使某些节点不可用或断开连接，Elasticsearch集群也可以继续正常运行。
弹性集群的最小规模是有限制的。所有 Elasticsearch 集群都需要以下组件才能正常运行：
一个弹性的集群需要为每个必需的集群组件提供冗余。 这意味着一个弹性的集群必须具备以下组件：
- 至少三个主节点
- 每种角色至少两个节点
- 每个分片至少两个副本（一个主分片和一个或多个副本，除非索引是可搜索快照索引）
一个弹性的集群需要三个主节点候选节点，这样如果其中一个节点失败，剩下的两个仍然可以形成多数并能够成功选举。
同样，每个角色的节点冗余意味着如果某个特定角色的节点发生故障，另一个节点可以接管其职责。
最后，一个弹性的集群应该至少有两个每个分片的副本。如果一个副本失败，那么应该有另一个好的副本接管。Elasticsearch会自动在剩余的节点上重建任何失败的分片副本，以便在故障后恢复集群的完全健康状态。
故障会暂时降低集群的总容量。此外，故障后集群必须执行额外的后台活动以恢复健康状态。您应确保即使某些节点发生故障，集群也能处理您的负载。
根据您的需求和预算，Elasticsearch 集群可以由单个节点、数百个节点或介于两者之间的任何数量组成。在设计较小的集群时，您通常应专注于使其能够抵御单节点故障。大型集群的设计者还必须考虑多个节点同时发生故障的情况。以下页面提供了一些关于构建各种规模的高弹性集群的建议：
小型集群中的弹性
edit在较小的集群中，最重要的是要能够抵御单节点故障。本节提供了一些指导，帮助您尽可能提高集群对单个节点故障的抵御能力。
单节点集群
edit如果您的集群由一个节点组成，那么这个单一节点必须完成所有工作。 为了适应这种情况，Elasticsearch 默认会为节点分配所有角色。
单节点集群不具备弹性。如果节点发生故障，集群将停止工作。由于单节点集群中没有副本，因此无法冗余存储数据。然而，默认情况下，至少需要一个副本才能使绿色集群健康状态。为了确保您的集群能够报告绿色状态，请通过将index.number_of_replicas设置为0来覆盖默认设置，对于每个索引都是如此。
如果节点失败，您可能需要从快照中恢复任何丢失索引的较旧副本。
由于它们对任何故障都不具备弹性，我们不建议在生产环境中使用单节点集群。
双节点集群
edit如果你有两个节点，我们建议它们都作为数据节点。你还应该通过在每个索引上设置index.number_of_replicas为1，确保每个分片在两个节点上都有冗余存储，除非该索引是可搜索快照索引。这是默认行为，但可能会被索引模板覆盖。自动扩展副本也可以实现相同的效果，但在如此小的集群中没有必要使用此功能。
我们建议您将两个节点中的一个设置为主节点。这意味着您可以确定哪个节点是集群的当选主节点。集群可以容忍另一个非主节点丢失。如果您将两个节点都设置为主节点，则需要两个节点进行主节点选举。由于如果任何一个节点不可用，选举将失败，因此您的集群无法可靠地容忍任何一个节点的丢失。
默认情况下，每个节点都被分配了所有角色。我们建议您将所有其他角色（除主节点资格外）分配给两个节点。如果一个节点发生故障，另一个节点可以处理其任务。
您应避免将客户端请求仅发送到您的某个节点。如果这样做，并且该节点发生故障，即使剩余节点本身是一个健康的集群，这些请求也将无法收到响应。理想情况下，您应将客户端请求均衡地分配到两个节点。一种好的做法是在配置客户端以连接到您的集群时，指定两个节点的地址。或者，您可以使用一个弹性负载均衡器来平衡客户端请求在集群节点之间的分配。
因为它对故障的恢复能力不强，我们不建议在生产环境中部署双节点集群。
带有仲裁器的双节点集群
edit由于主节点选举是基于多数原则的，上述的双节点集群可以容忍其中一个节点的丢失，但不能容忍另一个节点的丢失。你无法配置一个双节点集群，使其能够容忍任何一个节点的丢失，因为这在理论上是不可能的。你可能会期望，如果任何一个节点失败，Elasticsearch可以将剩余的节点选为主节点，但实际上无法区分远程节点的故障和节点间连接的丢失。如果两个节点都能够独立进行选举，连接丢失将导致脑裂问题，从而导致数据丢失。Elasticsearch通过避免这种情况并保护你的数据，确保在节点能够确定其拥有最新的集群状态并且集群中没有其他主节点之前，不会选举任何节点为主节点。这可能导致集群在连接恢复之前没有主节点。
您可以通过添加第三个节点并使所有三个节点成为主节点来解决这个问题。一个主选举只需要三个主节点中的两个。这意味着集群可以容忍任何单个节点的丢失。这个第三个节点在两个原始节点彼此断开连接的情况下充当决胜局。您可以通过将其设为专用仅投票主节点，也称为专用决胜局，来减少这个额外节点的资源需求。因为它没有其他角色，专用决胜局不需要像其他两个节点那样强大。它不会执行任何搜索，也不会协调任何客户端请求，并且不能被选为集群的主节点。
两个原始节点不应仅作为投票的主节点，因为一个弹性集群至少需要三个主节点，其中至少两个不是仅投票的主节点。如果你的三个节点中有两个是仅投票的主节点，那么被选中的主节点必须是第三个节点。这个节点随后成为单点故障。
我们建议为所有非决胜节点分配其他角色。这样可以确保集群中的任何任务都可以由任一节点处理，从而创建冗余。
您不应将任何客户端请求发送到专用仲裁节点。 您还应避免仅向其他两个节点中的一个发送客户端请求。如果您这样做，并且该节点发生故障，那么即使剩余节点形成一个健康的集群，任何请求也不会收到响应。理想情况下，您应在非仲裁节点之间平衡您的客户端请求。您可以通过在配置客户端以连接到集群时指定两个节点的地址来实现这一点。或者，您可以使用弹性负载均衡器在集群中的适当节点之间平衡客户端请求。Elastic Cloud 服务提供了这样的负载均衡器。
一个包含额外仲裁节点的双节点集群是最小的可用于生产部署的集群。
三节点集群
edit如果你有三个节点，我们建议它们都成为数据节点，并且 每个不是可搜索快照索引的索引 应该至少有一个副本。节点默认是数据节点。你可能 更希望某些索引有两个副本，以便每个节点都有这些索引中每个分片的一个副本。你还应该配置每个节点为 有资格成为主节点，以便其中任意两个节点可以在不需要与第三个节点通信的情况下进行主节点选举。节点默认是有资格成为主节点的。这个集群将能够容忍任何单个节点的丢失。
您应避免将客户端请求仅发送到您的某个节点。如果这样做，并且该节点发生故障，那么即使剩余的两个节点形成了一个健康的集群，任何请求也将无法收到响应。理想情况下，您应将客户端请求均衡地分配到所有三个节点。您可以通过在配置客户端以连接到您的集群时指定多个节点的地址来实现这一点。或者，您可以使用一个弹性负载均衡器来在您的集群中均衡客户端请求。Elastic Cloud服务提供了这样的负载均衡器。
具有三个以上节点的集群
edit一旦您的集群扩展到超过三个节点，您可以根据其职责开始专门化这些节点，从而根据需要独立扩展其资源。您可以根据需要拥有任意数量的数据节点、摄取节点、机器学习节点等，以支持您的工作负载。随着集群规模的扩大，我们建议为每个角色使用专用节点。这使您能够独立扩展每个任务的资源。
然而，将集群中符合主节点资格的节点数量限制为三个是一个好的做法。主节点不像其他节点类型那样可以扩展，因为集群总是只选举其中一个作为集群的主节点。如果符合主节点资格的节点太多，那么主节点选举可能需要更长的时间才能完成。在较大的集群中，我们建议您将一些节点配置为专用的符合主节点资格的节点，并避免向这些专用节点发送任何客户端请求。如果符合主节点资格的节点被不必要的额外工作所淹没，而这些工作本可以由其他节点处理，那么您的集群可能会变得不稳定。
您可以将其中一个符合主节点资格的节点配置为仅投票节点，这样它就永远不会被选为主节点。例如，您可能有两个专用主节点和一个既是数据节点又是仅投票主节点资格的节点。这个仅投票节点将在主节点选举中充当平局决胜的角色，但永远不会成为主节点本身。
总结
edit只要满足以下条件，集群将对任何节点的丢失具有弹性：
-
集群健康状态是
绿色。 - 至少有两个数据节点。
- 每个不是可搜索快照索引的索引 至少有一个每个分片的副本，除了主分片。
- 集群至少有三个符合主节点资格的节点，只要其中至少两个节点不是仅投票的主节点。
- 客户端配置为将请求发送到多个节点，或者配置为使用负载均衡器，该负载均衡器在适当的节点集合之间平衡请求。Elastic Cloud服务提供这样的负载均衡器。
大型集群中的弹性
edit节点共享常见的基础设施（如网络互连或电源）并不罕见。如果是这样，您应该为这些基础设施的故障做好计划，并确保这种故障不会影响过多的节点。通常的做法是将共享某些基础设施的所有节点分组到区域中，并为任何整个区域的故障做好计划。
Elasticsearch 期望节点之间的连接是可靠的、低延迟的，并且具有足够的带宽。许多 Elasticsearch 任务需要在节点之间进行多次往返。缓慢或不可靠的互连可能会对集群的性能和稳定性产生重大影响。
例如，每次往返增加几毫秒的延迟会迅速累积成明显的性能损失。不可靠的网络可能会频繁出现网络分区。Elasticsearch会尽可能快地自动从网络分区中恢复，但在分区期间您的集群可能会部分不可用，并且需要花费时间和资源来重新同步任何丢失的数据和重新平衡自身一旦分区修复。 从故障中恢复可能涉及在节点之间复制大量数据，因此恢复时间通常由可用带宽决定。
如果你已经将集群划分为多个区域，每个区域内的网络连接通常比区域之间的连接质量更高。确保区域之间的网络连接质量足够高。通过将所有区域定位在同一个数据中心内，并且每个区域都有自己独立的电源和其他支持基础设施，你将获得最佳效果。你还可以将集群扩展到附近的数据中心，只要每对数据中心之间的网络互连足够好。
运行一个健康的Elasticsearch集群没有特定的最低网络性能要求。理论上，即使节点之间的往返延迟达到几百毫秒，集群也能正常工作。但实际上，如果网络如此缓慢，集群性能将会非常差。此外，缓慢的网络通常不够可靠，可能会导致网络分区，从而导致一段时间内的不可用性。
如果您希望您的数据在相距较远或连接不佳的多个数据中心中可用，请在每个数据中心部署一个单独的集群，并使用跨集群搜索或跨集群复制将集群连接在一起。这些功能旨在即使集群间连接的可靠性或性能不如每个集群内部的网络，也能良好地执行。
在丢失整个区域的节点后，一个设计良好的集群可能仍然能够正常运行，但容量会显著降低。在处理此类故障时，您可能需要配置额外的节点以恢复集群中的可接受性能。
为了防止整个区域故障的恢复能力，重要的是在多个区域中有一份每个分片的副本，这可以通过在多个区域中放置数据节点并配置分片分配感知来实现。您还应确保客户端请求被发送到多个区域中的节点。
您应考虑所有节点角色，并确保每个角色在两个或更多区域中冗余分布。例如，如果您使用摄取管道或机器学习，您应在两个或更多区域中拥有摄取或机器学习节点。然而，主节点候选节点的放置需要更多注意，因为一个有弹性的集群至少需要三个主节点候选节点中的两个才能正常运行。以下部分探讨了在多个区域中放置主节点候选节点的选项。
双区集群
edit如果你有两个区域，你应该在每个区域中拥有不同数量的主节点，以便拥有更多节点的区域将包含大多数节点，并且能够承受另一个区域的损失。例如，如果你有三个主节点，你可以将它们全部放在一个区域中，或者你可以将两个放在一个区域中，第三个放在另一个区域中。你不应该在每个区域中放置相同数量的主节点。如果你在每个区域中放置相同数量的主节点，那么任何一个区域都没有自己的多数。因此，集群可能无法承受任何一个区域的损失。
带有仲裁器的双区域集群
edit上述的双区域部署能够容忍其中一个区域的丢失，但不能容忍另一个区域的丢失，因为主节点选举是基于多数原则的。你无法配置一个双区域集群，使其能够容忍任意一个区域的丢失，因为这在理论上是不可能的。你可能会期望，如果任意一个区域发生故障，Elasticsearch可以从剩余的区域中选举一个节点作为主节点，但无法区分远程区域的故障和仅仅是区域之间的连接丢失。如果两个区域都能够独立进行选举，那么连接丢失将导致脑裂问题，从而导致数据丢失。Elasticsearch通过避免这种情况并保护你的数据，不会从任意一个区域选举节点作为主节点，直到该节点能够确定它拥有最新的集群状态，并且集群中没有其他主节点。这可能意味着在连接恢复之前根本没有主节点。
您可以通过在每个区域中放置一个主节点，并在独立的第三个区域中添加一个额外的主节点来解决这个问题。这个额外的主节点在两个原始区域相互断开连接的情况下充当决胜节点。这个额外的决胜节点应该是一个专用仅投票主节点，也称为专用决胜节点。专用决胜节点不需要像其他两个节点那样强大，因为它没有其他角色，不会执行任何搜索，也不会协调任何客户端请求，也不会被选为集群的主节点。
您应该使用 shard allocation awareness 来确保每个区域中都有每个分片的副本。这意味着如果另一个区域发生故障，任一区域仍将保持完全可用。
所有主节点，包括仅投票节点，都是发布集群状态更新的关键路径。集群状态更新通常与性能关键型工作负载（如索引或搜索）无关，但它们涉及管理活动，如索引创建和滚动更新、映射更新以及故障后的恢复。这些活动的性能特征是每个主节点存储速度的函数，以及集群中所有节点之间网络互连的可靠性和延迟。因此，您必须确保集群中的节点可用的存储和网络足以满足您的性能目标。