眾所周知，Hadoop的存儲基礎，HDFS分布式文件系統，是按照GFS的思想實現的。

本文參考：Google File System 中文版 1.0 版 譯者 alex，原文地址 http://blademaster.ixiezi.com/

GFS是面向大規模數據密集型應用的，可伸縮的分布式文件系統。

1. 重要設計思路

1. 組件失效被認為是常態而不是突發事件，高度強調災備和自動恢復
2. 按照文件非常巨大的方向設計
3. 絕大部分修改是在文件尾部追加，而不是覆蓋原有數據：文件寫完之后對文件最多的操作是讀取，客戶端無需緩存數據塊，通過數據追加來優化性能和保證原子性
4. 應用程序和文件系統API的協同設計提高系統靈活性。e.g. 通過原子性的記錄追加的引入.放松GFS對一致性模型的要求

2. 設計概述

2.1 設計預期

• 對于小文件隨機讀取的解決方式：通常做法是把小規模的隨機讀取操作合并并排序，之后按照順序批量讀取，這樣可以避免在文件中前后來回讀取位置

• 高性能帶寬比低延遲重要，我們要求高速數據交換，不要求響應時間

  這一特性在做數據分析的時候沒有問題，但是對于要求相應時間的工作上，后來又提出了許多解決方案，但并沒有實質上改變這一設計初衷

2.2 接口

GFS提供了一套類似傳統文件系統的API接口，雖然并不是嚴格按照POSIX(The Portable Operating System Interface)等標準實現的。

• 快照：快照以很低的成本創建一個文件或者目錄樹的拷貝。
• 記錄追加：操作允許多個客戶端同時對一個文件進行數據追加操作，同時保證每個客戶端的追加操作都是原子性的。這對于實現多路結果合并，以及生產者-消費者隊列非常有用，多個客戶端可以在不需要額外的同步鎖定的情況下，同時對一個文件追加數據。

2.3 架構

• Master 節點：

  管理所有的文件系統元數據。這些元數據包括名字空間、訪問控制信息、文件和 Chunk 的映射信息、以及當前 Chunk 的位置信息。 Master 節點還管理著系統范圍內的活動，比如， Chunk 租用管理（Lease）、（orphaned ）孤兒 Chunk的回收、以及 Chunk 在 Chunk 服務器之間的遷移。 Master 節點使用心跳信息周期地和每個 Chunk服務器通訊，發送指令到各個 Chunk 服務器并接收 Chunk 服務器的狀態信息。

• Chunk節點：

  在 Chunk 創建的時候， Master 服務器會給每個 Chunk 分配一個不變的、全球唯一的 64 位的 Chunk 標識。 Chunk 服務器把 Chunk 以 Linux 文件的形式保存在本地硬盤上，并且根據指定的 Chunk 標識和字節范圍來讀寫塊數據。

無論是客戶端還是 Chunk 服務器都不需要緩存文件數據，不過客戶端會緩存元數據。 Chunk 服務器不需要緩存文件數據的原因是， Chunk 以本地文件的方式保存， Linux 操作系統的文件系統緩存會把經常訪問的數據緩存在內存中。

2.4 單一Master節點

客戶端并不通過 Master 節點讀寫文件數據。反之，客戶端向 Master 節點詢問它應該聯系的 Chunk 服務器。客戶端將這些元數據信息緩存一段時間，后續的操作將直接和 Chunk 服務器進行數據讀寫操作。

根據Figure 1。

• 首先，客戶端把文件名和程序指定的字節偏移，根據固定的 Chunk 大小，轉換成文件的 Chunk 索引。然后，它把文件名和 Chunk 索引發送給 Master 節點。 Master 節點將相應的 Chunk 標識和副本的位置信息發還給客戶端。客戶端用文件名和 Chunk 索引作為 key 緩存這些信息。
  • 之后客戶端發送請求到其中的一個副本處，一般會選擇最近的。

請求信息包含了 Chunk 的標識和字節范圍。在對這個 Chunk 的后續讀取操作中，客戶端不必再和 Master 節點通訊了，除非緩存的元數據信息過期或者文件被重新打開。客戶端通常會在一次請求中查詢多個 Chunk 信息， Master 節點的回應也可能包含了緊跟著這些被請求的 Chunk 后面的 Chunk 的信息。

