大規模クラスターにおけるレジリエンス

ノードがネットワーク接続や電源供給などの共通インフラを共有することは珍しくありません。その場合、このインフラの障害を考慮し、その障害があまり多くのノードに影響を与えないように計画する必要があります。共通のインフラを共有するすべてのノードを ゾーン にグループ化し、任意のゾーン全体の障害を計画することが一般的な慣行です。

Elasticsearchは、ノード間の接続が信頼性が高く、低遅延で、十分な帯域幅を持つことを期待しています。多くのElasticsearchタスクは、ノード間で複数の往復を必要とします。遅いまたは信頼性の低い接続は、クラスターのパフォーマンスと安定性に大きな影響を与える可能性があります。

たとえば、各往復に数ミリ秒の遅延が追加されると、すぐに目に見えるパフォーマンスのペナルティに累積する可能性があります。信頼性の低いネットワークは、頻繁にネットワークパーティションを引き起こす可能性があります。Elasticsearchは、ネットワークパーティションからできるだけ早く自動的に回復しますが、パーティション中はクラスターが部分的に利用できなくなる可能性があり、パーティションが回復した後に欠落データを再同期するために時間とリソースを費やす必要があります。また、再バランスを行う必要があります。障害からの回復には、ノード間で大量のデータをコピーすることが含まれる場合があるため、回復時間は通常、利用可能な帯域幅によって決まります。

クラスターをゾーンに分割している場合、各ゾーン内のネットワーク接続は通常、ゾーン間の接続よりも高品質です。ゾーン間のネットワーク接続が十分に高品質であることを確認してください。すべてのゾーンを単一のデータセンター内に配置し、各ゾーンが独立した電源供給とその他のサポートインフラを持つことで、最良の結果が得られます。また、各データセンター間のネットワーク接続が十分に良好であれば、クラスターを近くのデータセンターに ストレッチ することもできます。

健全なElasticsearchクラスターを運用するために必要な特定の最小ネットワークパフォーマンスはありません。理論的には、ノード間の往復遅延が数百ミリ秒であってもクラスターは正しく機能します。実際には、ネットワークがそれほど遅い場合、クラスターのパフォーマンスは非常に悪くなります。さらに、遅いネットワークは、ネットワークパーティションを引き起こすのに十分なほど信頼性が低く、利用できない期間を引き起こす可能性があります。

データがより遠く離れた、または接続が不十分な複数のデータセンターで利用可能であることを望む場合は、各データセンターに別のクラスターを展開し、クロスクラスター検索またはクロスクラスター複製を使用してクラスターをリンクします。これらの機能は、クラスター間の接続が各クラスター内のネットワークよりも信頼性が低いまたはパフォーマンスが劣る場合でも、良好に機能するように設計されています。

ゾーン全体のノードを失った後、適切に設計されたクラスターは機能する可能性がありますが、容量が大幅に減少している状態で動作します。このような障害を処理する際にクラスターのパフォーマンスを回復するために、追加のノードを用意する必要があるかもしれません。

ゾーン全体の障害に対するレジリエンスを確保するためには、各シャードのコピーが複数のゾーンに存在することが重要であり、これはデータノードを複数のゾーンに配置し、シャード割り当ての認識を構成することで実現できます。また、クライアントリクエストが複数のゾーンのノードに送信されることを確認する必要があります。

すべてのノードの役割を考慮し、各役割が2つ以上のゾーンに冗長に分割されていることを確認する必要があります。たとえば、インジェストパイプラインや機械学習を使用している場合、2つ以上のゾーンにインジェストまたは機械学習ノードを配置する必要があります。ただし、マスター候補ノードの配置にはもう少し注意が必要です。なぜなら、レジリエントなクラスターは機能するために3つのマスター候補ノードのうち少なくとも2つが必要だからです。以下のセクションでは、複数のゾーンにマスター候補ノードを配置するオプションについて探ります。

二ゾーンクラスター

