《The Google File System》論文閱讀筆記——GFS設計原理

1、設計預期

設計預期每每針對系統的應用場景，是系統在不一樣選擇間作balance的重要依據，對於理解GFS在系統設計時爲什麼作出現有的決策相當重要。因此咱們應重點關注：

• 失效是常態
• 主要針對大文件
• 讀操做：大規模流式讀取、小規模隨機讀取
• 寫操做：大規模順序追加寫，寫入後不多修改
• 高效明肯定義的並行追加寫
• 穩定高效地網絡帶寬

2、總體設計

一、系統架構

GFS主要由如下三個系統模塊組成：

• Master：管理元數據、總體協調系統活動
• ChunkServer：存儲維護數據塊（Chunk），讀寫文件數據
• Client：向Master請求元數據，並根據元數據訪問對應ChunkServer的Chunk

二、設計要點

1）Chunk尺寸

因爲GFS主要面向大文件存儲和大規模讀寫操做，因此其選擇了遠大於通常文件系統的64MB的Chunk尺寸。

好處：

• 減小元數據量，便於客戶端預讀緩存，減小客戶端訪問Master的次數，減少Master負載；
• 減小元數據量，Master能夠將元數據放在內存中；
• 客戶端短期內工做集落在同一Chunk上的機率更高，減小客戶端訪問不一樣ChunkServer創建TCP鏈接的次數，從而減小網絡負載。

壞處：

• 易產生數據碎片；
• 小文件佔用Chunk少，對小文件的頻繁訪問會集中在少數ChunkServer上，從而產生小文件訪問熱點。

可能的解決方案：

• 增大小文件複製參數；
• 客戶端間互傳數據。

2）元數據存儲方式

Master存儲的元數據包括：命名空間、文件和Chunk的對應關係、Chunk位置信息。

命名空間、文件和Chunk的對應關係的存儲方式：

• 內存：真實數據；
• 磁盤：按期Checkpoint（壓縮B樹）和上次CheckPoint後的操做日誌；
• 多機備份：Checkpoint文件和操做日誌。

Chunk位置信息的存儲方式：

• 內存：真實數據
• 磁盤：不持久存儲

系統啓動和新Chunk服務器加入時從Chunk服務器獲取。避免了Master與ChunkServer之間的數據同步，只有Chunk服務器才能最終肯定Chunk是否在它的硬盤上。

3）一致性模型

命名空間修改：原子性和正確性

文件數據修改（以後詳細解釋）：

• 修改失敗：不一致
• 串行隨機寫：一致且已定義
• 並行隨機寫：非原子寫，一致但未定義
• 串行/並行追加寫（推薦）：少許不一致，保證已定義

3、詳細設計

一、系統交互設計

1）重要原則

最小化全部操做與Master的交互。

2）緩存機制

最小化讀取操做與Master的交互：

客戶端訪問Chunk前從Master獲取元數據的過程當中，會預取和緩存部分Chunk的元數據，從而減小與Master的交互。

2）租約機制

最小化變動操做與Master的交互：

Master收到變動操做請求後

• 選擇一個Chunk副本發放定時租約做爲主Chunk並返回給客戶端；
• 客戶端與主Chunk進行通訊進行變動操做；
• 租約超時前，對該Chunk的變動操做都由主Chunk進行序列化控制。

3）數據流與控制流分離

數據推送與控制操做同時進行。

數據流：管道方式按最優化的Chunk服務器鏈推送，以最大化帶寬，最小化延時（全雙工交換網絡，每臺機器進出帶寬最大化）；

控制流：

• 主ChunkServer肯定二級副本接收完畢後，對全部變動操做分配連續序列號（序號肯定操做順序）；
• 按序修改本地數據；
• 請求二級副本按序修改；
• 全部副本修改完成成功，不然失敗重作。

4）非原子寫操做

一次寫入數據過大，可能被客戶端分爲多個寫操做，這些寫操做序號可能不連續，被其餘併發寫操做打斷或覆蓋，出現數據一致但未定義的狀態。

5）原子記錄追加

追加寫時GFS推薦的寫入方式，應重點研究。

a. 原子記錄追加：客戶端指定寫入數據，GFS返回真實寫入偏移量。

b. 追加寫的過程：

• 追加操做會使Chunk超過尺寸
  • 填充當前Chunk；
  • 通知二級副本作一樣操做；
  • 通知客戶機向新Chunk追加；
• 追加操做不會使Chunk超過尺寸
  • 主Chunk追加數據；
  • 通知二級副本寫在相同位置上；
  • 成功 - 返回偏移； 失敗 - 再次操做。

c. 追加結果：失敗的追加操做可能致使Chunk間字節級別不一致，但當最終追加成功後，全部副本在返回的偏移位置一致已定義，以後的追加操做不受影響。以下圖所示：

d. 冗餘數據處理：對於追加寫產生的冗餘數據

