我们正在运行一个 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 的节点）
然后，我使用 curator 将超过 10 天的索引标记为“存档”，将最近的索引标记为“实时”。这在后台设置索引分片分配“要求”。我的理解是它需要节点有标签，但不仅仅是那个标签。
不幸的是，这似乎没有达到预期的效果。最令人担忧的是，没有标记为存档的索引正在分配它们的副本分片，留下 295 个未分配的分片。此外，实时标记的索引仅使用节点 4、5 和奇怪的 3。节点 3 没有分片，除了最新的索引和一些 kibana-int 分片。
如果我删除标签并使用 exclude._ip 从新节点中拉出分片，我可以（慢慢地）将集群恢复为绿色，因为这是我在新节点完全填满时采用的方法，但我真的喜欢对这个设置进行排序，这样我就可以确信 SSD 配置在新套件到货时可以正常工作。
我试图启用：cluster.routing.allocation.allow_rebalance 总是，理论上集群由于未分配的副本而没有重新平衡。我也试过：cluster.routing.allocation.enable to all，但同样，这没有明显的影响。
我做了什么明显错误的事情吗？或者是否有某种我可以使用的诊断方法？我一直在使用 Elasticsearch Head 插件来可视化分片的分配。
任何帮助将不胜感激，希望这只是一个我可以轻松解决的愚蠢错误！
提前致谢