我试图想办法扩展我们的弹性搜索设置。人们是否在Elasticsearch集群上使用多个节点客户端,并将它们放在负载均衡器/反向代理(如Nginx)之前。其他想法会很棒。
答案 0 :(得分:26)
因此,我首先重新调整您可以在Elasticsearch中配置的三种不同类型的节点:
数据节点 - node.data设置为true,node.master设置为false - 这些是弹性搜索集群的核心节点,其中包含数据 被储存了。
专用主节点 - 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