Hdfsソースコードリーディング第２回

HDFSソースコードリーディング（第２回）三上俊輔2010/12/17

自己紹介筑波大学大学院1年Hadoop, Gfarmなど分散ファイルシステムを研究中（主に性能評価など）Twitter: @shun0102三上俊輔の研究日記 : http://shun0102.net

HDFSリーディング概要第一回org.apache.hadoop.fsを中心に見た第二回HDFS-265のappendDesign3.pdfを元にブロックの状態管理について第三回一貫性障害からの復帰

前回の内容HadoopのファイルシステムはプラガブルHadoopMapReduceorg.apache.hadoop.fs.FileSystemHDFS clientOther Filesystems clientHDFS serverOther Filesystems server

Append/Hflush/Read DesignHDFS-265の appendDesign3.pdfAppendを実装するためにのデザイン設計HDFSの書き込み時、読み込み時、エラー処理の時の振る舞いが細かく書かれているHadoop 0.21これを読むことで、HDFSの一貫性モデル、故障時の振る舞いが具体的にわかる今回は2章をメインに

ブロックの状態管理DataNodeでのブロックをレプリカと呼び、NameNodeでのブロックはブロックと呼ぶNameNode{Finename, numReplicas, block-ids}{block-id, datanodes}ブロックの状態DataNodesblock-idblock-idblock-idレプリカの状態レプリカの状態レプリカの状態

Append 導入前initCreateTemporaryFinalizedCloseOpen for AppendAppend導入後errordelete

なぜAppendのために新しいブロックの状態が必要か？Temporaryと finalized のみの状態管理では既にfinalized したブロックを失う可能性があるfileappendブロックを失ってしまうerrorTemporary block

Appendの目標Appendする前のデータに対する強い耐障害性Hflushしたデータに対する best effortな耐障害性※以前はAtoimicな追記(Hadoop-1700)を目指していたが、今回はAtomicではないHflush: Datanodeに転送してackが戻ってきたデータ

DataNodeのレプリカの状態以下の5状態があり、これはDataNodeのメモリ上で管理されるFinalizedRbw (Replica Being Written to)Rwr (Replica Waiting to be Recovered)Rur (Replica Under Recovery)Temporary

Finalized書き込みが終了し、appendのために再オープンされない限りも書き込まれない状態

Rbw (Replica Being Written to)レプリカが作成されるかappendされる時にrbw状態になる常にファイルの最後のブロック同じblock idの他のレプリカとデータサイズが一致していない状態Bytes はリーダーに見えるが、全てではないかもしれない障害時に出来るだけ保持しようとする

Rwr (Replica Waiting to be Recovered)データノードが死んで再起動した時、全ての rbwレプリカは rwrになるパイプラインには復帰しないので、新しいバイトは受け取らないクライアントが生きてれば無効になるクライアントも死んでいればリースリカバリに参加する

リースリカバリとはNameNode{Finename, lease expire, lease holder}Updatelease holderClientWriteDataNode

Rur (Replica Under Recovery)リースリカバリの結果、レプリカを復旧する時にこの状態になる

Temporaryレプリカ作成か、クラスタのバランシングのためのレプリカRbwと共通点は多いが、リーダーには見えず、DataNodeの再起動時には削除されるdeletedfail or DN restartTemporaryReplicainitreplicate/copy for balancingsucceedsFinalizedReplica

ディスク上での保存方法dfs.data.dir以下の3つのサブディレクトリに保存されるcurrent (finalized)再起動時に全て finalized レプリカになるtmp (temporary)再起動時に全て削除されるrbw (rbw, rwr, rur)再起動時に全て rwrレプリカになる

レプリカの状態遷移initCreateReplicaBeingWrittenFinalizedReplicacloseWriteAppendReplicaRecaveryfinishesReplica recovery startsDN restartsDN diesDN diesReplicaWaiting ToRecoveredReplicaUnderRecoveryReplica recovery startsReplicaRecovery starts

ブロックの状態 (NameNode)UnderConstruction書き込み中のブロックUnderRecoveryリカバリ中のブロックファイルの有効期限が切れるとこの状態になるCommitted全てのバイトを転送し終わって、GSとファイルサイズをfinalized した状態まだ全DataNodeからのackを受け取っていないComplete書き込み完了

ブロックの状態遷移（通常時）initaddBlockAppend if last block is fullCompleteBlockBlock UnderConstructionclose / addBlockAppendclose / addBlockReceives a GS/Lenmatched finalizedreplicaCommittedBlock

ブロックの状態遷移(クライアントが死んだ場合）CompleteBlockBlock UnderConstructionReceives a GS/Lenmatched finalizedreplicaLease expires &block recovery startsBlock UnderRecoveryCommittedBlockRecovery succeeds

ブロックの状態遷移（NN再起動時）CompleteBlockBlock UnderConstructionLast blockof an unclosed fileinitrestReceives a GS/Lenmatched finalizedreplicaLease expires &block recovery startsBlock UnderRecoveryCommittedBlockRecovery succeeds

まとめAppendの目的一度finalizedしたデータに対して強い耐障害性Hflushしたデータに対して best effort な耐障害性Append のために新しいレプリカ、ブロックの状態を導入レプリカは5状態、ブロックは4状態で管理状態はメモリ上に保存される

Hdfsソースコードリーディング第２回

More Related Content

What's hot (20)

Similar to Hdfsソースコードリーディング第２回 (20)

Hdfsソースコードリーディング第２回