我正在想办法扩展我们的 elasticsearch 设置。人们是否在 Elasticsearch 集群上使用多个节点客户端并将它们放在负载均衡器/反向代理(如 Nginx)的前面。其他想法会很棒。
最佳答案
因此，我将从重新概括您可以在 Elasticsearch 中配置的三种不同类型的节点开始:
数据节点 - node.data 设置为 true，node.master 设置为 false - 这些是 elasticsearch 集群的核心节点，其中数据 被储存了。
专用主节点 - node.data 设置为 false，node.master 为 设置为 true - 这些负责管理集群状态。
客户端节点 - node.data 设置为 false，node.master 设置为
false - 这些响应客户端数据请求，查询结果
从数据节点收集数据返回给客户端。
通过将功能拆分为 3 种不同的基本节点类型，您可以在管理集群规模时获得很大程度的粒度和控制。由于每种节点类型都处理一组更加独立的职责，因此您能够更好地调整每个节点并适本地扩展。
对于数据节点，它是处理索引和查询响应的功能，同时确保您为每个节点分配了足够的存储空间。您需要监控每个节点的存储使用情况和磁盘吞吐量，以及 CPU 和内存使用情况。您希望避免配置磁盘用完或磁盘饱和，同时仍然有大量多余的 cpu 和内存，或者相反，内存和 cpu 最大但您有很多可用磁盘。确定这一点的最佳方法是通过对典型索引和查询事件进行一些基准测试。
对于主节点，您应该始终至少有 3 个并且应该始终有一个奇数。法定人数应设置为 N/2 + 1，其中 N 是主节点的数量。这样您就不会遇到集群的裂脑问题。专用主节点往往负载不重，因此可以非常小。
对于客户端节点，您确实可以将它们放在负载均衡器后面，或者使用 dns 条目指向它们。只需向集群中添加更多，就可以轻松地扩大和缩小它们，并且应该添加它们以实现冗余以及您看到的 cpu 和内存使用率攀升。不需要很多磁盘。
无论您的配置如何，除了提前对可能的负载进行基准测试外，我强烈建议密切监控 CPU、内存和磁盘 - ES 很容易开始推出，但在您扩展到更大数量时确实需要观察事务和更多节点。处理由于内存或磁盘耗尽导致的节点故障而导致的黄色或红色状态集群并不是一件很有趣的事情。
为了了解一些背景，我会仔细阅读这篇文章:
http://elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
加上本系列文章:
http://elastic.co/guide/en/elasticsearch/guide/current/distributed-cluster.html
关于elasticsearch - 在 elasticsearch 中使用多节点客户端，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27408601/