2つのゾーンがある場合、各ゾーンに異なる数のマスター候補ノードを配置する必要があります。そうすることで、ノードが多いゾーンが過半数を占め、他のゾーンの喪失に耐えることができます。たとえば、3つのマスター候補ノードがある場合、すべてを1つのゾーンに配置するか、2つを1つのゾーンに、残りの1つを他のゾーンに配置することができます。各ゾーンに同じ数のマスター候補ノードを配置してはいけません。各ゾーンに同じ数のマスター候補ノードを配置すると、どちらのゾーンも自分自身の過半数を持たないことになります。したがって、クラスターはどちらのゾーンの喪失にも耐えられない可能性があります。

タイブレイカーを持つ二ゾーンクラスター

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

これを解決するには、各ゾーンに1つのマスター候補ノードを配置し、独立した第3のゾーンに1つの追加のマスター候補ノードを追加します。追加のマスター候補ノードは、元の2つのゾーンが互いに切断された場合のタイブレイカーとして機能します。追加のタイブレイカーノードは、投票専用のマスター候補ノードとして、または専用のタイブレーカーとして知られています。専用のタイブレーカーは、他の2つのノードほど強力である必要はありません。なぜなら、他の役割を持たず、検索を実行せず、クライアントリクエストを調整せず、クラスターのマスターとして選出されることもないからです。

シャード割り当ての認識を使用して、各ゾーンに各シャードのコピーが存在することを確認する必要があります。これにより、他のゾーンが失敗した場合でも、いずれかのゾーンは完全に利用可能なままになります。

すべてのマスター候補ノード、投票専用ノードを含む、はクラスター状態の更新を公開するための重要な経路にあります。クラスター状態の更新は、通常、インデックス作成や検索などのパフォーマンスに重要なワークロードとは独立していますが、インデックスの作成やロールオーバー、マッピングの更新、障害後の回復などの管理活動には関与しています。これらの活動のパフォーマンス特性は、各マスター候補ノードのストレージの速度、およびクラスター内のすべてのノード間のネットワーク接続の信頼性と遅延の関数です。したがって、クラスター内のノードに利用可能なストレージとネットワーキングが、パフォーマンス目標を満たすのに十分であることを確認する必要があります。

三つ以上のゾーンを持つクラスター

3つのゾーンがある場合、各ゾーンに1つのマスター候補ノードを配置する必要があります。3つ以上のゾーンがある場合は、3つのゾーンを選択し、これらの3つのゾーンのそれぞれにマスター候補ノードを配置する必要があります。これにより、1つのゾーンが失敗してもクラスターはマスターを選出できるようになります。

常に、インデックスにはノードが失敗した場合に備えて少なくとも1つのレプリカが必要です。ただし、検索可能なスナップショットインデックスの場合は除きます。また、シャード割り当ての認識を使用して、各ゾーンにおける各シャードのコピーの数を制限する必要があります。たとえば、1つまたは2つのレプリカが構成されたインデックスがある場合、割り当ての認識により、シャードのレプリカがプライマリとは異なるゾーンに配置されることが保証されます。これにより、1つのゾーンが失敗しても、すべてのシャードのコピーが利用可能なままになります。このシャードの可用性は、そのような障害によって影響を受けません。

まとめ

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

  • クラスターの健康状態green である。
  • データノードを含むゾーンが少なくとも2つある。
  • 検索可能なスナップショットインデックスでないすべてのインデックスには、プライマリに加えて、各シャードの少なくとも1つのレプリカがある。
  • シャード割り当ての認識が構成されており、すべてのシャードのコピーが単一のゾーンに集中しないようにしている。
  • クラスターには、少なくとも3つのマスター候補ノードがある。これらのノードのうち少なくとも2つは投票専用のマスター候補ノードではなく、少なくとも3つのゾーンに均等に分散されている。
  • クライアントは、リクエストを複数のゾーンのノードに送信するように構成されているか、適切なノードセットにリクエストを分散するロードバランサーを使用するように構成されている。 Elastic Cloudサービスは、そのようなロードバランサーを提供します。