Hadoop本読書会 - 10章 Hadoopの管理編集する

最終更新：ID:oTc6wz6Jsg 2010年11月14日(日) 14:30:04履歴

Hadoop本 10章 Hadoopの管理 の疑問点や気になる点について記述してください。
※記入者、該当ページ・該当行は忘れずに書いて下さい。

ネームノードのディレクトリ・ファイル構成

  • [記入者] terurou
  • [該当箇所] 295〜296ページ（10.1.1.1 ネームノードのディレクトリ構造）
ディレクトリファイル説明
${dfs.name.dir}/current/VERSION実行中のHDFSのバージョンに関する情報を保存
edits編集ログ、HDFSへの操作が記録される（バイナリデータ）
fsimageメタデータの永続的なチェックポイント（バイナリデータ）
fstimeチェックポイント時刻情報（バイナリデータ）
  • edits, fsimage, fstimeはネームノードを再起動する際に、メモリ上にメタデータを復元するために利用される

チェックポイント、編集ログ、セカンダリネームノード

  • [記入者] terurou
  • [該当箇所] 297ページ（10.1.1.2 ファイルシステムのイメージと編集ログ）
  • ネームノード再起動時のメタデータ復元シーケンス（詳細なシーケンスは10.1.2に記載あり）
    1. fsimageを読み込み、メモリ上に展開
    2. editsを読み込み、記録されている順序で各操作を適用していく
  • HDFSを運用していると、editsファイルは上限なしに肥大化していく
    • ネームノード再起動時にHDFSがオンラインになるまでの待ち時間が増加してしまう
      • それを防ぐためにセカンダリネームノードは適時editsをfsimageをマージし、fstimeを更新する（図10-1）
      • 大規模クラスタでセカンダリネームノードが必要となるのはこのため

チェックポイント作成処理の副作用

  • [記入者] terurou
  • [該当箇所] 298〜299ページ（10.1.1.3 セカンダリネームノードのディレクトリ構造）
  • ${fs.checkpoint.dir}/previous.checkpoint にはネームノードのメタデータの古いデータが保存される
    • これはメタデータのバックアップとして利用できる
    • ネームノードのメタデータ、NFSへのバックアップが破損・消失してしまった場合に利用できる
  • このデータを使って、セカンダリネームノードをネームノードに昇格させることもできる
    • デーモン起動時に-importCheckpointオプションをつける

データノードのディレクトリ構造

  • [記入者] terurou
  • [該当箇所] 315ページ（10.1.1.4 データノードのディレクトリ構造）
ディレクトリファイル説明
${dfs.name.dir}/current/VERSION実行中のHDFSのバージョンに関する情報を保存
blk_<id_1>HDFSブロックデータ
blk_<id_1>.metaブロックのためのメタデータ
blk_<id_2>
blk_<id_2>.meta
...
blk_<id_64>
blk_<id_64>.meta
subdir0/サブディレクトリ
subdir1/
...
subdir63/
  • 1つのディレクトリの上限ブロック数はデフォルト64、サブディレクトリも64
  • ブロック数が上限を超えた場合、サブディレクトリを作成し、次のブロックからはそこに保存する
  • ディレクトリ数も64になった場合、subdir0-63の下に同じファイル構成でブロックを作成していく
  • わざわざこんな処理にしているのは、多くのOS（ファイルシステム）で1つのディレクトリに大量のファイルが存在する場合、ディスクI/Oが劣化する問題が存在するため

ネームノードの再起動シーケンス、セーフモード

  • [記入者] terurou
  • [該当箇所] 300-301ページ（10.1.2 セーフモード）
  1. fsimageをメモリに読み込む
  2. editsの操作を適用
  3. 新しいfsimageと空のeditsを作成しなおす
  4. RPCサーバ起動（ただしセーフモードが有効）
  5. データノードからのブロック位置情報のチェックインを受け付ける
  6. 最小複製状態になったら、30秒後（dfs.safemode.extension設定値）にセーフモードを解除する

セーフモード、最小複製状態？

  • [記入者] terurou, masa_cbl追記
  • [該当箇所] 300-301ページ（10.1.2 セーフモード）
  • 解説が難解・・・。理解が間違ってるかも。
  • セーフモードが有効になっている間、クライアント側から見てHDFSはread-only
  • 最小複製状態
    • 最小レプリカ作成数（dfs.replication.min、デフォルト1）に達するレプリカが作成済みのブロックの割合が規定値（dfs.safemode.threathold.pct、デフォルト99.9%）に達しているか？
    • 最小複製状態に達するまでは、「データノードがまだレプリカを作成中である」と判断する
    • 最小複製状態に達するまでは、「ネームノードがデータノードからブロック情報を収集中である」と判断する。
    • ネームノード起動直後のブロック情報が断片的にしか得られていない状態でデータのレプリカ複製の処理をしてしまうと、全てのブロック情報収集完了時には不要になるレプリカを作成してしまう可能性がある。これを防ぐために起動後しばらくはセーフモードになる。
    • Hadoop本読書会 - 3章 Hadoop分散ファイルシステムのdfs.replicationについての議論も参照
  • セーフモードが終了した後、不足しているレプリカを作成する
  • セーフモード終了後はデータの書込、削除等の処理が可能となる。
  • （以下Hadoop本に記述はないが追記）
    • (1-dfs.safemode.threathold.pct)（デフォルトなら0.1%）以上の割合のデータの全レプリカがHDDの複数同時故障等により失われている場合、最小複製状態を満たすことができず、セーフモードから自動的には離脱できなくなる。
    • 対処手順はまず10.1.2.1節のコマンドによりセーフモードから強制離脱、次に10.1.4.1節のdfsadminの -move あるいは-delete オプションにより壊れた・失われたブロックに対処。

