我们正在运行一个elasticsearch集群，用于记录日志，使用logstash从多个位置索引日志。我们最近添加了两个额外的节点以增加容量，同时我们等待集群扩展的更多硬件。最终，我们的目标是拥有2个节点，用于＆＃34;实时＆＃34;在SSD上运行的数据可以快速访问最近的数据，并将数据老化到较旧的指标的HDD上。我们放入的新节点的内存比现有机箱少得多（700GB对5TB），但鉴于这与我们实施SSD时的情况类似，我并不认为它是很大的问题。
作为第一次尝试，我将节点放入群集中，信任新的基于磁盘间隔的分配规则意味着它们不会立即被填满。遗憾的是，情况并非如此，我醒来发现群集已经快速地将分片重新分配到新节点上，超过99％。经过一些设置的跳汰后，我设法从这些节点中删除所有数据，并将群集返回到它之前的状态（所有分配的分片，群集状态为绿色）。
作为下一个方法，我尝试实现类似于我实施SSD时的计划的索引/节点标记。这给我们留下了以下配置：
（运行elasticsearch 1.3.1和oracle java 7 u55的所有节点）
使用策展人我然后将超过10天的指标标记为＆＃34;存档＆＃34;以及更近期的＆＃34;实时＆＃34;。这在后台设置索引分片分配＆＃34;要求＆＃34;。我的理解是它需要节点有标签，但不仅仅是标签。
不幸的是，这似乎没有达到预期的效果。最令人担忧的是，没有标记为归档的索引正在分配其副本分片，留下295个未分配的分片。此外，实时标记的标记仅使用节点4,5和奇怪的3.节点3没有除最新索引和一些kibana-int分片之外的分片。
如果我删除标签并使用exclude._ip从新节点拉出分片，我可以（慢慢地）将群集恢复为绿色，因为这是我在新节点完全填满时采用的方法，但我和＃39; d非常希望对此设置进行排序，这样我就可以确信SSD配置在新套件到货时能够正常工作。
我试图启用：cluster.routing.allocation.allow_rebalance总是，理论上群集由于未分配的副本而没有重新平衡。 我也尝试过：cluster.routing.allocation.enable给所有人，但同样，这没有明显的影响。
我做错了什么吗？或者是否存在我可以使用的某种不一致？我已经使用Elasticsearch Head插件可视化分片的分配。
任何帮助都会受到赞赏，希望这只是一个我可以轻松解决的愚蠢错误！
提前致谢
答案 0 :(得分：1)
这可能不能完全回答你的问题，但看到今天早上我正在看这些文档：
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-allocation.html#disk 您应该能够在版本中设置磁盘使用情况的水印，以避免再次发生这种情况。
对于集群的（手动）监控我非常喜欢 https://github.com/lmenezes/elasticsearch-kopf
目前看着我的群集在出现类似问题后再次整理它的碎片（这么慢），但我还在运行一个古老的版本。