私はHadoopとそれがどれほどフォールトトレラントであるかについて読んでいました。HDFSを読み、マスターノードとスレーブノードの障害を処理する方法を読みました。ただし、mapreduceがフォールトトレランスを実行する方法について言及しているドキュメントは見つかりませんでした。特に、ジョブトラッカーを含むマスターノードがダウンしたり、スレーブノードのいずれかがダウンしたりするとどうなりますか?
誰かが私にこれを詳細に説明しているいくつかのリンクと参照を指摘することができれば。
私はHadoopとそれがどれほどフォールトトレラントであるかについて読んでいました。HDFSを読み、マスターノードとスレーブノードの障害を処理する方法を読みました。ただし、mapreduceがフォールトトレランスを実行する方法について言及しているドキュメントは見つかりませんでした。特に、ジョブトラッカーを含むマスターノードがダウンしたり、スレーブノードのいずれかがダウンしたりするとどうなりますか?
誰かが私にこれを詳細に説明しているいくつかのリンクと参照を指摘することができれば。
MapReduce レイヤーの耐障害性は、hadoop のバージョンに依存します。hadoop.0.21 より前のバージョンでは、チェックポイントが実行されず、JobTracker の障害によりデータが失われていました。
ただし、hadoop.0.21 以降のバージョンでは、JobTracker が進行状況をファイルに記録するチェックポイントが追加されました。JobTracker が起動すると、中断したところから作業を再開できるように、そのようなデータが検索されます。
Hadoop でのフォールト トレランス
JobTracker が TaskTracker から一定時間 (デフォルトでは 10 分に設定されています) ハートビートを受信しない場合、JobTracker はその TaskTracker に関連付けられたワーカーに障害が発生したことを認識します。この状況が発生した場合、失敗した TaskTracker に属する中間データが利用できなくなる可能性があるため、JobTracker はすべての保留中および進行中のタスクを別の TaskTracker に再スケジュールする必要があります。
失敗した TaskTracker ファイル システムにある中間結果に reduce タスクがアクセスできない可能性があるため、完了したすべてのマップ タスクが未完了のジョブに属している場合は、再スケジュールする必要もあります。
TaskTracker もブラックリストに登録できます。この場合、ブラックリストに登録された TaskTracker は引き続き JobTracker と通信しますが、対応するワーカーにはタスクが割り当てられません。TaskTracker によって管理される特定のジョブに属する特定の数 (デフォルトでは、この数は 4 に設定されています) のタスクが失敗すると、システムは障害が発生したと見なします。
TaskTracker が JobTracker に送信するハートビート内の関連情報の一部は次のとおりです。 ● TaskTrackerStatus
●再開しました
●初めての心拍の場合
● ノードがさらに多くのタスクを実行する必要がある場合
TaskTrackerStatus には、使用可能な仮想メモリと物理メモリ、CPU に関する情報など、TaskTracker によって管理されるワーカーに関する情報が含まれています。JobTracker は、障害のある TaskTracker と、その TaskTracker から受信した最後のハートビートを含むブラックリストを保持します。そのため、新しい再起動/最初のハートビートを受信すると、JobTracker はこの情報を使用して、TaskTracker を再起動するか、TaskTracker をブラックリストから削除するかを決定できます。
その後、TaskTracker のステータスが JobTracker で更新され、HeartbeatResponse が作成されます。この HeartbeatResponse には、 TaskTracker によって実行される次のアクションが含まれています。実行するタスクがある場合、TaskTracker は新しいタスクを必要とし (これは Heartbeat のパラメーターです)、それがブラックリストにない場合、クリーンアップ タスクとセットアップ タスクが作成されます (クリーンアップ/セットアップ メカニズムはまだ詳しく調査されていません)。 . 実行するクリーンアップまたはセットアップ タスクがない場合、JobTracker は新しいタスクを取得します。タスクが使用可能な場合、LunchTaskAction はそれぞれのタスクにカプセル化され、JobTracker は次のものも検索します。
-殺されるタスク
-殺す/クリーンアップするジョブ
-出力がまだ保存されていないタスク。
このすべてのアクションは、適用される場合、HeartbeatResponse で送信されるアクションのリストに追加されます。Hadoop に実装されているフォールト トレランス メカニズムは、特定の実行が失敗したときにタスクを再割り当てすることに限定されています。この状況では、次の 2 つのシナリオがサポートされます。 1. 特定の TaskTracker に割り当てられたタスクが失敗した場合、Heartbeat を介した通信を使用して JobTracker に通知し、可能であればタスクを別のノードに再割り当てします。2. TaskTracker が失敗した場合、JobTracker は、その TaskTracker からハートビートを受信しないため、障害のある状況に気づきます。次に、JobTracker は、TaskTracker が持っていたタスクを別の TaskTracker に割り当てます。JobTracker にも単一障害点があります。これが失敗すると、実行全体が失敗するためです。
Hadoop に実装されたフォールト トレランスの標準的なアプローチの主な利点は、その単純さとローカル クラスターでうまく機能するように見えることです。タスクの再割り当てで失われた時間は、システムを遅くする可能性があります
マスター ノード (NameNode) は、hadoop の単一障害点です。ダウンすると、システムが使用できなくなります。
スレーブ (計算) ノードの障害は問題なく、障害時に実行されていたものはすべて別のノードで再実行されます。実際、これはノードの動作が遅い場合でも発生する可能性があります。
単一障害点を排除しようとしているプロジェクトや企業がいくつかあります。興味がある場合は、「hadoop ha」(高可用性)をグーグルで検索してください。