小規模クラスターのレジリエンス

小規模クラスターでは、単一ノードの障害に対してレジリエンスを持つことが最も重要です。このセクションでは、個々のノードの障害に対してクラスターをできるだけレジリエントにするためのガイダンスを提供します。

単一ノードクラスター

クラスターが1つのノードで構成されている場合、その単一ノードはすべての作業を行う必要があります。これに対応するために、Elasticsearchはデフォルトでノードにすべての役割を割り当てます。

単一ノードクラスターはレジリエントではありません。ノードが障害を起こすと、クラスターは機能しなくなります。1ノードクラスターにはレプリカがないため、データを冗長に保存することはできません。ただし、デフォルトでは、少なくとも1つのレプリカがgreen クラスターの健康状態に必要です。クラスターがgreen ステータスを報告できるようにするには、すべてのインデックスでindex.number_of_replicasを0に設定してデフォルトを上書きしてください。

ノードが障害を起こした場合、失われたインデックスの古いコピーを@snapshotから復元する必要があるかもしれません。

障害に対してレジリエントではないため、プロダクションでの単一ノードクラスターの使用は推奨しません。

二ノードクラスター

ノードが2つある場合、両方ともデータノードであることを推奨します。また、index.number_of_replicasを1に設定することで、すべてのシャードが両方のノードに冗長に保存されることを確認する必要があります。これはデフォルトの動作ですが、@index templateによって上書きされる可能性があります。@Auto-expand replicasも同じことを達成できますが、そのような小さなクラスターではこの機能を使用する必要はありません。

2つのノードのうち1つだけを@master-eligibleに設定することを推奨します。これにより、どのノードがクラスターの選出されたマスターであるかを確実に知ることができます。クラスターは、他のマスター不適格ノードの喪失に耐えることができます。両方のノードをマスター適格に設定すると、マスター選挙には2つのノードが必要です。どちらかのノードが利用できない場合、選挙は失敗するため、クラスターはどちらのノードの喪失にも信頼性を持って耐えることができません。

デフォルトでは、各ノードにすべての役割が割り当てられます。両方のノードにマスター適格以外のすべての役割を割り当てることを推奨します。1つのノードが障害を起こした場合、もう1つのノードがそのタスクを処理できます。

クライアントリクエストを単一のノードに送信することは避けるべきです。そうしないと、そのノードが障害を起こした場合、残りのノードが健康なクラスターであっても、リクエストは応答を受け取れません。理想的には、クライアントリクエストを両方のノードに均等に分散させるべきです。これを行う良い方法は、クライアントをクラスターに接続する際に両方のノードのアドレスを指定することです。あるいは、レジリエントなロードバランサーを使用して、クラスター内のノード間でクライアントリクエストをバランスさせることができます。

障害に対してレジリエントではないため、プロダクションでの二ノードクラスターの展開は推奨しません。

タイブレイカーを持つ二ノードクラスター

マスター選挙は過半数ベースで行われるため、上記の二ノードクラスターは1つのノードの喪失には耐えられますが、もう1つのノードの喪失には耐えられません。いずれかのノードの喪失に耐えられるように二ノードクラスターを構成することは理論的に不可能です。どちらかのノードが障害を起こした場合、Elasticsearchが残りのノードをマスターとして選出できると期待するかもしれませんが、リモートノードの障害とノード間の単なる接続の喪失を区別することは不可能です。両方のノードが独立した選挙を実行できる場合、接続の喪失はhttps://en.wikipedia.org/wiki/Split-brain_(computing スプリットブレイン問題を引き起こし、したがってデータの喪失につながります。Elasticsearchはこれを回避し、データを保護するために、ノードが最新のクラスター状態を持っていることを確認し、クラスター内に他のマスターが存在しないことが確認されるまで、どちらのノードもマスターとして選出しません。これにより、接続が回復するまでクラスターにマスターが存在しない可能性があります。

この問題を解決するには、3つ目のノードを追加し、すべてのノードをマスター適格にすることができます。@master electionには、3つのマスター適格ノードのうち2つだけが必要です。これにより、クラスターは任意の単一ノードの喪失に耐えることができます。この3つ目のノードは、元の2つのノードが互いに切断されている場合のタイブレイカーとして機能します。この追加ノードのリソース要件を削減するために、@voting-only master-eligible nodeにすることもできます。これは、専用のタイブレイカーとも呼ばれます。役割がないため、専用のタイブレイカーは他の2つのノードほど強力である必要はありません。検索を実行したり、クライアントリクエストを調整したりすることはなく、クラスターのマスターとして選出されることもありません。

