我有一个在AWS EC2上运行的3个ElasticSearch节点集群。这些节点是使用OpsWorks / Chef设置的。我的目的是将该群集设计为非常有弹性和弹性（需要时，节点可以进出）。
从我阅读的有关ElasticSearch的所有内容来看，似乎没有人建议将负载均衡器放在集群的前面。相反，似乎建议您执行以下两项操作之一：
将您的客户端指向一个节点的URL / IP，让ES为您完成负载平衡，并希望该节点永远不会出现故障。
将所有节点的URL / IP硬编码到客户端应用程序中，并让该应用程序处理故障转移逻辑。
我的背景主要是在Web场中，创建一个巨大的自治Web服务器池，在它们前面放一个ELB，然后让负载均衡器确定哪些节点是活动的还是死亡的只是常识。为什么ES似乎不支持这种相同的体系结构？
您不需要负载平衡器-ES已经提供了该功能。您可能只是另一个组件，它可能行为不当，并且会添加不必要的网络跃点。
ES将分片您的数据（默认为5个分片），它将尝试在您的实例之间平均分配。在您的情况下，2个实例应具有2个分片，而1个只有一个，但是您可能需要将分片更改为6个以实现均等分布。
默认情况下，复制设置为"number_of_replicas":1，因此每个分片都有一个副本。假设您正在使用6个分片，则看起来可能像这样（R是复制的分片）：
"number_of_replicas":1
假设node1死了，集群将更改为以下设置：
根据您的连接设置，您可以连接到一个实例（传输客户端），也可以加入群集（节点客户端）。使用节点客户端，您将避免双跳，因为您将始终连接到正确的分片/索引。使用传输客户端，您的请求将被路由到正确的实例。
因此，没有什么可以自己平衡负载的，您只需增加开销即可。自动群集可能是ES的最大优势。
