ビッグデータ分散調整アーティファクト: 飼育係の選出

[[419551]]

序文

分散システムは、主にデータの一貫性を確保するためにマスタースレーブノードとして設計されています。マスタースレーブ設計は、最も直感的なデータ一貫性保証メカニズムです。

たとえば、マスタースレーブレプリケーションでは、マスターノードが書き込みを担当し、スレーブノードが読み取りを担当するため、読み取りパフォーマンスが向上します。スレーブ ノードはハートビートを通じてマスター ノードと定期的に通信します。マスターノードに障害が発生すると、スレーブノードが直ちにマスターノードのタスクを引き継ぎます。

しかし、瞬間的な過負荷、ネットワークの輻輳などの理由により、マスターノードが一時的に応答を失い、応答タイムアウト期間を超えてしまいます。このとき、スレーブ ノードが起動してリーダーの役割を引き継ぎますが、元のマスター ノードがサービスを再開します。この時点で、選出メカニズムがない場合 (自分自身をリーダーとして宣言するのではなく、他のサーバーまたはクライアントに自分がリーダーであることを知らせるために通知する必要がある)、リーダー ノードが 2 つ存在し、クラスターに混乱が生じる可能性があります。

これがビッグデータ フレームワークのマスター/スレーブ選出の概要です。今すぐ保存してください！うっかり使ってしまう瞬間が必ずあります。

飼育員選挙

Zookeeper の紹介

デザイン パターンの観点から見ると、Zookeeper はオブザーバー パターンに基づいて設計された分散サービス管理フレームワークです。誰もが関心を持つデータを保存および管理し、オブザーバーからの登録を受け入れる役割を担います。このデータのステータスが変更されると、Zookeeper は Zookeeper に登録されているオブザーバーに通知して、それに応じて対応する責任があります。

飼育係の特徴

クラスター内のノードの半分以上が稼働している限り、Zookeeper クラスターは正常にサービスを提供できます。これが選挙メカニズムの奇数原則です (Zookeeper は奇数のサービスをインストールするのに適しています)。

クラスターはリーダーと複数のフォロワーで構成されます。

飼育員選挙の仕組み

新しいクラスター選挙

ID が Service1 から Service5 までの 5 台のサーバーで構成される Zookeeper クラスターがあるとします。同時に、それらはすべて新しく開始されたもの、つまり履歴データがなく、保存されているデータの量の点では同じです。これらのサーバーが順番に起動されると仮定して、何が起こるかを見てみましょう。

1. サーバー 1 が起動し、選挙を開始します。サーバー 1 は自身に投票します。この時点で、サーバー 1 の投票数は 1 で、半数 (3 票) 未満であるため、選挙は完了できず、サーバー 1 のステータスは LOOKING のままになります。
2. サーバー 2 が起動し、別の選挙を開始します。サーバー 1 と 2 はそれぞれに投票し、投票情報を交換します。この時点で、サーバー 1 は、サーバー 2 の ID が現在投票しているサーバー 1 よりも大きいことに気付き、投票を変更してサーバー 2 を指名します。この時点で、サーバー 1 の投票数は 0 で、サーバー 2 の投票数は 2 です。投票数が半数を超えない場合、選挙は完了できず、サーバー 1 と 2 のステータスは LOOKING のままになります。
3. サーバー 3 が起動し、選挙を開始します。この時点で、サーバー 1 と 2 の両方が投票をサーバー 3 に変更します。投票結果は次のとおりです: サーバー 1 は 0 票、サーバー 2 は 0 票、サーバー 3 は 3 票。この時点で、サーバー 3 が投票の半分以上を獲得し、サーバー 3 がリーダーに選出されます。サーバー 1 と 2 のステータスが FOLLOWING に変更され、サーバー 3 のステータスが LEADING に変更されます。
4. サーバー 4 が起動し、選挙を開始します。この時点で、サーバー 1、2、3 は LOOKING 状態ではなくなり、投票情報は変更されません。投票情報の交換結果: サーバー 3 には 3 票、サーバー 4 には 1 票あります。このとき、サーバー4は多数決に従い、投票情報をサーバー3に変更し、ステータスをFOLLOWINGに変更します。
5. サーバー 5 が起動し、手順 4 と同様に動作します。

非フレッシュクラスタ選出

正常に動作している Zookeeper クラスターの場合、マシンがダウンして再選出が必要になった場合、選出プロセスにはデータ ID、サーバー ID、論理クロックが含まれている必要があります。

論理クロック: この値は 0 から始まり、各選択で一貫している必要があります。選挙結果が小さい場合は無視され、投票が再実行されます (選挙時間が不完全なサーバーは除きます)。

データ ID: 新しいバージョンのデータはより大きくなり、データが更新されるたびにバージョンも更新されます。最も大きなデータ ID を持つサーバーが勝ちます (最新のデータを持つサーバーが選択されます)。

