GFS論文學習筆記

jopen 10年前發布 | 48K 次閱讀 GFS 分布式/云計算/大數據

前言：Google大數據處理的3篇核心論文

《The Google File System》：http://research.google.com/archive/gfs.html

《MapReduce: Simplified Data Processing on Large Clusters 》：http://research.google.com/archive/mapreduce.html

《Bigtable: A Distributed Storage System for Structured Data》：http://research.google.com/archive/bigtable.html

 

GFS（Google文件系統）作為一個分布式文件系統，為Google提供基礎的海量數據存儲服務。雖然GFS并沒有開源，但Google在其 04年發表的論文《The Google File System》里面做了詳細的介紹，很多設計思路都很有學習的價值。由于論文很長，這里對這篇論文做個學習筆記，總結一下。

-----------------------------------------------------------------------------------------------------------------------------------

 

一、簡介

重新審視傳統文件系統在設計上的折忠選擇，衍生了GFS不同的設計思路：

*、組件/機器失效是常態，而不是意外事件（容錯性）

*、處理的文件巨大（大數據）

*、絕大多數文件寫操作都是尾部追加數據，而不是隨機寫（讀寫模型）

*、應用程序和文件系統API協同設計，簡化對GFS的要求（靈活性）

 

二、設計概述

1、架構：

1.jpg

* GFS Master（即NameNode）：單獨節點，管理GFS所有元數據（如名字空間、訪問控制權限等）

* GFS ChunkServer（即DataNode）：數據存儲節點，文件被分割為固定大小的Chunk，每個Chunk被唯一標識，默認情況下，Chunk存儲為3個副本。

* GFS Client：實現GFS的API接口函數（不是POSIX標準，因為API只需在用戶空間調用）

2、單一的Master節點

* 單一的Master簡化了設計，使架構能變得簡單

* 缺點是有可能成為系統瓶頸，故需減少對Master的讀寫 => Client只詢問Master相關文件的元數據信息，后面的具體讀寫操作均在ChunkServer上

* Master一般會返回離Client最近的文件副本（減少網絡IO）

3、Chunk的大小選擇

* 是一個關鍵的設計參數，默認為64MB。每個Chunk都以普通Linux文件存儲在ChunkServer上

* 較大Chunk尺寸的優點：1 減少Client和Master通訊。2、減少Master存儲元數據的大小 3 Client對一個Chunk能進行多次操作，減少網絡IO。

* 較大Chunk尺寸的缺點：小文件會存儲為一個Chunk，多個Client同時對單個小文件多次操作時，存放這個Chunk的ChunkServer會成為熱點

4、元數據

* 均存儲于Master服務器的內存中（性能優勢），缺點為受限于內存的大小=>一些可能的壓縮，如文件名等

* 主要有3類：1、命名空間。2、文件和Chunk的映射關系（文件包含哪些Chunk）。3、每個Chunk副本的存放信息

* 命名空間及文件和Chunk的映射關系，均以記錄變更日志的方式落地為系統日志文件，并復制到遠程Master備機上。

* Chunk副本的位置信息為Master周期性向各個ChunkServer輪詢獲得 => 沒有落地，避免了ChunkServer變更時的Master和ChunkServer的數據同步問題

* 操作日志記錄了關鍵元數據變更歷史，對Master的容災非常重要，故只有在元數據變更持久化到日志后，才會對Client可見。為了避免操作日志過長，GFS定期會對當前操作日志做一次Checkpoint，以壓縮B+樹形式存儲為一個CheckPoint文件。

* 故Master的恢復只需最新的CheckPoint文件和后續的操作日志。

5、一致性模型

* 命名空間修改為原子性的，由Master的命名空間鎖保障

 

三、系統交互

* 設計原則：最小化所有操作和Master的交互

1、租約（lease）機制和數據變更順序

  2.jpg

* 租約機制：Master確定一個Chunk副本為主Chunk，給其建立租約，然后主Chunk對更改操作序列化，所有Chunk副本遵循這個序列執行更改操作

* 使用租約機制來保障數據多個副本變更（寫/修改操作）順序的一致性，租約序列由主Chunk產生，最小化Master管理負擔

2、數據流