在實際應用中，這些額外的信息在沒有任何代價的情況下，避免了客戶端和 Master 節點未來可能會發生的幾次通訊。

2.5 chunk尺寸和元數據

• chunk尺寸

  Chunk 的大小是關鍵的設計參數之一。我們選擇了 64MB，這個尺寸遠遠大于一般文件系統的 Block size。每個 Chunk 的副本都以普通 Linux 文件的形式保存在 Chunk 服務器上，只有在需要的時候才擴大。

  這種chunk尺寸可以減少對master節點的請求；可以保持長的tcp請求；減少元數據

  同時缺點也非常明顯，小文件只有一個chunk的話可能會導致熱點問題

• 元數據：

  Master 服務器存儲 3 種主要類型的元數據，包括：文件和 Chunk 的命名空間、文件和 Chunk 的對應關系、每個 Chunk 副本的存放地點。所有的元數據都保存在 Master 服務器的內存中。前兩種類型的元數據同時也會以記錄變更日志的方式記錄在操作系統的系統日志文件中，日志文件存儲在本地磁盤上，同時日志會被復制到其它的遠程 Master服務器上。

2.6 一致性模型

3. 系統交互

原則：最小化所有操作和Master節點的交互。

1. 使用租約lease機制來保持多個副本間變更順序的一致性

2. 數據流

   沿著Chunk服務器數據鏈進行推送，接受數據的Chunk服務器同時通過管道在全全雙工的模式下向距離自己最近的同時也在鏈路上的Chunk服務器推送。在沒有網絡阻塞的情況下，傳送B字節到R個副本的理想時間B/T+L*R，T是吞吐量，L是兩臺機器之間的傳輸延遲。

3. 原子記錄增加

   GFS 提供了一種原子的數據追加操作–記錄追加。傳統方式的寫入操作，客戶程序會指定數據寫入的偏移量。對同一個 region 的并行寫入操作不是串行的： region 尾部可能會包含多個不同客戶機寫入的數據片段。使用記錄追加，客戶機只需要指定要寫入的數據。 GFS 保證至少有一次原子的寫入操作成功執行（即寫入一個順序的 byte 流），寫入的數據追加到 GFS 指定的偏移位置上，之后 GFS 返回這個偏移量給客戶機。這類似于在 Unix 操作系統編程環境中，對以 O_APPEND 模式打開的文件，多個并發寫操作在沒有競態條件時的行為。

4. 快照

   使用copy-on-write技術實現快照。

   當 Master 節點收到一個快照請求，它首先取消作快照的文件的所有 Chunk 的租約。這個措施保證了后續對這些 Chunk 的寫操作都必須與 Master 交互以找到租約持有者。這就給 Master 節點一個率先創建Chunk 的新拷貝的機會。

4. Master節點的操作

1. 名稱空間和鎖

   我們不希望在一些工作量較大的master節點的操作的運行時，延緩了其它的 Master 節點的操作。因此，我們允許多個操作同時進行，使用名稱空間的 region 上的鎖來保證執行的正確順序。 因為名稱空間可能有很多節點，讀寫鎖采用惰性分配策略，在不再使用的時候立刻被刪除。同樣，鎖的獲取也要依據一個全局一致的順序來避免死鎖：首先按名稱空間的層次排序，在同一個層次內按字典順序排序。

2. 副本的位置

   Chunk 副本位置選擇的策略服務兩大目標：最大化數據可靠性和可用性，最大化網絡帶寬利用率。

3. 創建，重新副本，重新負載均衡

   需要考慮的幾個因素：

   1. 平衡硬盤使用率
   2. 限制同一臺Chunk服務器上進行的創建/復制的操作數量
   3. 在機架間分布副本

4. 垃圾回收

   一開始只做日志標記，將文件隱藏，然后過幾天在做刪除

   所有不能被Master節點識別的副本將被刪除。垃圾回收會分散到各種例行操作里，同時會在Master節點相對空閑的時候完成。master節點會保存副本的版本號確保訪問數據的正確性。

5. 容錯和診斷