サーバー ID: つまり、myid。データ ID が同じ場合、ID が大きいサーバーが勝ちます (データが同じ場合は、ID が最も大きいサーバー、つまり重みが最も大きいサーバーが選択されます)。

Kafka は Zookeeper の選出に依存しています

Kafka は ZK で何を行いますか?

ZooKeeper は、分散システムの調整サービスを提供するツールとして Kafka によって使用されています。分散システムでは、コンシューマーはどのプロデューサーが利用可能かを知る必要があります。消費者が生産者との接続を確立し、その接続が成功するかどうかを毎回テストする必要がある場合、効率が低すぎて望ましくないのは明らかです。 ZooKeeper コーディネーション サービスを使用することで、Kafka はプロデューサー、コンシューマー、ブローカーなどを組み合わせることができます。同時に、ZooKeeper の助けを借りて、Kafka はステートレスな条件下ですべてのコンポーネントのプロデューサーとコンシューマー間のサブスクリプション関係を確立し、負荷分散を実現できます。

カフカ選挙

リーダーは、動的な同期レプリカ セット (ISR) を維持します。これは、リーダーと同期されているフォロワーのセットを意味します。 ISR 内のフォロワーがデータ同期を完了すると、リーダーはフォロワーに ack を送信します。フォロワーが長時間リーダーとデータを同期できない場合、フォロワーは ISR から追い出されます。時間のしきい値は、replica.lag.time.max.ms パラメータによって設定されます。リーダーが失敗すると、ISR から新しいリーダーが選出されます。

したがって、このセット内の任意のノードはいつでもリーダーとして選出される可能性があります。 ISR は ZooKeeper で管理されます。 ISR には f+1 個のノード (フォロー + リーダー) があり、これにより f 個のノードがダウンしてもメッセージを失うことなくサーバーは正常にサービスを提供できます。 ISR のメンバーシップは動的です。ノードが削除された場合、そのノードは再び「同期」状態に達すると ISR に再参加できます。したがって、リーダーがダウンした場合は、ISR からフォロワーを選択するだけです。

全員が吊り下げられたらどうなるでしょうか?

すべてのノードがダウンすると、Kafka はデータが失われないことを保証しません。したがって、すべてのレプリカがダウンした場合は、タイムリーに対応する必要があります。 ISR 内のいずれかのノードが回復し、リーダーとして機能するまで待機します。

付録: Kafka が ZK を放棄すべき理由

それ自体は分散システムですが、それを管理するには別の分散システムが必要であり、間違いなく複雑さが増します。

導入時には 2 つのシステムを導入する必要があり、運用および保守担当者は運用および保守能力を備えている必要があります。

コントローラーの障害処理: 単一のノードとの対話に依存します。このノードに障害が発生した場合は、新しいノードを選択する必要があります。新しい選択が成功すると、メタデータは初期化のために再度取得され、他のすべての更新を通知する必要があります。古いものは、リスナー、イベント処理スレッド、およびスケジュールされたタスクをシャットダウンする必要があります。パーティションの数が非常に多い場合、このプロセスには非常に時間がかかり、このプロセス中にクラスターは動作できません。

パーティションの数が増えると、保存されるメタデータが増え、クラスターの負荷が増加します。

ZooKeeper に基づく Hadoop の高可用性

HDFS 高可用性

導入

一般的な HA クラスターでは、NameNode は 2 台の独立したマシン上に構成されます。いつでも、1 つの NameNode がアクティブ状態になり、もう 1 つの NameNode がバックアップ状態になります。アクティブな NameNode はクラスター内のすべてのクライアントに応答し、バックアップ NameNode は必要に応じて高速転送を確保するためのレプリカとしてのみ機能します。したがって、HDFS の場合、高可用性は実際には NameNode の高可用性を指します。 NameNode はクラスターのメタデータ情報を保存するため、これが失われるとクラスター全体が存在しなくなります。

アクティブ/スタンバイ切り替えコントローラ ZKFailoverController: ZKFC は独立したプロセスとして実行され、NameNode のアクティブ/スタンバイ切り替えの全体的な制御を実行します。 ZKFailoverController は、NameNode のヘルス ステータスを適時に検出し、マスター NameNode に障害が発生した場合に Zookeeper を使用して自動マスター/スレーブ選択と切り替えを実装します。もちろん、NameNode は現在、Zookeeper に依存しない手動のマスター/スレーブ切り替えもサポートしています。

原理

HDFS の 2 つの NN が起動すると、ZKFC (Zookeeper FailoverController) も起動します。 ZKFC は、一時的にシリアル化されたノードを ZK に書き込み (デフォルトのノード名は /hadoop-ha)、ZK との接続を取得します。 NN に障害が発生すると、ZKFC にも障害が発生し、ノードは ZK によって自動的に削除されます。 ZKFC にはウォッチャー メカニズム (子ノードが変更されたときにトリガーされる) があります。 NN で開始された別の ZKFC は、子ノードが変更されたことを検出し、それが 1 位にランクされているかどうかを確認します。そうであれば、2 番目の NN に引き継ぎを開始するように通知し、データを JN に同期し (IDS ファイルをダウンロードして FImage とマージし、新しい FImage を生成)、すべてのメタデータを最新のものにします。障害が発生した NN が再起動されると、ZKFC も ZK にノードを書き込み、現在の NN に障害が発生した後にマスターとして引き継ぎます。