* GFS將數據流和控制流分離，數據流順序沿著一個ChunkServer鏈推送，目的是為了充分利用機器帶寬，最小化推送時延

* 基于TCP連接的，管道式數據推送方式。1MB數據理想狀態下80ms左右能分發出去

* 每臺ChunkServer會選取里離自己最近的機器做目標推送，Google的網絡拓撲較簡單，通過IP地址就可計算出節點“距離”

3、原子的記錄追加

* GFS提供一種具有原子性的數據追加操作：記錄追加。即Client只需指定要寫入數據（而不用指定偏移值），GFS就保證至少有一次原子的寫入操作執行成功，并返回偏移值的Client

* 記錄追加的引入是為了在分布式應用中，減少很多Client并行對同份數據寫入的同步機制開銷

4、快照

* Client快照請求的理解：對一個文件或者目錄樹做一次拷貝

* GFS使用copy-on-write技術來實現快照：收到快照請求時，Master并沒有立即對指定Chunk拷貝，而只拷貝其元數據并對指定Chunk的引用計數增1。等到Client需要修改指定Chunk時，再在本地復制，并卻保新Chunk擁有租約

 

四、Master節點操作

1、命名空間管理和鎖

* 名字空間的組織：全路徑和元數據映射關系的查找表，利用前綴壓縮，高效存儲在內存中

