Downloaded 36 times
Recommended
Hdfsソースコードリーディング第２回
- 1.
- 2.自己紹介筑波大学大学院1年Hadoop, Gfarmなど分散ファイルシステムを研究中（主に性能評価など）Twitter: @shun0102三上俊輔の研究日記: http://shun0102.net
- 3.
- 4.前回の内容HadoopのファイルシステムはプラガブルHadoopMapReduceorg.apache.hadoop.fs.FileSystemHDFS clientOther FilesystemsclientHDFS serverOther Filesystems server
- 5.Append/Hflush/Read DesignHDFS-265の appendDesign3.pdfAppendを実装するためにのデザイン設計HDFSの書き込み時、読み込み時、エラー処理の時の振る舞いが細かく書かれているHadoop0.21これを読むことで、HDFSの一貫性モデル、故障時の振る舞いが具体的にわかる今回は2章をメインに
- 6.ブロックの状態管理DataNodeでのブロックをレプリカと呼び、NameNodeでのブロックはブロックと呼ぶNameNode{Finename, numReplicas, block-ids}{block-id,datanodes}ブロックの状態DataNodesblock-idblock-idblock-idレプリカの状態レプリカの状態レプリカの状態
- 7.Append 導入前initCreateTemporaryFinalizedCloseOpen forAppendAppend導入後errordelete
- 8.なぜAppendのために新しいブロックの状態が必要か？Temporaryと finalized のみの状態管理では既にfinalizedしたブロックを失う可能性があるfileappendブロックを失ってしまうerrorTemporary block
- 9.
- 10.DataNodeのレプリカの状態以下の5状態があり、これはDataNodeのメモリ上で管理されるFinalizedRbw (Replica BeingWritten to)Rwr (Replica Waiting to be Recovered)Rur (Replica Under Recovery)Temporary
- 11.
- 12.Rbw (Replica BeingWritten to)レプリカが作成されるかappendされる時にrbw状態になる常にファイルの最後のブロック同じblock idの他のレプリカとデータサイズが一致していない状態Bytes はリーダーに見えるが、全てではないかもしれない障害時に出来るだけ保持しようとする
- 13.Rwr (Replica Waitingto be Recovered)データノードが死んで再起動した時、全ての rbwレプリカは rwrになるパイプラインには復帰しないので、新しいバイトは受け取らないクライアントが生きてれば無効になるクライアントも死んでいればリースリカバリに参加する
- 14.リースリカバリとはNameNode{Finename, lease expire,lease holder}Updatelease holderClientWriteDataNode
- 15.Rur (Replica UnderRecovery)リースリカバリの結果、レプリカを復旧する時にこの状態になる
- 16.Temporaryレプリカ作成か、クラスタのバランシングのためのレプリカRbwと共通点は多いが、リーダーには見えず、DataNodeの再起動時には削除されるdeletedfail or DNrestartTemporaryReplicainitreplicate/copy for balancingsucceedsFinalizedReplica
- 17.ディスク上での保存方法dfs.data.dir以下の3つのサブディレクトリに保存されるcurrent (finalized)再起動時に全て finalizedレプリカになるtmp (temporary)再起動時に全て削除されるrbw (rbw, rwr, rur)再起動時に全て rwrレプリカになる
- 18.レプリカの状態遷移initCreateReplicaBeingWrittenFinalizedReplicacloseWriteAppendReplicaRecaveryfinishesReplica recovery startsDNrestartsDN diesDN diesReplicaWaiting ToRecoveredReplicaUnderRecoveryReplica recovery startsReplicaRecovery starts
- 19.
- 20.ブロックの状態遷移（通常時）initaddBlockAppend if lastblock is fullCompleteBlockBlock UnderConstructionclose / addBlockAppendclose / addBlockReceives a GS/Lenmatched finalizedreplicaCommittedBlock
- 21.ブロックの状態遷移(クライアントが死んだ場合）CompleteBlockBlock UnderConstructionReceives aGS/Lenmatched finalizedreplicaLease expires &block recovery startsBlock UnderRecoveryCommittedBlockRecovery succeeds
- 22.ブロックの状態遷移（NN再起動時）CompleteBlockBlock UnderConstructionLast blockofan unclosed fileinitrestReceives a GS/Lenmatched finalizedreplicaLease expires &block recovery startsBlock UnderRecoveryCommittedBlockRecovery succeeds
- 23.まとめAppendの目的一度finalizedしたデータに対して強い耐障害性Hflushしたデータに対して best effortな耐障害性Append のために新しいレプリカ、ブロックの状態を導入レプリカは5状態、ブロックは4状態で管理状態はメモリ上に保存される