我们正在运行一个elasticsearch集群,用于记录日志,使用logstash从多个位置索引日志.我们最近添加了两个额外的节点以增加容量,同时我们等待集群扩展的更多硬件.最终,我们的目标是在SSD上运行"实时"数据的2个节点,以便快速访问最近的数据,并将数据老化到较旧的指标的HDD上.我们放入的新节点的内存比现有机箱少得多(700GB对5TB),但考虑到这与我们实施SSD时的情况类似,我并不认为这是一个很大的问题. .
作为第一次尝试,我将节点扔进集群中,信任新的基于磁盘空间的分配规则意味着它们不会立即被填满.不幸的是,情况并非如此,我醒来发现群集已经快速地将分片重新分配到新节点上,超过99%.在设置了一些跳汰之后,我设法从这些节点中删除所有数据,并将群集返回到之前的状态(分配了所有分片,群集状态为绿色).
作为下一个方法,我尝试实现索引/节点标记,类似于我实施SSD时的计划.这给我们留下了以下配置:
节点1 - 5TB,标签:实时,存档
节点2 - 5TB,标签:实时,存档
节点3 - 5TB,标签:实时,存档
节点4 - 700GB,标签:实时
节点5 - 700GB,标签:实时
(运行elasticsearch 1.3.1和oracle java 7 u55的所有节点)
使用策展人我然后将超过10天的标记标记为"存档",将更新的标记标记为"实时".这在后台设置索引分片分配"需要".我的理解是它需要节点有标签,但不仅仅是标签.
不幸的是,这似乎没有产生预期的效果.最令人担忧的是,没有标记为归档的索引正在分配其副本分片,留下295个未分配的分片.此外,实时标记的指示仅使用节点4,5和奇怪的3.除了最新的索引和一些kibana-int分片之外,节点3没有分片.
如果我删除标签并使用exclude._ip从新节点拉出分片,我可以(慢慢地)将群集恢复为绿色,因为这是我在新节点完全填满时采用的方法,但我真的喜欢将此设置排序,以便我可以放心,当新套件到货时,SSD配置将起作用.
我试图启用:cluster.routing.allocation.allow_rebalance to always,理论上由于未分配的副本,集群没有重新平衡.我也尝试过:cluster.routing.allocation.enable给所有人,但同样,这没有任何可辨别的影响.
我做过一些明显错误的事吗?或者是否存在我可以使用的某种不一致?我一直在使用Elasticsearch Head插件可视化分片的分配.
任何帮助将不胜感激,希望这只是一个愚蠢的错误,我可以很容易地解决!
提前致谢