分散システムにおける「スプリットブレイン」とは一体何でしょうか?

[[413929]]

この記事はWeChatの公開アカウント「New Vision of Programming」から転載したもので、著者はUgly Fat Man Second Brotherです。記事の転載については、Program New Visionの公式アカウントまでご連絡ください。

現在、ほとんどのプロジェクトは配布に向けて動いています。システムが分散システムを採用すると、より複雑なシナリオとソリューションが導入されるようになります。たとえば、システムで Elasticsearch と ZooKeeper のクラスターを使用する場合、クラスターの「スプリット ブレイン」現象を理解したことがありますか?スプリットブレイン問題をどのように解決するか知っていますか?

これらすべてを理解していない場合、配布についての理解は表面的すぎます。この記事を読むことをお勧めします。

ZooKeeper を例に、分散システムにおけるスプリットブレイン現象を解決する方法を説明します。

スプリットブレインとは何ですか?

Elasticsearch や ZooKeeper などのクラスター環境には、共通の特徴として「頭脳」があることが挙げられます。たとえば、Elasticsearch クラスターにはマスターノードがあり、ZooKeeper クラスターにはリーダーノードがあります。

クラスター内のマスター ノードまたはリーダー ノードが頻繁に選出されます。ネットワークが正常な場合は、スムーズにリーダーを選出することができます（以下ではZookeeperを例に説明します）。ただし、2 つのコンピュータ ルーム間のネットワーク通信が失敗すると、選出メカニズムによって異なるネットワーク パーティション内の 2 人のリーダーが選択される場合があります。ネットワークが復旧したら、2 人のリーダーはデータの同期をどのように処理すればよいでしょうか?誰の言うことを聞くべきでしょうか?このようにして「スプリット ブレイン」現象が発生します。

簡単に言えば、スプリットブレインとは「脳の分割」を意味し、1 つの「脳」が 2 つ以上に分割されます。想像してみてください。もし人間が複数の脳を持ち、それらが互いに独立していたら、体は「踊り回り」、そして「制御不能」になるでしょう。

スプリットブレインの基本概念を理解したところで、Zookeeper クラスターのシナリオを例に、スプリットブレインの発生を分析してみましょう。

Zookeeper クラスタのスプリット ブレイン

Zookeeper を使用すると、スプリット ブレインの発生を軽減または回避するための適切な対策が講じられているため、スプリット ブレイン現象が発生することはほとんどありません。 Zookeeper の具体的なソリューションについては後ほど説明します。ここで、ZooKeeper がスプリットブレインを防ぐためにこれらの対策を講じていないと仮定しましょう。この場合、スプリットブレイン問題がどのように発生するかを確認します。

現在、2 つのコンピュータ ルームに展開され、クラスターを形成する 6 つの zkServer サービスがあります。

スプリットブレイン

通常の状況では、クラスターにはリーダーが 1 つだけ存在します。リーダーが失敗した場合、他の 5 つのサービスが新しいリーダーを再選出します。

コンピュータ ルーム 1 とコンピュータ ルーム 2 間のネットワークに障害が発生し、Zookeeper の多数決メカニズムが当面考慮されない場合、次の状況が発生します。

スプリットブレイン

つまり、コンピュータ ルーム 2 の 3 つのサービスはリーダーがいないことを検出し、新しいリーダーの再選出を開始しました。元のクラスターは 2 つのクラスターに分割され、2 つの「脳」が同時に出現しました。これはいわゆる「スプリットブレイン」現象です。

元々 1 つのクラスターが 2 つになったため、両方が外部にサービスを提供します。しばらくすると、2 つのクラスター間のデータが不整合になる可能性があります。ネットワークが復旧すると、誰がリーダーになるのか、データをどのようにマージするのか、データの競合をどのように解決するのかといった問題に直面します。

もちろん、上記のプロセスは、Zookeeper がブレイン スプリットを防止するための対策を講じていないと仮定した場合に発生する問題にすぎません。では、Zookeeper はスプリットブレイン問題をどのように処理するのでしょうか?

動物園飼育員の多数決

ブレインスプリットを防ぐための対策は数多くありますが、Zookeeper ではデフォルトで「多数決原理」を採用しています。いわゆる多数決ルールとは、リーダー選出プロセス中に、zkServer が過半数の票を獲得した場合、その zkServer がリーダーになることができることを意味します。

基礎となるソースコードは次のように実装されています。

