Google文件系統（一）

譯自The Google File System

做者：Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung

摘要

咱們設計並實現了面向大規模數據密集型應用的可擴展文件系統GFS。 GFS雖然運行在廣泛硬件設備上，但依然具有災難冗餘能力，爲大量客戶機提供高性能服務。

GFS的設計目標雖然與傳統的分佈式文件系統有不少相同之處，但咱們的設計是基於對Google應用當前和將來負載狀況和技術環境的分析，所以與早期的分佈式文件系統的設想存在明顯的差別。因此咱們從新審視了傳統文件系統，最後得出了徹底不一樣的設計思路。

GFS徹底知足了咱們的存儲需求。做爲存儲平臺，GFS已經在Google內部獲得普遍部署，用於存儲服務產生和處理的數據，同時還支持須要大規模數據集的研究和開發工做。目前爲止，最大的集羣利用數千臺機器的數千個硬盤提供了數百TB的存儲空間，同時服務數百個客戶機。

本文介紹了可以支持分佈式應用的文件系統接口的擴展、GFS的設計、小規模性能測試結果及真實生產系統中的性能相關數據。

1 引言

咱們設計並實現了適用於大規模數據密集型應用的可擴展文件系統GFS，知足Google不斷提升的數據處理需求。GFS在性能、可擴展性、可靠性和可用性方面的設計目標與不少傳統的分佈式文件系統類似。

但GFS的設計主要仍是基於對Google當前和將來應用負載狀況和技術環境的觀察和分析，於是與早期文件系統的設計存在顯著不一樣。基於對傳統文件系統的分析，咱們設計出了全新的分佈式文件系統。

第一，組件失效時常態而非異常。文件系統由數百臺甚至上千臺配置較低的存儲機器構成，每臺客戶機的訪問量很大。組件的數量和質量決定了機器可能會出現故障，且可能沒法恢復。咱們遇到過應用程序bug、操做系統bug、人爲失誤以及硬盤、內存、鏈接器、網絡及電源故障引發的各類問題。所以，GFS必須含有不間斷的監控、錯誤監測、災難冗餘以及自動恢復機制。

第二，文件很大。數GB的文件很是常見。每一個文件通常都包含不少應用程序對象，如web文檔。處理數億個對象構成且快速增加的TB級數據集時，傳統的管理數億個KB級小文件的方式並不適用。 所以，設計時必須從新考慮假設條件和參數，如I/O操做和Block的大小。

第三，對絕大部分文件的修改是採用在文件尾部追加數據而非覆蓋原有數據的方式。現實中幾乎不存在對文件的隨機寫。寫入以後，只能按順序讀取文件。 不少數據都具有這類特徵，好比數據分析程序掃描的大型數據集，正在運行的應用程序連續生成的數據流，存檔數據，以及在一臺機器上生成、另外一臺機器上同步或異步處理的中間數據。對於海量數據的訪問，客戶端的緩存數據塊是沒有用武之地的，數據追加操做纔是性能優化和原子性保證重點。

第四，應用程序與文件系統API的協同設計下降了對GFS一致性模型的要求，在不對應用程序形成負擔的前提下簡化了文件系統。經過原子性追加操做，保證了多個客戶端可以同時進行追加操做，不須要額外的同步操做。下文將對這些問題展開詳細討論。

Google已針對不一樣的應用部署了多套GFS集羣。最大的集羣有1000多個存儲節點，300多TB的硬盤空間，被多臺機器上的數百個客戶端連續頻繁訪問。

2 設計概述

2.1 設計目標

文件系統的設計要有必定的挑戰性和創新空間。以前咱們已經提到了一些關鍵點，如今來詳細討論設計目標。

系統由不少普通商用組件構成，組件失效是常態。系統必須持續監控自身的狀態，迅速偵測、冗餘並恢復失效組件。

系統存儲必定數量的大文件，預期約爲幾百萬，文件的大小一般爲100MB及以上。數GB大小的文件也很常見，且需進行有效管理。系統也須要支持小文件，但不須要對此進行專門的優化。

系統的工做負載主要由兩類讀操做組成：大規模的流式讀取和小規模的隨機讀取。大規模的流式讀取一般一次讀取幾百KB的數據，多位1MB甚至更多的數據。來自同一個客戶機的連續操做一般是讀取同一個文件中的一個連續區域。小規模的隨機讀取一般是從文件的某個隨機位置讀取幾KB數據。 若是應用程序對性能要求很是高，通常會合並並排序小規模的隨機讀取操做，以後按順序批量讀取，從而避免在文件中來回讀取。