ZKFCとは何ですか？

• ZKFC は Zookeeper クライアントであり、主に NameNode のステータスを監視および管理するために使用されます。 ZKFC プログラムは各 NameNode マシン上で実行されます。その主な責任は、第一に健康監視です。 ZKFC は NameNode に断続的に ping を送信し、NameNode から返されるステータスを取得します。 NameNode に障害が発生したり、異常な状態になったりすると、ZKFS はそれを異常としてマークします。
• Zookeeper セッション管理。ローカル NaneNode が正常に動作している場合、ZKFC は Zookeeper セッションを保持します。ローカル NameNode がアクティブな場合は、「排他ロック」znode も保持されます。セッションの有効期限が切れると、ロックに対応する znode も削除されます。
• 選挙。クラスター内の NameNode の 1 つがダウンすると、Zookeeper は自動的にもう 1 つをアクティブ化します。

内部操作と原理

HealthMonitor は初期化された後、内部スレッドを開始し、NameNode に対応する HAServiceProtocol RPC インターフェースのメソッドを定期的に呼び出して、NameNode のヘルス状態を検出します。

HealthMonitor は、NameNode のヘルス ステータスが変化したことを検出すると、処理のために ZKFailoverController によって登録された対応するメソッドをコールバックします。

ZKFailoverController は、アクティブ/スタンバイの切り替えが必要であると判断した場合、まず ActiveStandbyElector を使用してアクティブ/スタンバイ ノードを自動的に選択します。

ActiveStandbyElector は Zookeeper と対話して、自動マスター/スレーブ選択を完了します。

マスター/スレーブの選出が完了すると、ActiveStandbyElector は ZKFailoverController の対応するメソッドをコールバックして、現在の NameNode がマスター NameNode またはスタンバイ NameNode になるように通知します。

ZKFailoverController は、対応する NameNode の HAServiceProtocol RPC インターフェースのメソッドを呼び出して、NameNode をアクティブ状態またはスタンバイ状態に変換します。

簡単に説明すると、ZooKeeper はアクティブ ノードの選択を実装するためのシンプルなメカニズムを提供します。現在のアクティブに障害が発生した場合、スタンバイは特定の排他ロックを取得し、ロックを取得したノードが次にアクティブになります。

Yarn の高可用性

導入

YARN ResourceManager の高可用性は HDFS NameNode と似ていますが、NameNode とは異なり、ResourceManager には維持するメタデータ情報がそれほど多くないため、そのステータス情報は Zookeeper に直接書き込まれ、マスター/スレーブの選択は Zookeeper に依存できます。

内部操作と原理

1. ZooKeeper にはロック ノード /yarn-leader-election/yarn1 が存在します。すべての ResourceManager が起動されると、それらは Lock 子ノード (一時ノードである /yarn-leader-election/yarn1/ActiveBreadCrumb) への書き込みを競います。 ZooKeeper では、ResourceManager が 1 つだけ正常に作成されるようにすることができます。正常に作成された ResourceManager はアクティブ状態に切り替わり、正常に作成されなかった ResourceManager はスタンバイ状態に切り替わります。
2. RM はジョブ情報を Zookeeper の /rmstore ディレクトリに保存し、アクティブ RM はアプリ情報をこのディレクトリに書き込みます。アクティブ RM がハングアップすると、スタンバイ RM は zkfc を介してアクティブ状態に切り替わり、zookeeper の /rmstore ディレクトリから対応するジョブ情報を読み取ります。ジョブのメモリ情報を再構築し、内部サービスを開始し、NM ハートビート情報の受信を開始し、クラスター リソース情報を構築し、クライアントのジョブ送信要求を受け入れます。

その他と概要

ビッグデータの分野では、Hbase クラスター、Kudu クラスター、Impala クラスターなど、マスターとスレーブの選択に Zookeeper を利用するフレームワークが多数あります。基本的な原理は基本的に同じです。

要約する

選挙: Zookeeper はクラスター管理機能を簡単に実装できます。複数のサーバーがサービス クラスターを形成する場合、リーダーはクラスター内の各マシンのサービス ステータスを把握し、調整を行ってサービス戦略を再配布する必要があります。 1 つ以上のサーバーがクラスターに追加される場合、リーダーもそれを知る必要があります。 Zookeeper は、現在のクラスター内のマシンのサービス ステータスを維持できるだけでなく、クラスターを管理するリーダーを選択することもできます。

HA (分散ロックの適用): マスターに障害が発生すると、すぐにスレーブ ノードに切り替わります。