論文閱讀筆記 – The Google File System

作者：劉旭暉 Raymond 轉載請註明出處

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

更多論文閱讀筆記 http://blog.csdn.net/colorant/article/details/8256145

 

關鍵字

GFSDistributed File System

 

==目標問題 ==

 

在相對廉價的機器上構建大規模的，可擴充的，高可靠性，Distributed File System

 

==核心思想 ==

 

GFS的設計思想緊密的圍繞著它的目標問題，它的幾個重要的基本假設是：

• 由於構建系統的是大量的相對廉價的機器，所以硬體的失效是常態，需要有效容忍各種層級的硬體失效
• 檔案的尺寸大於常規檔案尺寸，通常以GB為單位
• 檔案的批量讀寫操作比隨機讀寫操作更頻繁，而寫操作又以添加為主，主要針對這些應用模式進行最佳化
• 需要支援並發的寫操作，對資料的吞吐率的要求高於對低延遲的要求

 

GFS的基本系統架構和工作模式如所示

 

 

基本上來說GFS的系統架構可以概括為:

• 單主節點+多資料服務節點
• 主節點維護檔案命名空間，許可權，資料區塊映射，儲存位置等Meta資訊，協調資料服務節點的Server Load Balancer，調度讀寫操作。所有用戶端的讀寫操作的首次發起，都要通過主節點來擷取資料位元置資訊。
• 為了儘可能減小主節點的負擔，用戶端後續具體讀寫資料都是和資料服務節點直接互動，用戶端同時Cache部分資料Meta資訊，進一步減少主節點負擔。
• 主節點將相關Meta資訊維護在記憶體中，以加速檢索，用Log/Snapshot/多機備份等多種機制保證Meta資料的可靠性
• 檔案劃分為固定尺寸的大小(chunk)進行儲存，每個Chunk都以多個備份的形式分散儲存在不同的資料服務節點上，一方面為了可靠性，另一方面可以增加讀資料操作的吞吐率。
• 無論資料服務節點還是用戶端代碼都不使用Cache快取資料（不需要），簡化系統的複雜性。

 

==實現 ==

 

具體的實現還有各種細節需要考量

 

Chunk Size : GFS預設設定的檔案塊的尺寸是64MB，較大的檔案塊尺寸能減少Master節點的管理開銷，如更少的Meta資料需要儲存，更少的用戶端通訊需求等。但較大的檔案塊尺寸也會帶來部分被多個用戶端同時讀取的檔案在某台資料服務節點上造成熱點（因為較大的chunk
size導致較少的檔案塊，讀取同一個檔案可能最終會讀取同一個檔案塊）

 

Chunk位置資訊 :主節點需要將記憶體中的管理得Meta資訊以Log/Snapshot的形式持久化，但是並不持久化檔案塊的具體位置資訊，而是在每次啟動時查詢資料服務節點，一方面簡化了各種災難恢複情況下，資料一致性的問題。另一方面，資料的存在與否最終根本上還是資料服務節點說了算。

 

資料互動流程和一致性問題：為了保證不同的資料備份Replica的一致性，就需要保證對所有replica的更新操作的一致性，為了減少主節點的負擔，GFS設計了Lease租約來管理Replica，每次操作都會有一個Replica得到具體Chunk的Lease，這個Replica稱為Primary，在Lease有效期間，client對資料的更新的控制資訊通過該Primary執行和分發，但是資料本身則不一定先寫入Primary再分發，而是通過寫入離Client最近的節點，再序列化由該節點依次寫入臨近的節點。這樣做是為了最大化網路頻寬的利用。

 

 

 

資料完整性：一個Chunk內部資料按64KB劃分為一個資料區塊，對這個資料區塊進行校正，每個資料服務節點負責校正自己的資料，並且定期掃描所有的檔案塊，這樣有助於及早探索資料的損壞。

 

空間回收，到期資料檢測等：對於刪除的檔案資料，GFS並不會即時刪除其資料區塊對應的物理檔案，而是重新命名並標識起來，定期批量回收，這樣一方面減少了狀態同步的複雜性，另一方面批量處理也有助於效能的提高。對於各種災難恢複場合下，資料更新可能在某些節點上步調不一致的情況，GFS對每個Chunk都維護了一個版本資訊，每次更新操作都會增加對應Chunk的版本號碼，這個版本號碼被用在各種讀寫操作中，以檢測資料的合法性。

 

==相關研究，項目等 ==

 

HDFS是GFS設計思想的一個開源實現