系統的工做負載還包括許多大規模的順序追加寫操做。通常狀況下，每次寫入的數據大小與大規模讀相近。一旦寫入後，文件就不多會被修改了。系統支持小規模的隨機位置寫入操做，但效率通常。

系統必須高效地將多個客戶端的數據並行追加到同一個文件裏。咱們的文件一般用於「生產者-消費者」隊列或多路文件合併。一般狀況下，運行在不一樣機器上的數百個生產者會同時對一個文件進行追加操做，所以，以最小的同步開銷實現原子性多路數據追加操做很是重要。消費者可稍後讀取文件，也能夠在追加的同時讀取。

高性能的穩定網絡帶寬比低延遲更重要。咱們絕大多數目標程序要求可以快速大批量地處理數據，不多有程序對單一的讀寫操做有嚴格的響應時間要求。

2.2 接口

GFS提供了一套相似傳統文件系統的API接口函數，但接口並非嚴格按照POSIX等標準API的形式實現的。文件以分層目錄的形式組織，用路徑名來標識。咱們支持經常使用的操做，包括建立、刪除、打開、關閉以及讀寫文件。

另外，GFS可以快照並記錄追加操做。快照能以較低的成本建立文件或目錄樹副本。記錄追加操做支持多個客戶端同時對一個文件進行數據追加操做，保證每一個客戶端的追加操做都是原子性的。這對於實現多路結果合併及「生產者-消費者」隊列很是有用，多個客戶端能夠在不須要額外同步鎖定的狀況下，同時對一個文件追加數據。咱們發現這類文件對於構建大型分佈應用很是重要。快照和記錄追加操做的功能將在第3.4和3.3節分別討論。

2.3 架構

一個GFS集羣包含一個Master節點和多臺數據塊服務器，同時被多個客戶端訪問，如圖1所示。這些機器通常是商用Linux機器，運行着用戶級的服務進程。只要機器資源容許，且可以接受不可靠應用程序代碼對穩定性的影響，即可以把數據塊服務器和客戶端部署在同一臺機器上。

圖1 GFS架構

GFS存儲的文件都被分割成固定大小的數據塊。建立數據塊時，Master服務器會給每一個數據塊分配不變且惟一的64位標識。數據塊服務器以Linux文件的形式把數據塊存儲在本地硬盤上，根據指定的數據塊標識和字節範圍讀寫數據塊。爲了提升可靠性，每一個數據塊都會複製到多個數據塊服務器上。缺省條件下，咱們使用3個存儲複製節點，不過用戶能夠爲不一樣的文件命名空間設定不一樣的複製級別。

Master節點管理全部文件系統的元數據，包括命名空間、訪問控制信息、文件和數據塊的映射信息以及當前數據塊的位置信息。Master節點還管理着系統範圍內的相關活動，如數據塊租用管理、孤立數據塊回收以及數據塊在數據塊服務器之間的遷移。

Master節點按期使用心跳信息與每一個數據塊服務器通信，向各個數據塊服務器發送指令，並接收數據塊服務器的狀態信息。

GFS客戶端代碼以庫的形式連接到客戶程序中，客戶端代碼實現了GFS文件系統的API接口函數，並與Master節點和數據塊服務器通信，完成應用程序對數據的讀寫操做。客戶端和Master節點的通訊只獲取元數據，全部的數據操做都是由客戶端與數據塊服務器直接交互完成的。咱們不提供POSIX標準的API功 能，所以GFS API調用不須要深刻到Linux vnode級別。

客戶端和Chunk服務器均不緩存文件數據。客戶端緩存數據幾乎沒有什麼用處，由於大部分程序要麼以流的方式讀取大型文件，要麼工做集太大根本沒法被緩存。不考慮緩存問題也簡化了客戶端和整個系統的設計和實現。（但客戶端會緩存元數據。）數據塊服務器不須要緩存文件數據，由於數據塊以本地文件的形式保存，Linux操做系統的文件系統緩存會把常常訪問的數據緩存在內存中。

參考資料

1. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google File System
2. Yan Wei. The Google File System中文版