• Chunk尺寸不足時的填充數據
• 追加失敗時產生的重複內容

可在插入數據時附帶記錄級別的Checksum或惟一標識符，在客戶端讀取數據時進行校驗過濾。

6）快照

使用COW技術，瞬間完成。快照實現的過程：

• 收回文件全部Chunk的租約；
• 操做元數據完成元數據拷貝；
• 客戶端要寫入該文件的Chunk時，Master通知該Chunk所在ChunkServer進行本地拷貝；
• 發放租約給拷貝Chunk；
• 返回拷貝Chunk的位置信息。

二、Master節點設計

1）名稱空間管理

多操做並行，名稱空間鎖保證執行順序，文件操做需得到父目錄讀鎖和目標文件/目錄寫鎖。

2）副本位置

Chunk跨機架分佈：

好處 -

• 防止整個機架破壞形成數據失效
• 綜合利用多機架整合帶寬（機架出入帶寬可能小於機架上機器的總帶寬，因此應最大化每臺機架的帶寬利用率）；

壞處 - 寫操做需跨機架通訊。

3）Chunk管理

a. 建立操做，主要考慮：

• 平衡硬盤使用率；
• 限制單ChunkServer短時間建立次數（建立開銷雖小，但每次建立每每意味着大量的後續寫入）；
• 跨機架分佈。

b. 重複制，即有效副本不足時，經過複製增長副本數。優先考慮：

• 副本數量和複製因數相差多的；
• live（未被刪除）文件的；
• 阻塞客戶機處理的

Chunk進行重複制。策略與建立相似。

c. 重負載均衡，經過調整副本位置，平衡格機負載。策略與建立相似。新ChunkServer將被逐漸填滿。

4）垃圾回收

惰性回收空間：刪除操做僅在文件名後添加隱藏標記，Master在常規掃描中刪除超時隱藏文件的元數據，並通知對應ChunkServer刪除Chunk。

好處 -

• 與建立失敗的無效Chunk一致的處理方式；
• 批量執行開銷分散，Master相對空閒時進行；
• 刪除操做必定時間內可逆轉。

壞處 - 不便於用戶進行存儲空間調優。

解決方案 - 再次刪除加速回收，不一樣命名空間不一樣複製回收策略。

5）過時失效副本檢測

過時檢測：Master維護Chunk級別版本號，新租約增長Chunk版本號，並通知全部副本更新版本號，過時Chunk會因版本號過舊被檢測。

三、容錯機制設計

1）高可用性

主要的提升可用性的機制：

• 組件快速恢復
• Chunk複製
• Master服務器複製
  • Checkpoint和操做日誌多機備份；
  • Master進程失效重啓，硬件失效則新機器重啓Master進程；
  • 「影子」Master，經過操做日誌「模仿」主Master操做，元數據版本稍慢。做用 - 分擔必定負載、失效期暫時接管。

2）數據完整性

ChunkServer獨立維護CheckSum檢驗副本完整性。緣由：

• 跨Chunk服務器比較副本開銷大；
• 追加操做形成的的byte級別不一致，致使沒法經過比較副本判斷完整性。

Chunk讀取和Chunk服務器空閒時，進行CheckSum校驗，發現損壞Chunk上報Master，進行重複制。

Checksum校驗的開銷：

• Checksum讀取開銷；
• Checksum校驗計算開銷。

但總體開銷能夠接受，特別是對追加寫操做。

覆蓋寫與追加寫的Checksum計算開銷比較。二者的關鍵區別在於不完整塊的CheckSum計算：

• 追加寫 - 對最後一個不完整塊，在寫入後進行增量的CheckSum計算。New CheckSum由Old CheckSum和新數據算出，未對原有數據從新計算，原有數據損壞，依然能夠發現；
• 覆蓋寫 - 對第一個和最後一個不完整塊，在寫以前進行CheckSum校驗。不然，覆蓋寫只能從新對整塊計算CheckSum，若寫操做未覆蓋部分存在損壞數據，新CheckSum將從包含損壞數據的Chunk算出，以後再也沒法校驗出該損壞數據。

4、總結

本文是我在閱讀論文《The Google File System》時記下的筆記，對論文的各部份內容進行了梳理。

系統設計過程每每就是在各類因素間根據目標需求權衡利弊的過程。分佈式系統設計須要權衡的問題存在許多共性，GFS在設計過程當中基於分佈式環境的特色，作的許多重要決策對於其餘分佈式系統開發具備指導性的意義。

因此，我盡力把以爲有趣的設計要點進行了提煉，並對重要細節進行了重點分析，特別是各類權衡帶來的好處和壞處，以及針對最終選擇帶來的壞處的彌補方案。

若是這篇文章在梳理本身思路的同時，能爲感興趣的朋友們提供一點點幫助，那也算作了件有意義的事情了！