* 名字空間樹型結構每個節點都有一個讀寫鎖，每個操作開始前都需獲得路徑上所有的讀寫鎖 

    - 鎖策略的設計與實現

  • 避免死鎖方法：鎖的獲取依據全局一致的順序，先按名字空間層次排序，同一層次按字典序排序</p>

    2、Chunk副本的位置

  • Chunk副本的位置選擇策略兩大目標：1 提高數據可靠性 2 提高網絡帶寬利用率
  • 一個簡單有效的策略：多個機架分布存儲Chunk副本 
        - 可靠性：預防整個機架損壞
        - 帶寬利用率：尤其對Chunk讀操作，有效利用多個機架的整合帶寬(同個機架內機器間會帶寬競爭)
    3、Chunk的創建，重新復制，重新負載均衡
  • 創建：3個位置選擇因素，1 平衡硬盤利用率 2 限制每個ChunkServer"近期"創建Chunk個數 3 分布在多機架間
  • 重新復制：當Chunk有效副本數小于設置值，Master對Chunk副本重新復制
  • 重新負載均衡：Master會周期性對Chunk副本重新負載均衡
    4、垃圾回收機制
  • 垃圾回收機制：GFS文件刪除時并不立即釋放物理空間，而是采用惰性策略，在周期性的常規垃圾掃描才回收物理空間。</p>

    * 優點：1 系統設計更簡單 2 批量執行，節省開銷 3 可靠性和容錯性（防誤刪等）

    * 缺點：存儲的開銷，阻礙用戶調優存儲空間使用

    * 實現細節：Client提交文件刪除操作，Master將刪除操作記錄到日志，并將對應文件名改為包含刪除時間戳的隱藏文件名（改名字，并沒有回收物理空 間）。Master周期性對名字空間做常規垃圾掃描，會在名字空間中刪除3天前（可設置）的隱藏文件及元數據。ChunkServer在與Master的 心跳信息中，得知哪些Chunk的元數據不存在了，便可實際回收其物理空間

    5、過期失效的Chunk副本檢測

    * Chunk副本失效的原因：ChunkServer出錯或失效，導致Chunk副本因錯失一些修改操作而失效

    * 通過版本號標識：只要Master給Chunk簽訂新租約（修改操作），就會增加Chunk的版本號，如果ChunkServer出錯或失效，其上面的Chunk副本的版本號就不會增加，不是最高版本號的Chunk副本就會被認為是失效的

    * 在垃圾回收機制中會刪除所有過期失效的Chunk副本

     

    五、容錯和診斷

    * 高可用性的體現，如何處理頻繁發生的組件失效

    1、高可用性

    * 遵循的2個簡單策略：1 快速恢復 2 復制

    * 快速恢復：Master或ChunkServer關閉（正常/異常），都被設計在數秒內可恢復狀態并重啟。Client和其他服務器發現請求超時，會重連重啟的Server

    * Chunk的復制：當ChunkServer關閉或Chksum校驗出損壞的Chunk副本，Master都會通過復制已有Chunk副本來保障副本個數

    * Master的復制：CheckPoint文件+操作日志完成Master的恢復。此外，GFS還有些“影子”Master，在Master宕機時提供GFS的只讀訪問

    2、數據完整性

    * 每個ChunkServer獨立維護Checksum來校驗自己副本的完整性，每個Chunk塊都對應一個32位的Checksum。

    * 當Checksum校驗到數據損壞，ChunkServer會做2件事：1 返回給Client錯誤信息，讓Client操作其他Chunk副本 2 通知Master，請求Chunk副本復制

    * 讀操作的Checksum：只取Chunk小部分額外相關數據進行校驗，對齊在Chunk塊的邊界上

    * 記錄追加操作的Checksum：只增量更新最后一個不完整Chunk塊的Checksum

    * 寫操作的Checksum：先讀取和校驗被寫操作覆蓋的第一個和最后一個Chunk塊，寫操作完成后再重新計算和寫入Chunksum

    * 當ChunkServer空閑時，其會周期性掃描不活動的Chunk塊，檢驗數據完整性

    3、診斷工具

    * 詳細的、深入細節的診斷日志，記錄GFS關鍵性事件，在問題隔離、調試及性能分析都有巨大的幫助

    * RPC日志記錄了網絡上所有請求和響應的詳細記錄，方便重現GFS的消息交互來診斷問題

    * 日志對系統性能影響很小，因為其寫入方式為順序的、異步的。最近的日志保存在內存中，用于更新系統的在線監控

     

    六、度量

    1、小規模基準測試

    * 機器部署：1臺Master，2臺Master復制節點，16臺ChunkServer， 16臺Client（均為PIII 1.4GHz CPU，2GB內存，2個80G/5400rpm硬盤，100Mbps全雙工以太網，GFS集群和Client集群各接入一個交換機，2個交換機用 1GMbps線路連接），測試結果如下圖所示：

    3.jpg

    * 讀操作： N個Client同時從GFS同步讀取數據。

        - 當N=16時，整體讀取速度為94MB/s，理論極限為125MB/s（1Gbps線路），為理論極限值的75%。

        - 當N增大時，單Client的讀取效率下降（N=5為80%，N=16為75%），原因為Client增多時，同時讀單個ChunkServer的幾率也增加

    * 寫操作：N個Client同時向GFS寫入數據。

        - 當N=16時，整體寫入速度為35MB/s，理論極限為67MB/s（要寫入到16個ChunkServer中的3個副本，每個ChunkServer網卡12.5MB/s，故12.5*16/3=67MB/s），約為理論極限的50%

        - 當N增大時，單Client的讀取效率基本持平（均約為50%）。在實際應用中，并沒有成為主要問題

    * 記錄追加操作：N個Client同時追加數據到一個文件。

        - 性能受限于保存文件最后一個Chunk塊的ChunkServer的帶寬，與N大小無關。在實際應用中，ChunkServer的網絡擁塞也不是一個嚴重問題

    2、實際應用中的集群

    * Google內部使用的2個具有代表性的集群（04年）：

        - 集群A：用于內部開發和研究，典型任務為讀取數MB/TB數據，轉化或分析后，結果寫回集群

        - 集群B：用于處理當前生產數據，很少人工干預，持續生產和處理TB級別的數據集

    * 存儲相關的集群特性：

        4.jpg

        - 集群B的“Dead files”比例更高（“Dead files”指物理存儲空間還沒回收的被刪除文件，或者舊版本文件），是因為集群B的文件更大Chunk塊數更多造成的

        - ChunkServer總共保存十多GB左右元數據，主要為Chunk塊的Checksum，此外還有Chunk塊版本號等

        - Master保存幾十MB元數據（Master的內存并不會成為系統瓶頸），每個文件約100字節，主要為以前綴壓縮存儲的文件名，此外還有權限列表，Chunk映射關系等

        - Master和ChunkServer均單機只有約有50~100MB元數據，保證了恢復服務器是非常快速的

    * 讀寫速率相關的集群特征：

    5.jpg

    來自：http://blog.csdn.net/yyyiran/article/details/12687603
 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！