パブリッククラスQuorumMajはQuorumVerifierを実装します{ 
  
整数半分; 
     
    // QuorumMaj 構築メソッド。
    // パラメータ n は、オブザーバーノードを除くクラスター内の zkServer の数を表します。
パブリックQuorumMaj( int n){
        this.half = n/2;
    } 
 
    // 多数決メカニズムが満たされているかどうかを確認する
パブリックブール値 containsQuorum( Set <Long> set ){
        // 半分はコンストラクタで割り当てられます
        //セット。 size ()はzkServerが獲得した投票数を示す
戻り値( set . size () > half);
    }
 }

上記のコードは、QuorumMaj オブジェクトを構築するときに、クラスター内の有効なノードの数を渡します。 containsQuorum メソッドは、zkServer が投票の半分以上を獲得したかどうかを判断する方法を提供します。ここで、set.size は zkServer が獲得した投票数を表します。

上記のコードには 2 つの核となるポイントがあります。1 つ目は、半分を計算する方法です。 2番目は、どの票が半分に属するかの比較です。

上図の 6 台のサーバーを例に挙げると、半分 = 6 / 2 = 3 となり、選挙が成功するには、選挙中に少なくとも 4 台のマシンがリーダーになるために投票する必要があることを意味します。そして、上記 2 つのコンピュータ ルームでインターネットが切断された場合、コンピュータ ルーム 1 とコンピュータ ルーム 2 にはサーバーが 3 台しかないため、リーダーを選出することができません。この場合、クラスター全体にリーダーは存在しません。

スプリットブレイン

リーダーがいない場合、Zookeeper は外部サービスを提供できなくなるため、クラスターを設計および構築する際には、このような状況を避ける必要があります。

2 つのコンピュータ ルームの展開要求が 3:3 ではなく 3:2、つまりコンピュータ ルーム 1 に 3 台のサーバー、コンピュータ ルーム 2 に 2 台のサーバーがある場合:

上記の場合、まず半分 = 5 / 2 = 2 を計算します。これは、リーダーを選出するには 2 台以上のマシンが必要であることを意味します。この時点で、コンピュータ ルーム 1 のリーダーは通常どおり選出できます。コンピュータ ルーム 2 の場合、サーバーが 2 台しかないため、リーダーを選出することはできません。現時点では、クラスター全体にリーダーは 1 つだけ存在します。

上の図は、逆の場合も同様です。たとえば、コンピュータ ルーム 1 にサーバーが 2 台しかなく、コンピュータ ルーム 2 にサーバーが 3 台しかない場合、ネットワークが切断されると、選出状況は次のようになります。

Zookeeper クラスターは多数決メカニズムを使用して、リーダーをゼロにするか、リーダーを 1 人のみにすることで、スプリット ブレイン問題を回避します。

多数決メカニズムは、スプリットブレインを防止するだけでなく、高速な選挙も実現できます。多数決メカニズムは、すべての zkServer が同じ zkServer に投票するのを待たずにリーダーを選出できるため、高速リーダー選出アルゴリズムとも呼ばれます。

新旧リーダー間の競争

多数決ルールは、コンピュータ室を分割することによって発生するスプリットブレイン現象を防ぐことができますが、リーダーが停止される別の状況もあります。

リーダーが亡くなり、残ったフォロワーが新しいリーダーを選出するとします。この時点で、古いリーダーが復活し、依然として自分自身をリーダーとみなし、他のフォロワーへの書き込みリクエストも拒否されます。

ZooKeeper は epoch と呼ばれる変数を保持しているため、新しいリーダーが生成されるたびに、エポック番号 (そのリーダーの現在の統治期間を示す) が生成され、エポックが増加します。フォロワーが新しいリーダーの存在を確認し、そのエポックを知っている場合、フォロワーは現在のリーダーのエポックよりも小さいエポックのすべてのリクエストを拒否します。

新しいリーダーの存在を知らないフォロワーはいますか？それは可能ですが、絶対に過半数ではありません。そうでないと、新しいリーダーを生成できません。 ZooKeeper の書き込みもクォーラム メカニズムに従います。したがって、過半数の支持を得ていない書き込みは無効です。たとえ古いリーダーが自分をリーダーだと思っていても、それはまだ役に立たない。

ZooKeeper クラスター ノードを奇数でデプロイする必要があるのはなぜですか?

多数決原理については上で説明しました。 Zookeeper はデフォルトでこの戦略を採用するため、別の問題が発生します。適切なクラスターの数はいくつですか?私たちが目にする Zookeeper ノードの数は、通常、奇数です。何故ですか？

まず、クラスター内のマシンの半分以上が正常に機能している限り、クラスター全体が外部サービスを提供できます。いくつかの状況を見て、その状況におけるクラスターのフォールト トレランスを確認してみましょう。

