我有一个在 AWS EC2 上运行的由 3 个 ElasticSearch 节点组成的集群。这些节点是使用 OpsWorks/Chef 设置的。我的意图是将这个集群设计得非常有弹性和弹性（节点可以在需要时进出）。
从我读到的所有关于 ElasticSearch 的文章来看，似乎没有人建议在集群前面放置一个负载均衡器。相反，似乎建议是做以下两件事之一：
将你的客户端指向一个节点的URL/IP，让ES为你做负载均衡，希望这个节点永远不会宕机。
将所有节点的 URL/IP 硬编码到客户端应用程序中，并让应用程序处理故障转移逻辑。
我的背景主要是在网络农场中，创建一个巨大的自治网络服务器池只是常识，在它们前面扔一个 ELB，让负载平衡器决定哪些节点是活动的还是死的。为什么 ES 似乎不支持同样的架构？
【问题讨论】：
标签： amazon-web-services elasticsearch amazon-ec2 lucene nosql
您不需要负载平衡器 - ES 已经提供了该功能。您只需要另一个组件，它可能会出现异常行为并且会添加不必要的网络跃点。
ES 会将您的数据分片（默认为 5 个分片），它会尝试在您的实例之间平均分配。在您的情况下，2 个实例应该有 2 个分片，而 1 个只有一个，但您可能希望将分片更改为 6 个以实现均等分布。
默认情况下，复制设置为"number_of_replicas":1，因此每个分片都有一个副本。假设您使用 6 个分片，它可能看起来像这样（R 是一个复制分片）：
假设 node1 死亡，集群将更改为以下设置：
根据您的连接设置，您可以连接到一个实例（传输客户端），也可以加入集群（节点客户端）。使用节点客户端，您将避免双跳，因为您将始终连接到正确的分片/索引。使用传输客户端，您的请求将被路由到正确的实例。
因此，您无需为自己进行负载平衡，您只会增加开销。自动聚类可能是 ES 最大的优势。
【讨论】：
您想要设计“故障转移”是完全正确的，在 AWS 中，我建议您这样做。
1) 限制集群中可以被选为主节点的节点。其余的，设置 node.client: true。根据您希望有多少可供故障转移使用，您可以选择有多少主可选节点。
2) 创建一个只包含可选主节点的 ELB。
3) 在 Route 53 中，为您的集群创建一个 CNAME，并将值设置为 ELB 的 DNS 名称。
【讨论】：
我认为对 Elasticsearch 集群进行负载平衡是个好主意（设计一个容错系统，对单节点故障具有弹性。）
要构建您的集群，您需要了解 Elasticsearch 的两个主要功能：1. 编写和更新文档以及 2. 查询文档。
在 elasticsearch 中编写/索引文档：
在 Elasticsearch 中查询文档：
为写入/索引/更新构建负载均衡器
Elasticsearch 自行管理分片在节点上的位置。 “主节点”保存并更新“分片路由表”。 “主节点”将分片路由表的副本提供给集群中的其他节点。
通常，您不希望您的主节点做更多的工作，而不仅仅是对集群进行健康检查、更新路由表和管理分片。
最好将负载均衡器指向“数据节点”（数据节点是包含数据=分片的节点）并让数据节点使用其分片路由表将写入写入正确的分片。
查询架构
Elasticsearch 创建了一个特殊的节点类型：“客户端节点”，它包含“无数据”，不能成为“主节点”。客户端节点的功能是在查询结束时执行最终的资源重合并排序。
对于 AWS，您可能会使用 c3 或 c4 实例类型作为“客户端节点”
最佳做法是将查询的负载均衡器指向客户端节点。
干杯！
参考资料：
【讨论】：
主节点出现故障时该怎么办，有点不清楚。挖掘后，这里有几个选项：
【讨论】：