セーフモードへの移行・解除

  • [記入者] terurou
  • [該当箇所] 301〜302ページ（10.1.2.1 セーフモードへの移行と終了）
  • セーフモードが有効になっているか判定
    • hadoop dfsadmin -safemode get
  • セーフモードが解除されるまでWait（スクリプトなどで利用する）
    • hadoop dfsadmin -safemode wait
  • セーフモード 手動ON
    • hadoop dsfadmin -safemode enter
  • セーフモード 手動OFF
    • hadoop dfsadmin -safemode leave

監査ログの出力

  • [記入者] terurou
  • [該当箇所] 302〜303ページ（10.1.3 監査ログ）
  • HDFSはすべてのアクセス要求のログをとることができる
  • log4jの出力設定をINFOレベルに変更するだけでよい
  • いわゆるJ-SOX法とか内部統制への対応に必須ですね

HDFSの運用ツール

  • [記入者] terurou
  • [該当箇所] 303〜303ページ（10.1.4 ツール）
  • dfsadmin
    • HDFSの状態取得や管理操作を行う
    • 機能については表10-4を参照
  • fsck
    • HDFSのファイル健全性チェック
      • ブロックのレプリカ作成状況（過剰複製、複製数不足、複製位置の誤り、破損・消失ブロック）を出力
    • 指定したファイルに含まれるブロックの探索
  • DataBlockScaner
    • 定期的にブロックのスキャンを行う（チェックサムエラーの検出）
    • スキャン間隔はdfs.datanode.scan.period.hoursで設定（デフォルトは504時間＝3週間）
  • start-balancer.sh
    • 長期間HDFSを運用しているとブロックの分散度合いが偏ってくるので、ブロックを再配置する（デフラグ的な感じ）
    • balancerはクラスタに過度の負荷を与えないように設計されている

Hadoopのモニタリング

  • [記入者] terurou
  • [該当箇所] 308〜314ページ（10.2 モニタリング）
  • ロギング（システムログ）
    • すべてのデーモンはlog4jでログを出力する
    • Webページから設定変更（デーモン再起動時にリセットされる）
    • hadoopコマンドから設定変更（デーモン再起動時にリセットされる）
      • hadoop daemonlog -setlevel jobtracker-host:50030 org.apache.hadoop.mapred.JobTracker DEBUG
    • 恒久的にログの設定変更を行う
      • log4j.propertiesの設定を変更する
    • 277ページ 9.4.2.3 も参照
  • メトリクス
    • 直訳すると、評価尺度、品質測定。クラスタ管理者のための統計情報
    • dfs, mapred, rpc, jvmというコンテキスト（監視対象）が用意されている
    • FileContext
      • メトリクスをローカルファイルに書き出す
    • GangliaContext
    • NullContextWithUpdateThread
      • メモリ内に保持しているメトリクスを定期的に更新する
      • JMXを利用する場合に利用する（GangliaContextを使っている場合は使う必要がない）
    • CompositeContext
      • メトリクスを複数のコンテキストに出力する
  • JMX（Java Management Extensions）
    • アプリケーション監視用のJava標準API
    • JDK付属のJConsoleや、JMX対応のサードパーティ製の管理ツール（NagiosやHypericなど）で問い合わせすることができる
  • Chukuwa
    • Hadoopのサブプロジェクト
    • 長期にわたるトレンドをログデータから発見することに秀でている
    • http://incubator.apache.org/chukwa/
    • どうでもいいけど、ロゴが。。。

データのバックアップ

  • [記入者] terurou
  • [該当箇所] 315ページ（10.3.1.1 メタデータのバックアップ）
  • メタデータ
    • セカンダリネームノードのprevious.checkpointディレクトリ以下をバックアップ
  • データ
    • HDFSで扱うデータが大量になので、全てはバックアップできない
    • 優先度の高いデータをバックアップする
    • ファイルのコピー自体はdistcopyを使う

ファイルシステムのメンテナンス

  • [記入者] terurou
  • [該当箇所] 316ページ（10.3.1.3 ファイルシステムのチェック（fsck）, 10.3.1.4 ファイルシステムのバランサー）
  • fsckを定期的にしましょうね
    • 10.1.4.2 を参照
  • balancerを定期的に動かしましょうね
    • 10.1.4.4 を参照