元の2つのノードは、投票専用のマスター適格ノードであってはなりません。レジリエントなクラスターには、少なくとも3つのマスター適格ノードが必要であり、そのうち少なくとも2つは投票専用のマスター適格ノードであってはなりません。3つのノードのうち2つが投票専用のマスター適格ノードである場合、選出されたマスターは3つ目のノードでなければなりません。このノードは単一障害点となります。

両方の非タイブレイカーのノードにすべての他の役割を割り当てることを推奨します。これにより、クラスター内の任意のタスクがどちらのノードでも処理できるように冗長性が確保されます。

専用のタイブレイカーのノードにクライアントリクエストを送信しないでください。また、他の2つのノードのうちの1つにのみクライアントリクエストを送信することも避けるべきです。そうしないと、そのノードが障害を起こした場合、残りのノードが健康なクラスターであっても、リクエストは応答を受け取れません。理想的には、非タイブレイカーの2つのノードにクライアントリクエストを均等に分散させるべきです。これを行うには、クライアントをクラスターに接続する際に両方のノードのアドレスを指定します。あるいは、適切なノード間でクライアントリクエストをバランスさせるために、レジリエントなロードバランサーを使用できます。@Elastic Cloudサービスは、そのようなロードバランサーを提供します。

タイブレイカーのある二ノードクラスターは、プロダクション展開に適した最小のクラスターです。

三ノードクラスター

ノードが3つある場合、すべてを@data nodesにし、@searchable snapshot indexでないすべてのインデックスに少なくとも1つのレプリカを持たせることを推奨します。ノードはデフォルトでデータノードです。いくつかのインデックスに2つのレプリカを持たせて、各ノードがそれらのインデックス内の各シャードのコピーを持つようにすることを好むかもしれません。また、各ノードを@master-eligibleに設定して、任意の2つのノードが3つ目のノードと通信することなくマスター選挙を行えるようにする必要があります。ノードはデフォルトでマスター適格です。このクラスターは、任意の単一ノードの喪失に対してレジリエントです。

クライアントリクエストを単一のノードに送信することは避けるべきです。そうしないと、そのノードが障害を起こした場合、残りの2つのノードが健康なクラスターであっても、リクエストは応答を受け取れません。理想的には、クライアントリクエストを3つのノード全体に均等に分散させるべきです。これを行うには、クライアントをクラスターに接続する際に複数のノードのアドレスを指定します。あるいは、クラスター全体にクライアントリクエストをバランスさせるために、レジリエントなロードバランサーを使用できます。@Elastic Cloudサービスは、そのようなロードバランサーを提供します。

三ノード以上のクラスター

クラスターが3ノードを超えると、ノードをその責任に応じて専門化し、必要に応じてリソースを独立してスケールさせることができます。必要に応じて、@data nodes、@ingest nodes、@machine learning nodesなど、必要なだけのノードを持つことができます。クラスターが大きくなるにつれて、各役割に専用ノードを使用することを推奨します。これにより、各タスクのリソースを独立してスケールさせることができます。

ただし、クラスター内のマスター適格ノードの数を3つに制限することは良いプラクティスです。マスターノードは他のノードタイプのようにスケールしないため、クラスターは常にそのうちの1つをマスターとして選出します。マスター適格ノードが多すぎると、マスター選挙が完了するまでに時間がかかる場合があります。大規模なクラスターでは、いくつかのノードを専用のマスター適格ノードとして構成し、これらの専用ノードにクライアントリクエストを送信しないことを推奨します。マスター適格ノードが不要な余分な作業で圧倒されると、クラスターが不安定になる可能性があります。

マスター適格ノードの1つを@voting-only nodeに構成することで、マスターノードとして選出されることが決してないようにすることができます。たとえば、2つの専用マスターノードと、データノードおよび投票専用のマスター適格ノードの両方である3つ目のノードを持つことができます。この3つ目の投票専用ノードは、マスター選挙でタイブレイカーとして機能しますが、決してマスターにはなりません。

まとめ

クラスターは、次の条件を満たす限り、任意のノードの喪失に対してレジリエントです。

  • クラスターの健康状態がgreenである。
  • データノードが少なくとも2つある。
  • searchable snapshot indexでないすべてのインデックスには、プライマリに加えて各シャードの少なくとも1つのレプリカがある。
  • クラスターには、少なくとも3つのマスター適格ノードがあり、これらのノードのうち少なくとも2つは投票専用のマスター適格ノードでない。
  • クライアントは、リクエストを複数のノードに送信するように構成されているか、適切なノードセット間でリクエストをバランスさせるロードバランサーを使用するように構成されている。@Elastic Cloudサービスは、そのようなロードバランサーを提供します。