GoogleFileSystem設計構想
為滿足Google數據處理的需求，Google工程師設計并實現了GoogleFileSystem（GFS）。GFS與傳統分布式文件系統類似，也需要滿足高性能、可伸縮性、可靠性以及可用性。與傳統分布式文件系統思路不不同的是：
- GFS認為組件失效是常態而非意外，GFS由大量廉價設備組成
- 文件數量異常巨大
- 絕大部分文件修改采用文件尾部追加數據而非覆蓋原有數據
- 應用和文件系統協同設計
GFS架構設計
一個GFS包含一個單獨的Master節點、多臺Chunk服務器，并同時被多個客戶端訪問。
存儲方式
GFS存儲的文件被分割成固定大小的Chunk，Master分配給每個Chunk一個不變的64位唯一標識。每個Chunk備份到多個服務器上，以提高可靠性。
Master服務器
Master服務器管理所有Chunk的元數據，以管理各Chunk數據（類似于Linux文件系統的inode）。每個Chunk大小為64M，Chunk元數據大小為64字節，而且由于大多數文件包含多個Chunk因此可以將所有Chunk的元數據存儲在Master的內存中，增強系統的簡潔性、可靠性、高性能和靈活性。
Chunk信息
Master服務器不永久保存Chunk服務器有指定Chunk的副本的信息。因為在一個擁有數百臺服務器的集群中，Chunk服務器加入集群、離開集群、更名、失效、以及重啟的時候，Master服務器和Chunk服務器數據同步的問題會非常頻繁。Master服務器在啟動時候輪詢Chunk服務器，并在之后定期輪詢更新。
GFS的日志系統（災備）
操作日志包含了關鍵的元數據變更歷史記錄。操作日志是元數據唯一的持久化存儲記錄，同時也是判斷同步操作順序的邏輯時間基線（類似LSN），必須確保日志文件的完整，確保只有在元數據的變化被持久化后，日志才對客戶端是可見的。GFS把日志復制到多臺遠程機器，只有相應的日志記錄寫入到本地以及遠程機器的硬盤后，才會響應客戶端的操作請求。Master服務器會收集多個日志記錄后批量處理，以減少寫入磁盤和復制對系統整體性能的影響。
GFS災難恢復
Master服務器在災難恢復時，通過重演操作日志把文件系統恢復到最近的狀態。為了縮短Master啟動的時間，重演系統操作的日志量盡量的少。Master服務器在日志增長到一定量時對系統狀態做一次Checkpoint（對數據庫的快照）。在災難恢復的時候，Master服務器就通過從磁盤上讀取這個Checkpoint文件，以及重演Checkpoint之后的有限個日志文件就能夠恢復系統。Checkpoint文件以壓縮B-樹形勢的數據結構存儲，可以直接映射到內存，在用于命名空間查詢時無需額外的解析。Master服務器恢復只需要最新的Checkpoint文件和后續的日志文件。舊的Checkpoint文件和日志文件可以被刪除。通常會多保存一些歷史文件。Checkpoint失敗不會對正確性產生任何影響，因為恢復功能的代碼可以檢測并跳過沒有完成的Checkpoint文件。
資料
The Google File System – Research at Google
谷歌三大核心技術（一）Google File System中文版 譯者：alex
原創文章，作者：easyTang，如若轉載，請注明出處：http://www.www58058.com/74893
