經典分佈式論文閱讀：GFS

本文是GFS論文的學習筆記。GFS（Google File System）是谷歌針對分佈式大數據處理而設計的大規模分佈式文件系統。在設計GFS的時候主要考慮了應用場景的如下特性：

• 故障時常發生
• 文件十分巨大
• 大部分文件修改操做只是追加而不是覆蓋
• 協同設計文件系統和應用能夠增長系統的靈活性

系統概覽

根據應用場景的特性，論文對文件系統作了如下設定：

• 系統由廉價的硬件構成，所以故障也是時有發生的事情
• 系統須要存儲大量大文件
• 讀取任務主要包括大數據量的流式讀取和小數據量的隨機讀取
• 寫入任務主要是大數據量的數據寫入到文件末尾
• 系統須要實現相應功能，保證不一樣客戶端可以高效並行寫入同一個文件
• 高帶寬比低延遲更重要

GFS以目錄樹的形式組織文件，可是並無提供相似POSIX標準的文件系統操做。操做只要包含建立、刪除、打開、關閉、讀取、寫入、快照和記錄追加，其中快照操做用於快速複製一個文件或者目錄，記錄追加功能容許多個客戶端並行追加數據到一個文件。

GFS的集羣由一個主服務器（master）和多個塊服務器（chunkserver）構成。每一個文件由文件塊組成，文件塊採用64位的塊句柄進行惟一標識，原文中文件塊大小爲64MB，不過這是16年前的系統，如今64MB顯得就過小了。

• 主服務器：保存了整個文件系統的元數據，元數據包括命名空間、訪問控制信息、文件到塊的映射和每一個文件塊的位置，還要負責文件塊租借管理、垃圾回收、文件塊遷移，在運行過程當中經過心跳包和塊服務器交換信息。
• 塊服務器：保存文件塊並向主服務器報告狀態。
• 客戶端：從主服務器獲取元數據，而後再從塊服務器讀寫文件數據。

文件塊大小

文中表示，使用較大的文件塊好處多多：

• 可以減小客戶端向主服務器查詢塊位置的次數，下降了主服務器負載
• 在單個文件塊內的操做變多，下降了網絡負載
• 減小了主服務器須要保存的元數據的數量

固然，大文件塊會致使小文件只存在一個文件塊中，所以若是大量客戶端對某個小文件的寫入，那麼負載會集中在某幾臺保存這個文件塊服務器上，不過能夠增長小文件的副本數量。

元數據

主服務器保存的元數據主要爲：文件命名空間、文件到數據塊的映射和數據塊的位置。文件命名空間和文件到數據塊的映射的數據須要持久化地寫入到一個操做日誌中，而數據塊的位置經過和塊服務器通訊得到。

這些元數據須要保存在主服務器的內存中來加速訪問。主服務器在運行中會週期性地進行掃描，來完成數據塊垃圾回收、故障塊服務器數據重備份以及遷移數據塊進行負載均衡。

操做日誌記錄了元數據地修改歷史，主要用於故障恢復。顯然，操做日誌還須要在主服務器以外的遠程服務器備份，全部操做必須在寫入到操做日誌以後執行。操做日誌一般會結合檢查點機制進行高效地備份。

一致性模型

在分佈式文件系統，一個文件被修改以後會出現如下狀態

	寫入	追加
順序成功執行	肯定	肯定+不一致
並行成功執行	一致+不肯定	肯定+不一致
失敗	不一致	不一致

• 一致：全部客戶端看到的數據塊是同樣的
• 肯定：文件知足一致性，而且每次修改都能知道具體修改的內容

一次成功的獨立寫入後的數據是一致的，成功的並行寫入後的數據是一致，可是並不知道每一個修改的具體內容。修改操做包括寫入和記錄追加，記錄追加保證至少一次是肯定的（詳細見後續解釋）。

GFS中文件肯定性和實時性有如下兩個策略肯定：

1. 在全部副本上的修改保持一致的順序
2. 使用塊版原本識別塊是否過時

客戶端能夠緩存塊位置，緩存超時或者從新打開文件後即從新獲取位置。GFS主要經過心跳判斷塊服務器是否正常，若是一個塊在全部塊服務器上找不到，那麼即爲丟失，訪問的時候返回錯誤信息。

系統交互

租約和修改順序

修改操做包括對文件元數據和內容的修改，例如寫入和追加。GFS使用租約來保證多個副本之間修改順序的一致性，主節點會將租約受權給某個副本，每一個租約有必定的有效期。

1. 客戶端詢問主服務器持有當前塊租約的塊服務器以及其餘副本位置。若是目前沒有租約，那麼選擇一個副本受權租約。
2. 主服務器回覆全部副本位置和主副本標識。
3. 客戶端將數據推送到全部副本上。
4. 當全部副本確認收到了數據以後，客戶端給主副本發送寫入請求。而後，主副本規定順序執行修改操做。
5. 主副本將寫入請求發送給其餘全部從副本。每一個從副本按照相同順序執行修改操做。
6. 從副本告知主副本完成了操做。
7. 主副本答覆客戶端

