ロギング用にelasticsearchクラスターを実行しており、logstashを使用して複数の場所からのログにインデックスを付けています。最近、クラスターの拡張用の追加のハードウェアを待っている間、容量を追加するために 2 つのノードを追加しました。最終的には、SSD で実行される「リアルタイム」データ用に 2 つのノードを用意して、最近のデータへの高速アクセスを提供し、古い指標のためにデータを HDD にエージングすることを目指しています。私たちが入れた新しいノードは、既存のボックスよりもはるかに少ないメモリ (700 GB 対 5 TB) でしたが、これは SSD を実装したときの状況と似ているため、大きな問題になるとは予想していませんでした。 .
最初の試みとして、新しいディスク容量ベースの割り当てルールを信頼してノードをクラスターに投入しました。これは、ノードがすぐにいっぱいにならないことを意味します。残念ながら、これは事実ではありませんでした.99% を超えて、クラスターが新しいノードにシャードを陽気に再割り当てしていることに気付きました. 設定を少し調整した後、これらのノードからすべてのデータを削除し、クラスターを以前の状態 (すべてのシャードが割り当てられ、クラスターの状態が緑色) に戻すことができました。
次のアプローチとして、SSD を実装するときの計画と同様に、インデックス/ノードのタグ付けを実装しようとしました。これにより、次の構成が残りました。
- ノード 1 - 5 TB、タグ: リアルタイム、アーカイブ
- ノード 2 - 5 TB、タグ: リアルタイム、アーカイブ
- ノード 3 - 5 TB、タグ: リアルタイム、アーカイブ
- ノード 4 - 700 GB、タグ: リアルタイム
- ノード 5 - 700 GB、タグ: リアルタイム
(elasticsearch 1.3.1 および oracle Java 7 u55 を実行しているすべてのノード)
キュレーターを使用して、10 日以上前のインデックスを「アーカイブ」としてタグ付けし、最近のものは「リアルタイム」としてタグ付けしました。これはバックグラウンドで、インデックス シャードの割り当てを "Require" に設定します。私の理解では、ノードにタグが必要ですが、そのタグだけではありません。
残念ながら、これは望ましい効果があったようには見えません。最も心配なのは、アーカイブとしてタグ付けされたインデックスがレプリカ シャードを割り当てておらず、295 個の未割り当てのシャードが残っていることです。さらに、リアルタイムでタグ付けされたインデックスは、ノード 4、5、および奇妙なことに 3 のみを使用しています。ノード 3 には、最新のインデックスといくつかの kibana-int シャードを除いてシャードがありません。
タグを削除し、exclude._ip を使用して新しいノードからシャードをプルすると、(ゆっくりと) クラスターをグリーンに戻すことができます。これは、新しいノードが完全にいっぱいになったときに取ったアプローチだからです。新しいキットが到着したときに SSD 構成が機能することを確信できるように、このセットアップを整理したいと思っています。
私は有効にしようとしました: 私も試しました: cluster.routing.allocation.enable をすべてに有効にしましたが、これも目に見える影響はありませんでした。
私は明らかに間違ったことをしましたか？または、私が使用できる何らかの診断がありますか? Elasticsearch Head プラグインを使用して、シャードの割り当てを視覚化してきました。
簡単に修正できるばかげた間違いであることを願っています。
前もって感謝します