分散式儲存技術解讀系列之GFS

1. 什麼是GFS?

首先，我們從 GFS 的定義：“Google File System (GFS) is a scalable distributed file system (DFS) created by Google Inc. and developed to accommodate Google’s expanding data processing requirements. GFS provides fault tolerance, reliability, scalability, availability and performance to large networks and connected nodes . ” 。當中我們可以非常明確看到 GFS區別於Ceph和SWift的核心在於它是一個檔案系統，但是這個檔案系統又是區別於我們Linux作業系統上普通的EXT檔案系統，它具有分散式架構，因此它被賦予了以下特性 ：

(1) 擴充套件性 ( Scalability ) ：它具備較強的架構擴充套件性，可以使得資料規模很容易擴充套件到PB級別;

(2) 高可用( availability )：它具備較強的叢集高可用性，能解決節點故障對叢集的可用性影響 ;

(3) 容錯性 ( Fault Tolerance )：它具備很強的資料容錯性，能解決資料錯誤的問題 ;

除此之外，我們還要知道它的來源，它是谷歌的傑出作品，是谷歌三駕馬車(GFS、Big Table、Mapreduce)三個當中的一個，而且對應著谷歌著名的三篇論文當中的一篇，支援所有谷歌服務的基石。接下來，我們 從各個維度來分析究竟是什麼樣的架構和原理使它具備了這樣的分散式特性 。

2. GFS 架構原理

2.1 GFS物理架構

從 物理節點角度看GFS的架構，它主要分為三個部分：Client、Master Server、Chunk Server。應用的資料讀寫請求從Client端發起，先經過Master Server查詢後設資料資訊，得到後設資料資訊之後再到Chunk Server尋找資料本身或者寫入資料本身。如圖2.1：

圖2.1 GFS物理拓撲圖

Client：是GFS提供給應用程式的訪問介面，它是一組專用介面，以庫檔案的形式提供。應用程式直接呼叫這些庫函式來獲取資料的訪問。它的輸入僅僅需要檔名稱及其在GFS系統當中的全路徑。

Master：是GFS的叢集管理節點，可以是主備模式，當然也可以是AA模式的叢集。但是它的資料空間只有一個。它主要負責儲存GFS的後設資料及叢集的協調管理。

Chunk：它是儲存資料的節點，它可以擴充套件為很多。它主要負責響應客戶端的實際資料讀寫，資料以檔案的形式儲存在Chunk Server上，檔案組織的粒度為Chunk(預設為64M)。既然是檔案系統的儲存管理方式，那必然是Chunk_ID+Chunk_Address的組織管理模式。

2.2 GFS Master

既然Master是GFS的核心管理節點，那麼搞清楚Master裡面的運作機制就是搞清楚GFS的必要條件，首先我們來看Master Server儲存的後設資料是什麼樣的?我們在文章前面內容當中曾經說過，GFS排除它的分散式而言，它就是一個檔案系統。既然是檔案系統就會遵循檔案存取的基本規則：客戶端按照全路徑檔名稱存放或者讀取檔案。如圖2.2.1：

圖2.2.1 Master名稱空間圖

對於Master Server上儲存的Metadata來講，主要包含兩個維度的資料，一個是檔案的名稱空間，它是一個樹狀的資料結構，也就是檔案目錄樹。另外一方面，對於這個目錄樹的每一個葉子節點，也就是對應的每一個檔案的後設資料，它是一組Key-Value(Chunk標識，Chunk_Servers )。還有一點非常重要，那就是以上所述的Metadata，會在Master節點的記憶體當中保留快取，其主要目的是為了快速返回客戶端的後設資料請求。

除了後設資料的管理，Master還有比較重要的工作就是對Chunk Server的管理。如圖2.2.2：

圖2.2.2 GFS Master and Chunk

Master需要和Chunk Server進行互動，從而收集一些必要資訊(Chunk Server上的檔案對映關係更新版本、Chunk Server節點本身以及它的磁碟及資料副本健康狀況)。另外，根據收集的資訊決定其下一步對Chunk Server的控制操作，包括更新自己的後設資料資訊，告訴Chunk Server從別的Chunk Server副本來複制完成對損壞資料的恢復，定期對資料分佈的平衡性進行評估並通知Chunk Server去做資料的再平衡，重新仲裁資料副本的主節點等。

2.3 GFS Chunk Server

對於Chunk Server來講，其實它就是負責具體儲存檔案本身的伺服器節點，它可以橫向擴張其節點數量，有較強的伸縮性。對於它的理解，我們需要掌握以下幾個點：

1.每一個Chunk Server都是安裝了Linux作業系統的伺服器節點，檔案系統都是普通Linux FS(例如ext3);

2.每一個儲存塊Chunk都是檔案，遵守檔案系統I節點對映的規則;

3.每一個Chunk預設為64M;

4.GFS對Chunk Server裡面的檔案系統後設資料不做快取，它的快取只是Linux作業系統自身的快取。

3. GFS讀寫原理

3.1 GFS資料副本控制

對於分散式系統來講，GFS採用的是中心化副本控制協議，即對於副本集的更新操作有一箇中心節點來協調管理，將分散式的併發操作轉化為單點的併發操作，從而保證副本集內各節點的一致性。在GFS中，中心節點稱之為Primary，非中心節點稱為Secondary。中心節點是GFS Master透過lease選舉的 。

圖 3.1 資料副本控制機制

從圖 3 . 1 當中，我們可以看到 資料寫的過程是三副本都正常返回才算一個完整的寫完成。當Master節點透過與Chunk節點之間的探測之後，發現當中的主節點發生故障，Master節點會利用Lease選舉機制重新選擇新的主Chunk節點，並且通知Chunk發起資料複製恢復的操作，直到所有操作完成將Chunk對映後設資料同步給Master。

雖然我們從圖中可以看到完整有序的控制資訊序列，但是在Chunk節點之間的資料複製同步過程當中，這個操作是動態的。GFS會賦予Chunk節點一種最優路徑選擇機制，讓他們自己決定如何資料同步路由。

3.2 GFS Chunk資料分佈演算法

GFS中Chunk以多副本的形式儲存以提高資料的高可用性。那麼如何選擇各Chunk資料的存放位置就顯得直觀重要，好的Chunk位置定義演算法滿足幾個條件：

1.保證足夠的物理故障隔離性，將不同的Chunk資料副本存放於不同的故障隔離域;

2.保證寫入高效性，多副本位置儘量靠近，降低寫入延遲，提高讀寫效能。

GFS在論文中並沒有詳細說明其資料的分佈演算法，但是基本說明了演算法的基本原則：

1.選擇儲存空間利用率最低的節點和磁碟;

2.選擇最近一段時間內新建Chunk數量較少的節點和磁碟;

3.將多個副本分散在不同的Rack上。

4. 結語

總結來看，GFS作為分散式儲存技術體系的一個分支，但是它與我們曾經介紹的Ceph、Swift都有很大的區別，首先、它的底層架構是基於檔案系統實現的分散式儲存系統，因此管理資料的方式也是傳統的檔案模式。其次、它是一個有中心狀態的架構，需要藉助於Master節點的後設資料查詢來實現資料的定址，並不是透過雜湊演算法的來定位，因此它的擴充套件性會受到Master節點本身空間的限制。再次、從它的檔案儲存單元預設設計引數64M來看，它是一個適合於儲存大檔案的分散式檔案系統。最後，GFS在資料讀寫的過程當中，僅對Append提供原子性，因此它更適合於順序寫的場景。