ノードが 2 つある場合、1 つのノードに障害が発生するとクラスターは使用できなくなります。この時点で、クラスター ペアの許容値は 0 です。

ノードが 3 つある場合、1 つのノードに障害が発生しても、まだ半分以上の 2 つの正常なノードが残っているので、新しい選挙を実行して通常のサービスを提供することができます。この時点で、クラスターの許容値は 1 です。

ノードが 4 つある場合、1 つのノードに障害が発生すると、半分以上の 3 つのノードが残り、新しい選挙を行うことができます。しかし、あと1つが失敗して残り2つになった場合、選挙や礼拝は正常に進行できなくなります。この時点で、クラスターの許容値は 1 です。

同様に、5 つのノードの場合、許容値は 2 になります。 6 ノードの場合、許容値も 2 になります。

3ノードと4ノード、5ノードと6ノード、つまり2nと2n-1の許容値は同じなので、すべてn-1です。したがって、リソースを節約し、効率を高めるために（より多くのノードが選挙と通信に参加する）、ノードをもう 1 つ追加してみてはいかがでしょうか。このため、クラスターは奇数で展開する必要があります。

スプリットブレインを解決する一般的な方法

Zookeeper が使用する多数決ルールについては上記で説明しました。ここでは、スプリットブレイン問題を解決するためのシナリオ手法をまとめます。

方法 1: クォーラム

たとえば、3 つのノードのクラスターの場合、Quorums = 2 となり、クラスターは 1 つのノードの障害を許容できることを意味します。この時点では、リーダーを選出することができ、クラスターを引き続き使用することができます。たとえば、4 つのノードのクラスターの場合、クォーラムは 3 です。クォーラムは 3 より大きくする必要があります。つまり、クラスターの許容値は 1 のままです。2 つのノードに障害が発生すると、クラスター全体が無効になります。これは、ZooKeeper が「スプリット ブレイン」を防ぐために使用するデフォルトの方法です。

方法2: ハートビートラインを追加する

クラスターでは複数の通信方法を使用して、1 つの通信方法の障害によりクラスター内のノードが通信できなくなるのを防ぎます。

たとえば、ハートビートのラインを追加します。心拍線は 1 本しかないことがわかりました。このとき切断されるとハートビートレポートを受信できず、相手が死亡していると判断されます。ハートビート ラインが 2 つあり、1 つが切断された場合でも、もう 1 つはハートビート レポートを受信できるため、クラスター サービスの正常な動作が保証されます。ハートビート ラインは HA (高可用性) にもなり、2 つのハートビート ラインは互いを検出できます。一方が切断されると、もう一方は直ちに有効になります。通常の状況では動作せず、リソースを節約します。

方法 3: ディスク ロック モードを開始します。

ディスク ロックを使用すると、データの混乱を避けるために、クラスター内の 1 つのリーダーだけがディスク ロックを取得して外部にサービスを提供できるようになります。しかし、問題もあります。リーダー ノードがダウンすると、ロックを積極的に解放することができなくなり、他のフォロワーは共有リソースを取得できなくなります。そこで誰かが HA で「スマート」ロックを設計しました。サービス側は、すべてのハートビート ラインが切断されている (相手側は認識しない) ことがわかった場合にのみ、ディスク ロックを有効にします。通常はロックされていません。

方法4: 仲裁メカニズム。

スプリット ブレインの結果、スレーブ ノードはどのリーダーに接続すればよいか分からなくなります。この時点で、仲裁人がこの問題を解決することができます。たとえば、参照 IP アドレスが提供されます。ハートビート メカニズムが切断されると、ノードはそれぞれ参照 IP アドレスに ping を実行します。 ping が失敗した場合は、ノード ネットワークに問題があることを意味します。この場合、ノードはリソース競争から撤退し、占有している共有リソースを解放し、より包括的な機能を持つノードにサービス提供機能を付与する必要があります。

上記の方法を同時に使用してクラスター内のスプリットブレインの発生を減らすことはできますが、保証されるものではありません。たとえば、調停メカニズム内の 2 台のマシンが同時に故障した場合、クラスター内で使用できるリーダーは存在しなくなります。この時点では人間の介入が必要になります。

まとめ

私たちのシステムは分散を使用しているとよく言われますが、分散シナリオにおけるいくつかのシナリオとソリューションを本当に理解しているでしょうか?この記事のスプリットブレインシナリオの分析と解決策の紹介から学びましたか?一緒に学びましょう。