エラッタ？

  • [記入者] terurou
  • [該当箇所] 316ページ（10.3.2.1 新しいノードの参加）
  • 「mapred-site.xmlを設定して、jobtrackerを指し、データノードとjobtrackerが起動...」
  • jobtrackerではなくてtasktrackerだと思われる。

クラスタへのノードの追加

  • [記入者] terurou
  • [該当箇所] 316〜317ページ（10.3.2 ノードの参加と脱退）
  • 事前準備
    1. ネームノード、jobtrackerへ接続可能なアドレスを列挙したファイル（includeファイル）を作成し、共有ファイルとする
    2. ネームノードのdfs.hostsプロパティ、jobtrackerのmapred.hostsプロパティでincludeファイルを参照するように設定する
  • 手順
    1. 追加するノードのhdfs-site.xmlを編集。ネームノードを指すように設定する。
    2. 追加するノードのmapred-site.xmlを編集。jobtrackerノードを指すように設定する。
    3. includeファイルに追加するノードのアドレスを追加する。
    4. ネームノードの接続ノード情報を更新する。
      1. hadoop dfsadmin -refreshNodes
    5. slavesファイルに追加するノードを追加し、Hadoopの制御スクリプトのコントロール下におく。
    6. データノードを起動
      1. hadoop-daemon.sh start datanode
    7. jobtrackerの接続ノード情報を更新し、tasktrackerを起動する。（MapReduceクラスタの再起動）
      1. stop-mapred.sh
      2. start-mapred.sh
    8. Web UIから新ノードが追加されたことを確認する。
    9. 必要に応じ、HDFSのブロックをバランスさせる。
      1. start-balancer.sh

クラスタからノードの削除

  • [記入者] terurou
  • [該当箇所] 318〜319ページ（10.3.2 ノードの参加と脱退）
  • 事前準備
    1. ネームノード、jobtrackerへ接続拒否するアドレスを列挙したファイル（excludeファイル）を作成し、共有ファイルとする
    2. ネームノードのdfs.hosts.excludeプロパティ、jobtrackerのmapred.hosts.excludeプロパティでexcludeファイルを参照するように設定する
  • 手順
    1. excludeファイルに削除するノードのアドレスを追加する。
    2. jobtrackerの接続ノード情報を更新し、削除するノードのtasktrackerを停止する。（MapReduceクラスタの再起動）
      1. stop-mapred.sh
      2. start-mapred.sh
    3. ネームノードの接続ノード情報を更新する。
      1. hadoop dfsadmin -refreshNodes
    4. Web UIからノードがDecommissionedになったことを確認し、対象ノードをシャットダウンする。
    5. includeファイルから削除対象ファイルのアドレスを削除する。
    6. 再度ネームノードの接続ノード情報を更新する。
      1. hadoop dfsadmin -refreshNodes
    7. slavesファイルから対象ノードのアドレスを削除する。

クラスタ上のHadoopをアップグレード（HDFSのレイアウト変更なし）

  • [記入者] terurou
  • [該当箇所] 319〜320ページ（10.3.3 アップグレード）
  1. 新しいバージョンのHadoopをインストール
  2. 古いバージョンのデーモンを停止
  3. 新しいHadoopの設定ファイルを更新
  4. 新しいデーモンを起動
  • HDFSのレイアウトのバージョンが異なっている場合、ネームノードは実行を拒否し、エラーログを出力する。

クラスタ上のHadoopをアップグレード（HDFSのレイアウト変更あり）

  • [記入者] terurou
  • [該当箇所] 320〜323ページ（10.3.3 アップグレード）
  • アップグレード前に確認すること
    • 以前アップグレードをしたことがある場合、ファイナライズされているか確認する。
  • 手順
    1. MapReduceをシャットダウンする。
      1. stop-mapred.sh
    2. tacktrackerで孤立してしまったタスクのプロセスが残っている場合はkillする。
    3. HDFSをシャットダウンする。
      1. stop-dfs.sh
    4. ネームノードのディレクトリをバックアップする。
    5. 新しいバージョンのHadoopをインストールする。
    6. HDFSを-upgrageオプションつきで起動する。
      1. start-dfs.sh -upgrade
    7. アップグレードが完了したら、ファイル健全性チェックを行う
      1. hadoop fsck /
    8. MapReduceを起動する。
      1. start-mapred.sh
    9. しばらく運用し問題がなければ、アップグレードのファイナライズを行う。問題があればロールバックする。
      1. （ファイナライズ）hadoop dfsadmin -finalizeUpgrade
      2. （ロールバック）start-dfs.h -rollback

運用について合わせて読みたい

このエントリーをTumblrにポストClip to Evernoteこのエントリーをはてなブックマークに追加
Hadoop本読書会 - 10章 Hadoopの管理 - 大規模分散技術勉強会 in 名古屋 先頭へ

コメントをかく


「http://」を含む投稿は禁止されています。

利用規約をご確認のうえご記入下さい
 

最近更新したページ

最新コメント

QRコード

アクセス解析中

どなたでも編集できます