入門
名前ノードのノードのメモリのオーバーフローが発生した後、我々は、この名前ノードのノードを再起動するまで、ダウンタイムやその他の不測の事態は、システム全体がサービス外となりますHDFSフレームワークのHadoop 1.xでのみ名前ノードノードは、あります。この問題を解決するために、hadoop2.x HDFSの枠組みの中で、HAを実装するメカニズムは、のは2.xでこのメカニズムは、システムの高可用性を確保することである方法を見てみましょう。
アーキテクチャ
1.1はので、それは、長期的に名前ノード保証することはできません唯一のシステムであり、最初のキーポイントは、名前ノードがサービスを提供するために、他の名前ノードの上に、ハングアップした後にさらにいくつかのこのシステムの名前ノードのノードを追加することですが、より多くあり名前ノードは、非常に高い可用性アーキテクチャ2.xのHDFS、そして2つだけの名前ノードのノード（アクティブおよびスタンバイ）を備え、システムの複雑さを増加させるであろう。システムは、このように、彼らは保存データの一貫性を確保し、地元fsimageファイルをマージし、スタンバイノードが編集ファイルを同期させる責任がある、唯一のアクティブ・ノードにのみサービスを提供し、実行されています。
共有メモリ
しかし、また問題に直面同期編集ファイルでは、それは、周波数同期の設定を変更するには、ファイルを編集する方法、ありますか？あなたはそれぞれのアクティブのためにファイルを挿入した場合、スタンバイは、データを同期させるために、システムのパフォーマンスは、多くのことをドロップします必要であり、一定の時間間隔が編集ファイルを同期する場合、システムは、データを失うリスクであってもよく、したがって、第二キーポイントはデザインがファイル共有システムを編集することができ、アクティブノードは、このファイルシステムの書き込みデータを編集する責任があるということです、スタンバイノードは、このファイルシステム編集を同期させる責任があります。
このシステムを格納ファイルを編集し、私たちは、このシステムは非常に利用可能であることを確認する必要があるため、Hadoopの2つのプログラムを提供しています- QJM（クォーラムジャーナルマネージャ）とNFS、私はQJMに焦点を当てますが、あなたは少しNFSを知りたいですパートナーは見ることができ、このブログ。2N + 1番目のノードを含むQJMジャーナル、各ノードは、データを読み書き名前ノードせる、単純なジャーナルRPCインターフェースを提供します。名前ノードの編集ファイルを書き込むとき、それが成功しているクライアントに代わって書かれている、N + 1のノードが正常に書き込まれた場合にのみ、クラスタ内のジャーナルノードへの書き込み要求を送信します。
スプリットブレイン
今のシステムのより多くの明確なアーキテクチャは、2つの名前ノードノードは、共有ファイルシステムを編集し、データは、システムは、長い時間を果たすように見えるかもしれないが、問題はまだある、ファイルアクティブノード、待機ノード同期編集を書かれています。ネットワークノードの動作中に活性が破壊されたシナリオを検討し、システムが誤っことサービスは、アクティブノードにスタンバイノードを変換すると考えすることができません。しかし、回復する前に、ネットワーク内のアクティブノードがまだそこシステムが動作中に2つのノードが名前ノード、サービスを提供することができた後は、さまざまな問題となり、この状態は、スプリットブレインと呼ばれています。これは、HAのメカニズムである3番目のキーポイント -スプリットブレインの問題発生を防ぐ方法。
QJMでは、分割は、いくつかのエポックを通じて脳の問題を解決することです。名前ノードがアクティブ状態になったときに、エポックの数に割り当てされ、この番号はユニークであり、そして前に保持された全てのエポックの名前ノードの数よりも大きいです。名前ノードのジャーナルにメッセージを送信するときは、この番号をもたらすでしょう。ジャーナル・ノードメッセージを受信したとき、このエポックは、要求を処理したり、要求を拒否しますローカルに格納されopochの数よりも大きい場合にのみ。
なぜなら、この名前ノードのepchoの数だけ、クラスタの通信名前ノードとジャーナルノードを切断しますが、クライアントはまだすることができ、これ名前ノードの通信は、できないとジャーナルノード間通信、したがってないシステムにクライアントを引き起こすことになる、クライアントの要求を処理できないことにより、アクティブノードにスタンバイノードは、システムが一つだけアクティブな名前ノードを持っていることを確認して、マシン上の別の名前ノードのプロセスを殺すためにsshの方法を介してコマンドを送信すると、オンラインでの操作、この問題を解決するために、HDFSは、フェンシングのメカニズムを提供しますノードは、これはスプリットブレインの問題を解決するだろう、存在しています。
フェイルオーバー
上記の内容は名前ノード当社のソリューションサービスを提供しない場合はの話ですが、私たちは名前ノードがハングアップするかどうかを検出し、どのようにstangdyノード、アクティブノードにどのように言及しませんでした。これは、HAのメカニズムである第四の重要なポイントとどのようにフェイルオーバー- 。
次のセクションでは、参照https://blog.csdn.net/Androidlushangderen/article/details/53148213
名前ノードハングアップするかどうかをテストするには、HDFSは、ホスト名として、この意志のznodeでアクティブnodenode情報の現在の数を維持するために、名前ノードが正常にアクティブ状態に切り替えられたときに、それは飼育係内の一時のznodeを作成し、飼育係を導入しましたように。障害がアクティブなのでの場合に発生すると、一時的なのznodeは、対応する監視プログラムを削除するのznodeの削除は、自動的に次のアクティブな名前ノードの選択にイベントをトリガーする、飼育係ます。
問題のフェイルオーバーを解決するために、HDFSは、このプロセスでは、内部ZKFCプロセス我々は、通常、名前ノードのノード上で開始されたコアオブジェクトHDFS HA自動切替、あるZKFC（ZKFailoverController）成分を導入し、これら3つのサービスオブジェクトを実行します：
- HealthMonitor：名前ノードを監視することが使用できないか、不健康な状態にあります
- ActiveStandbyElector：ノードのステータスZKの制御と監視
- ZKFailoverController：コーディネーションHealMonitorとActiverStandbyElectorオブジェクト、イベント処理は、処理を完了し、自動的に切り替え、イベントの変化に送信されます。
HealthMonitorは、その現在の名前ノードが不健康検出した場合、ZKFailoverControllerはそのように彼らの一時的な撤退アクティブ状態でquitElectionメソッドActiveStandbyElectorを呼び出し、健康の名前ノードの状態ならば、joinElectionでActiveStandbyElectorは選挙の名前ノードに参加するために呼び出されます。これはおおよそフェイルオーバ処理、上記の記事を参照することができるソースコードの詳細な分析です。
HDFSの4つのキーポイントが解決された後、我々はまた、HA完全に理解するためのメカニズムを持って、その全体的なアーキテクチャ図の下に与えられます：
上記は、エラーがある場合は、指摘してくださいHDFS HAメカニズムの私の要約です！