小型集群的弹性

如果您的集群由一个节点组成，那么该单个节点必须完成所有工作。为了适应这种情况，Elasticsearch 默认情况下会为节点分配所有角色。

单节点集群不具备弹性。如果该节点发生故障，则集群将停止工作。由于单节点集群中没有副本，因此您无法冗余地存储数据。但是，默认情况下，至少需要一个副本才能使 green 集群健康状态。为了确保您的集群可以报告 green 状态，请通过在每个索引上将 index.number_of_replicas 设置为 0 来覆盖默认值。

如果节点发生故障，您可能需要从快照还原任何丢失索引的旧副本。

由于它们对任何故障都不具备弹性，因此我们不建议在生产环境中使用单节点集群。

如果您有两个节点，我们建议它们都为数据节点。您还应通过在每个非 可搜索快照索引的索引上将 index.number_of_replicas 设置为 1，来确保每个分片都冗余地存储在两个节点上。这是默认行为，但可能会被索引模板覆盖。自动扩展副本也可以实现相同的效果，但在这样的小型集群中没有必要使用此功能。

我们建议您将两个节点中的一个设置为符合主节点条件的。这意味着您可以确定哪个节点是集群的选举主节点。该集群可以容忍另一个不符合主节点条件的节点的丢失。如果您将两个节点都设置为符合主节点条件，则需要两个节点才能进行主节点选举。由于如果任何一个节点不可用，选举将失败，因此您的集群无法可靠地容忍任何节点的丢失。

默认情况下，每个节点都分配有所有角色。我们建议您为两个节点分配除主节点资格之外的所有其他角色。如果一个节点发生故障，另一个节点可以处理其任务。

您应避免仅将客户端请求发送到您的其中一个节点。如果您这样做，并且此节点发生故障，则即使剩余的节点本身是一个健康的集群，此类请求也不会收到响应。理想情况下，您应该在两个节点之间平衡您的客户端请求。做到这一点的不错方法是在配置客户端以连接到您的集群时指定两个节点的地址。或者，您可以使用弹性负载均衡器来平衡集群中节点之间的客户端请求。

由于它对故障不具备弹性，因此我们不建议在生产环境中部署双节点集群。

由于主节点选举是基于多数的，因此上述描述的双节点集群可以容忍其中一个节点的丢失，但不能容忍另一个节点的丢失。您无法配置双节点集群，使其可以容忍任何节点的丢失，因为这在理论上是不可能的。您可能会认为，如果任何一个节点发生故障，则 Elasticsearch 可以选举剩余节点为主节点，但是不可能区分远程节点的故障和节点之间仅仅是连接丢失。如果两个节点都能够运行独立的选举，则连接丢失会导致脑裂问题，从而导致数据丢失。Elasticsearch 通过不选举任何一个节点为主节点来避免这种情况并保护您的数据，直到该节点可以确定它具有最新的集群状态并且集群中没有其他主节点。这可能会导致集群在连接恢复之前没有主节点。

您可以通过添加第三个节点并使所有三个节点都符合主节点条件来解决此问题。 主节点选举只需要三个符合主节点条件的节点中的两个。这意味着该集群可以容忍任何单个节点的丢失。当两个原始节点彼此断开连接时，第三个节点充当仲裁器。您可以通过将其设为专用的仅投票的主节点资格节点（也称为专用仲裁器）来降低此额外节点的资源需求。由于它没有其他角色，因此专用仲裁器不需要像其他两个节点那样强大。它不会执行任何搜索，也不会协调任何客户端请求，并且不能被选举为集群的主节点。

两个原始节点不应是仅投票的主节点资格节点，因为一个具有弹性的集群至少需要三个符合主节点条件的节点，其中至少两个不是仅投票的主节点资格节点。如果您的三个节点中的两个是仅投票的主节点资格节点，那么当选的主节点必须是第三个节点。然后，此节点将成为单点故障。

我们建议为两个非仲裁器节点分配所有其他角色。通过确保集群中的任何任务都可以由任何一个节点处理，从而创建冗余。

您不应将任何客户端请求发送到专用仲裁器节点。您还应避免仅将客户端请求发送到其他两个节点中的一个。如果您这样做，并且此节点发生故障，则任何请求都不会收到响应，即使剩余节点构成一个健康的集群。理想情况下，您应该在两个非仲裁器节点之间平衡您的客户端请求。您可以通过在配置客户端以连接到集群时指定两个节点的地址来做到这一点。或者，您可以使用弹性负载均衡器来平衡集群中相应节点之间的客户端请求。Elastic Cloud 服务提供了这样的负载均衡器。

带有附加仲裁器节点的双节点集群是适合生产部署的最小可行集群。

如果您有三个节点，我们建议它们都为 数据节点，并且每个非可搜索快照索引的索引都应至少有一个副本。默认情况下，节点是数据节点。您可能更希望某些索引有两个副本，以便每个节点都具有这些索引中每个分片的副本。您还应将每个节点配置为符合主节点条件，以便它们中的任意两个都可以在无需与第三个节点通信的情况下进行主节点选举。默认情况下，节点符合主节点条件。此集群将能够容忍任何单个节点的丢失。

您应避免仅将客户端请求发送到您的其中一个节点。如果您这样做，并且此节点发生故障，则即使剩余的两个节点构成一个健康的集群，任何请求也不会收到响应。理想情况下，您应该在所有三个节点之间平衡您的客户端请求。您可以通过在配置客户端以连接到您的集群时指定多个节点的地址来做到这一点。或者，您可以使用弹性负载均衡器来平衡集群之间的客户端请求。Elastic Cloud 服务提供了这样的负载均衡器。

一旦您的集群增长到三个以上的节点，您就可以开始根据其职责来专门化这些节点，从而使您可以根据需要独立地扩展其资源。您可以拥有任意数量的数据节点，摄取节点，机器学习节点等，以支持您的工作负载。随着集群的增长，我们建议为每个角色使用专用节点。这使您可以独立扩展每个任务的资源。

但是，最好将集群中符合主节点条件的节点数限制为三个。主节点不像其他节点类型那样可以扩展，因为集群始终只选举其中一个作为集群的主节点。如果符合主节点条件的节点太多，则主节点选举可能需要更长的时间才能完成。在较大的集群中，我们建议您将某些节点配置为专用的符合主节点条件的节点，并避免将任何客户端请求发送到这些专用节点。如果符合主节点条件的节点不堪重负，而其他节点可以处理的不必要额外工作，则您的集群可能会变得不稳定。

您可以将其中一个符合主节点条件的节点配置为仅投票的节点，以便它永远不会被选举为主节点。例如，您可能有两个专用的主节点和第三个既是数据节点又是仅投票的符合主节点条件的节点。此第三个仅投票的节点将在主节点选举中充当仲裁器，但永远不会成为主节点本身。

只要满足以下条件，集群就可以弹性地容忍任何节点的丢失