Elasticsearchクラスタの脳裂問題
2036 ワード
脳裂問題(精神分裂に類似)とは,同じクラスタにおける異なるノードであり,クラスタの状態について異なる理解を持つ.
今日、Elasticsearchクラスタではクエリが極端に遅くなり、次のコマンドでクラスタのステータスを表示します.
curl -XGET 'es-1:9200/_cluster/health'
クラスタの全体的な状態はredであり,本来9つのノードのクラスタは結果として4つしか表示されないことが分かった.しかし、リクエストを異なるノードに送信した後、全体的なステータスがredであっても、使用可能なノードの数が一致しないことに気づきました.
通常、クラスタ内のすべてのノードは、クラスタ内のmasterの選択に一致するべきであり、このようにして得られる状態情報も一致し、一致しない状態情報であるべきであり、異なるノードがmasterノードの選択に異常が発生したことを示す--いわゆる脳裂問題である.このような脳裂状態はノードにクラスタの正確な状態を直接失わせ,クラスタが正常に動作しない.
原因:
1.ネットワーク:イントラネット通信のため、ネットワーク通信の問題で一部のノードはmasterが死んだと思っているが、別のmasterを選ぶ可能性は低い.さらにGangliaクラスタモニタリングを確認しても異常なイントラネットトラフィックは認められなかったため,この原因は排除できる.
2.ノード負荷:masterノードとdataノードが混在しているため、ワークノードの負荷が大きい(確かに大きい)場合、対応するESインスタンスが応答を停止し、このサーバがmasterノードのアイデンティティとして機能している場合、一部のノードはこのmasterノードが失効したと判断し、新しいノードを再選挙すると、脳裂が発生する.また、dataノードでESプロセスが消費するメモリが大きいため、大規模なメモリ回収操作でもESプロセスが応答を失う可能性があります.だから、この原因の可能性は最大のはずだ.
問題に対処する方法:
1.上記の解析に対応して、ノード負荷によりmasterプロセスが応答を停止し、一部のノードがmasterの選択に食い違いが生じたと推測される.このため,直感的な解決策はmasterノードとdataノードを分離することである.このため、ESクラスタに3台のサーバを追加しましたが、それらの役割はmasterノードにすぎず、ストレージと検索の役割を果たしていないため、比較的軽量レベルのプロセスです.次の構成でロールを制限できます.
もちろん、他のノードはマスターを担当することはできません.上の構成を逆にすればいいです.これによりmasterノードとdataノードを分離することができる.もちろん、新しく追加されたノードがmasterの位置を迅速に決定するために、dataノードのデフォルトのmaster検出方式をmulticastからunicastに変更することができます.
2.脳裂の問題を緩和する2つの直感的なパラメータがあります.
discovery.zen.ping_timeout(デフォルト値は3秒):デフォルトでは、masterノードが3秒以内に応答しなければ、このノードは死んでしまい、この値を増加させると、ノードが応答を待つ時間が増加し、ある程度誤判が減少すると考えられます.
discovery.zen.minimum_master_Nodes(デフォルトは1):このパラメータは、クラスタ内で操作するには、1つのノードが表示するmasterノード資格を持つ最小数を制御します.公式の推奨値は(N/2)+1で、Nはマスター資格を持つノードの数です(私たちの場合は3なのでこのパラメータは2に設定しますが、2ノードしかない場合は2に設定すると問題があります.1ノードDOWNが落ちた後、2台のサーバーに接続できないことに注意してください).
以上の解決方法はこのような現象の発生を遅らせることしかできなくて、根本的に根絶していませんが、結局役に立ちます.もし他のもっと良い提案があれば、検討を歓迎します.
今日、Elasticsearchクラスタではクエリが極端に遅くなり、次のコマンドでクラスタのステータスを表示します.
curl -XGET 'es-1:9200/_cluster/health'
クラスタの全体的な状態はredであり,本来9つのノードのクラスタは結果として4つしか表示されないことが分かった.しかし、リクエストを異なるノードに送信した後、全体的なステータスがredであっても、使用可能なノードの数が一致しないことに気づきました.
通常、クラスタ内のすべてのノードは、クラスタ内のmasterの選択に一致するべきであり、このようにして得られる状態情報も一致し、一致しない状態情報であるべきであり、異なるノードがmasterノードの選択に異常が発生したことを示す--いわゆる脳裂問題である.このような脳裂状態はノードにクラスタの正確な状態を直接失わせ,クラスタが正常に動作しない.
原因:
1.ネットワーク:イントラネット通信のため、ネットワーク通信の問題で一部のノードはmasterが死んだと思っているが、別のmasterを選ぶ可能性は低い.さらにGangliaクラスタモニタリングを確認しても異常なイントラネットトラフィックは認められなかったため,この原因は排除できる.
2.ノード負荷:masterノードとdataノードが混在しているため、ワークノードの負荷が大きい(確かに大きい)場合、対応するESインスタンスが応答を停止し、このサーバがmasterノードのアイデンティティとして機能している場合、一部のノードはこのmasterノードが失効したと判断し、新しいノードを再選挙すると、脳裂が発生する.また、dataノードでESプロセスが消費するメモリが大きいため、大規模なメモリ回収操作でもESプロセスが応答を失う可能性があります.だから、この原因の可能性は最大のはずだ.
問題に対処する方法:
1.上記の解析に対応して、ノード負荷によりmasterプロセスが応答を停止し、一部のノードがmasterの選択に食い違いが生じたと推測される.このため,直感的な解決策はmasterノードとdataノードを分離することである.このため、ESクラスタに3台のサーバを追加しましたが、それらの役割はmasterノードにすぎず、ストレージと検索の役割を果たしていないため、比較的軽量レベルのプロセスです.次の構成でロールを制限できます.
node.master: true
node.data: falseもちろん、他のノードはマスターを担当することはできません.上の構成を逆にすればいいです.これによりmasterノードとdataノードを分離することができる.もちろん、新しく追加されたノードがmasterの位置を迅速に決定するために、dataノードのデフォルトのmaster検出方式をmulticastからunicastに変更することができます.
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["master1", "master2", "master3"]2.脳裂の問題を緩和する2つの直感的なパラメータがあります.
discovery.zen.ping_timeout(デフォルト値は3秒):デフォルトでは、masterノードが3秒以内に応答しなければ、このノードは死んでしまい、この値を増加させると、ノードが応答を待つ時間が増加し、ある程度誤判が減少すると考えられます.
discovery.zen.minimum_master_Nodes(デフォルトは1):このパラメータは、クラスタ内で操作するには、1つのノードが表示するmasterノード資格を持つ最小数を制御します.公式の推奨値は(N/2)+1で、Nはマスター資格を持つノードの数です(私たちの場合は3なのでこのパラメータは2に設定しますが、2ノードしかない場合は2に設定すると問題があります.1ノードDOWNが落ちた後、2台のサーバーに接続できないことに注意してください).
以上の解決方法はこのような現象の発生を遅らせることしかできなくて、根本的に根絶していませんが、結局役に立ちます.もし他のもっと良い提案があれば、検討を歓迎します.