數據流

爲了提升網絡效率，數據流和控制流是互相分開的。控制流從客戶端開始，到主副本，再到從副本，而數據線性地沿着一個塊服務器串以管道的形式傳輸。塊服務器的串從客戶端開始，每次選擇最近的塊服務器做爲下個節點。

原子記錄追加

GFS提供了原子記錄追加功能，將數據追加到文件末尾，並將新數據的起始位置返回給客戶端。追加操做寫入前，主副本會檢查追加數據是否會超出最後一個塊的大小。若是超出，那麼填補剩餘空間，將數據追加到新的塊中，並將位置告知客戶端。不然，直接將數據追加到最後一個塊中。

當任何一個副本寫入故障以後，客戶端就會開始重試，那些故障時寫入的數據區就產生了不一致，所以只能保證數據寫入至少有一次是一致的。

快照

快照可以快速複製一個文件或者文件夾樹，採用寫時複製。

主節點操做

命名空間管理和鎖定

GFS支持命名空間上的鎖操做來保證串行。GFS維護了一個文件路徑到元數據的映射，之前綴壓縮的形式保存。每一個文件夾或者文件是命名空間樹中的一個節點，每一個節點都有讀寫鎖。

每一個操做以前須要獲取一系列的鎖。若是某個操做涉及/d1/d2/.../dn/leaf，首先須要獲取文件夾/d1,/d1/d2,...,/d1/d2/.../dn上的讀鎖，然而獲取文件上的讀鎖或者寫鎖/d1/d2/.../dn。例如，咱們將/home/user快照副本到/save/user上，那麼能夠給/home/user加寫鎖阻止其餘程序在/home/user下建立新的文件。顯然，鎖須要按順序獲取來避免死鎖。

副本存放

副本存放策略須要達到兩個目的：

• 最大化數據可靠性和可用性
• 最大化網絡帶寬利用率

所以，副本須要存放到不一樣的機架上，讀取操做就能利用多個機架的帶寬。可是，寫入操做的數據流須要跨越多個機架，這是能夠接受的權衡。

建立、從新複製和從新平衡

快副本在三種狀況下建立：塊建立、從新複製和從新平衡。

當塊建立的時候，塊服務器的選擇規則爲：

1. 選擇磁盤利用率低於平均值的服務器
2. 限制最近建立塊數量
3. 將塊散佈到不一樣機架上

從新複製會發生在：塊服務器失聯、副本損壞、磁盤損壞、備份數量增長。塊的複製有優先級，通常是距離備份目標數量的差距，以及優先處理正在阻塞程序的塊。

從新平衡移動副本位置來平衡磁盤空間和負載，通常將副本從高磁盤利用率的服務器移動到低磁盤利用率的服務器。

垃圾回收

當應用程序要求刪除一個文件時，主節點將文件重命名爲一個隱藏名並記錄時間，三天以後才物理刪除。在物理刪除以前，還可使用隱藏文件名讀取以及撤銷刪除。運行期間，主節點會掃描那些沒法到達的塊並刪除元數據，塊服務器經過心跳得知再也不有用的塊。總之，全部主節點不知道的副本都是「垃圾」。

垃圾回收相對當即刪除有如下優點：

1. 在平常發生組件故障的分佈式系統中，垃圾回收比較可靠
2. 把空間回收放入主節點後臺活動中
3. 延遲迴收給意外刪除提供了迴旋的餘地

垃圾回收的壞處就是沒法在空間緊張的時候快速騰出空間，不過能夠修改回收副本和策略解決。

過時副本檢測

GFS使用塊版本識別副本是否過時，每次受權新的租約以後增長版本號，而後通知其餘副本更新版本號。

容錯和診斷

高可用

高可用主要經過快速恢復和副本來實現。

• 快速恢復：主節點和塊服務器都可以快速恢復和啓動。
• 塊副本：每一個塊被複制到不一樣機架上的不一樣塊服務器上，固然還有其餘建立副本的方式，例如相似於RAID3中的奇偶校驗。
• 主節點副本：主節點的操做日誌和檢查點會被備份在多個機器上，日誌中包括修改操做已經後臺任務。當主節點崩潰以後，GFS使用檢查點和操做日誌啓動新的主節點。另外，能夠設置一些影子主節點來緩解主節點壓力，影子主節點上的文件元數據會有短期的過時。

數據完整性

每一個塊服務器使用校驗和來檢測數據完整性，每一個塊服務器負責檢測本身維護的數據。在讀取數據時，塊服務器首先檢查數據完整性，若是檢查出錯則返回錯誤。在寫入數據時候，須要計算更新校驗和。在空閒時間，塊服務器須要掃描和檢查那些不活躍的數據塊。

診斷工具

GFS主要採用診斷日誌來進行問題排查、調試和性能分析。

參考文獻

1. Ghemawat, Sanjay, Howard Gobioff, and Shun-Tak Leung. "The Google file system." (2003).