• 高可用性：
  • 快速恢復：不管 Master 服務器和 Chunk 服務器是如何關閉的，它們都被設計為可以在數秒鐘內恢復它們的狀態并重新啟動。
  • Chunk復制：雖然 Chunk復制策略對我們非常有效，但是我們也在尋找其它形式的跨服務器的冗余解決方案，比如使用奇偶校驗、或者 Erasure codes來解決我們日益增長的只讀存儲需求。
  • Master的復制：對 Master 服務器狀態的修改操作能夠提交成功的前提是，操作日志寫入到 Master 服務器的備節點和本機的磁盤。 GFS 中還有些“影子” Master 服務器，這些“影子”服務器在“主” Master 服務器宕機的時候提供文件系統的只讀訪問。 這里要注意，我們都知道Namenode在Master上，但是SecondaryNamenode并不是其備份，而是輔助Namenode工作的。并不是這里提到的備用節點
• 數據完整性：每個 Chunk 服務器必須獨立維護 Checksum 來校驗自己的副本的完整性 。和其它元數據一樣，Checksum 與其它的用戶數據是分開的，并且保存在內存和硬盤上，同時也記錄操作日志。 Checksum 的計算可以和 I/O 操作同時進行。
• 診斷工具：GFS 的服務器會產生大量的日志，記錄了大量關鍵的事件（比如， Chunk 服務器啟動和關閉）以及所有的 RPC 的請求和回復。

6. 實驗，一些經驗，相關工作

這里這里主要說一下相關工作

AFS類似，GFS 提供了一個與位置無關的名字空間 ：John Howard, Michael Kazar, Sherri Menees, David Nichols, Mahadev Satyanarayanan, Robert Sidebotham, and Michael West. Scale and performance in a distributed file system. ACM Transactions on Computer Systems,6(1):51–81, February 1988

和其它的大型分布式文件系統，比如 AFS類似， GFS 提供了一個與位置無關的名字空間，這使得數據可以為了負載均衡或者災難冗余等目的在不同位置透明的遷移。不同于 AFS 的是， GFS 把文件分布存儲到不同的服務器上，這種方式更類似 Xfs[1]和 Swift[3]，這是為了提高整體性能以及災難冗余的能力。

Xfs:Thomas Anderson, Michael Dahlin, Jeanna Neefe, David Patterson, Drew Roselli, and Randolph Wang.Serverless networkfil e systems. In Proceedings of the 15th ACM Symposium on Operating System Principles, pages 109–126, Copper Mountain Resort, Colorado, December 1995.

Swift:Luis-Felipe Cabrera and Darrell D. E. Long. Swift: Using distributed disks triping to provide high I/O data rates. Computer Systems, 4(4):405–436, 1991.

GFS 很類似 NASD 架構[4]。 NASD 架構是基于網絡磁盤的，而 GFS 使用的是普通計算機作為 Chunk 服
務器，就像 NASD 原形中方案一樣。所不同的是，我們的 Chunk 服務器采用惰性分配固定大小的 Chunk 的方
式，而不是分配變長的對象存儲空間。此外， GFS 實現了諸如重新負載均衡、復制、恢復機制等等在生產環
境中需要的特性。

Garth A. Gibson, David F. Nagle, Khalil Amiri, Jeff Butler, Fay W. Chang, Howard Gobioff, Charles Hardin, ErikR iedel, David Rochberg, and Jim Zelenka. A cost-effective, high-bandwidth storage architecture. In Proceedings
of the 8th Architectural Support for Programming Languages and Operating Systems, pages 92–103, San Jose,
California, October 1998.

我們通過原子的記錄追加操作實現了生產者-消費者隊列，這個問題類似 River[2]中的分布式隊列。 River
使用的是跨主機的、基于內存的分布式隊列，為了實現這個隊列，必須仔細控制數據流；而 GFS 采用可以被
生產者并發追加記錄的持久化的文件的方式實現。 River 模式支持 m-到-n 的分布式隊列，但是缺少由持久化
存儲提供的容錯機制， GFS 只支持 m-到-1 的隊列。多個消費者可以同時讀取一個文件，但是它們輸入流的區
間必須是對齊的。

Remzi H. Arpaci-Dusseau, Eric Anderson, Noah Treuhaft, David E. Culler, Joseph M. Hellerstein, David
Patterson, and Kathy Yelick. Cluster I/O with River: Making the fast case common. In Proceedings of the Sixth
Workshop on Input/Output in Parallel and Distributed Systems (IOPADS ’99), pages 10–22, Atlanta, Georgia, May

1. ?