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

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

[[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 がリーダーになることができることを意味します。

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

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

上記のコードは、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 台のマシンが同時に故障した場合、クラスター内で使用できるリーダーは存在しなくなります。この時点では人間の介入が必要になります。

まとめ

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

<<:  JVM における TLAB の謎を解明

>>:  分散調整フレームワークZookeeperのコア設計の理解と実践

推薦する

推奨: m247-4 Euro/Xen/256M メモリ/10G ハードドライブ/G ポート無制限/ルーマニア

m247 は 2001 年に設立され、ISO 9001:2008 品質管理システムと ISO2700...

Googleの無料広告入札料を使ってTaobaoを宣伝する方法を紹介

グーグルは今年の元旦から、新規入札ユーザーに350元相当の広告料を無料にする活動を開始した。つまり、...

Sonicvps 米国西海岸 低価格 KVM

Sonicvpsは2009年に設立されたVPS事業者です。簡単に言うと、中国人が運営しています。以前...

360 はデフォルトブラウザの改ざんの報告に応答: ユーザーの選択肢を尊重

9月20日夜、奇虎360は、360ソフトウェアがユーザーのデフォルトブラウザを改ざんしているというメ...

hosteons: ハロウィーン、すべての VPS が 50% オフ、無制限のトラフィック、無料のセキュリティ、Windows 付き

Hosteons のハロウィン プロモーションが始まりました。今から 11 月 1 日まで、Host...

Kubernetes 7周年記念:K8s の導入とアプリケーションの簡素化における VMware の成果と課題

コンテナベースの分散管理システムである Kubernetes は 7 年間の開発期間を経て、そのエコ...

Baidu Webmaster Tools クロール診断ツールの実践分析

Google 最適化を行う友人は、Google ウェブマスター ツールをよく知っているはずです。Go...

分散ネットワーク全体の内部脅威を表示して対処する

ハッカー、サイバー犯罪者、マルウェア感染、その他の外部からの脅威がニュースの見出しを賑わせています。...

大型模型で古い香港映画を復元:Volcano EngineとTikTokが共同で「クラシック香港映画復元プロジェクト」を開始

8月16日、TikTok、中国電影資料館、Volcano Engineは北京で「継続する時間-香港ク...

VMware Explore 2022 は、中国企業のクラウド インテリジェンスの加速を支援するマルチクラウド ソリューションをリリースします。

企業のデジタル変革が深まり続けるにつれて、マルチクラウド アーキテクチャがほとんどの企業の選択肢とな...

コンテンツはSEOの魂

著者は2010年末からSEOに携わり、現在はインターネット企業でSEOスーパーバイザーとして働いてい...

ゲーミフィケーションの考え方を使って製品を作ると、人気が出ないということはまずないでしょう

現代はユーザーとトラフィックが王様の時代です。トラフィックの入り口をコントロールし、より多くのユーザ...

編集者注: AdWords コンバージョン トラッキングのヒント

温州ウェブサイト構築の編集者は対外貿易SEOとの関わりがほとんどなく、主に国内SEOを行っていますが...

クラウドにおける完璧な組み合わせ: コンテナと DevOps

企業が継続的デリバリー アプローチの実装や、ソフトウェア開発プラクティスへのクラウド コンピューティ...

新しいアルゴリズム:オリジナルコンテンツが人気に。独創性のボトルネックをどう打破するか?

Baidu アルゴリズムが Pomegranate にアップグレードされて以来、オリジナルの Mar...