Google 雲計算中的 GFS 體系結構

      google 公司的不少業務具備數據量巨大的特色，爲此，google 公司研發了雲計算技術。google 雲計 算結構中的 google 文件系統是其雲計算技術中的三大法寶之一。本文主要介紹了 google 公司根據本身公司應 用對文件系統的要求設計的 GFS 的體系結構，首先簡單介紹了 google 雲計算平臺，而後介紹了 google 公司 設計的 GFS 框架，對其中的三類組件的功能、組件之間的交互和框架的特色進行了說明，接着經過介紹基於 GFS 框架構建的 google 文件系統，說明了 GFS 的框架中的組件是如何合做來完成 GFS 中的一些操做，最後 分析了 GFS 的質量屬性，從中能夠看到 GFS 框架很好的知足了 google 應用對文件系統的要求。 

1 Google 雲計算平臺
1.1 雲計算
　　雲計算是一種利用互聯網實現隨時隨地、按需、便捷地訪問共享資源池的計算模式。「雲」指的是一些可 以自我維護和管理的虛擬計算機資源，計算機羣，一般是一些大型服務器集羣，包括計算服務器、存儲服務 器和寬帶資源等。在雲計算環境中，用戶不須要了解「雲」中基礎設施的細節，也不須要知道「雲」的相應專業知識，只須要關注本身真正須要什麼資源，如何經過網絡獲得服務。從用戶的角度來看，「雲」中的資源 是能夠無限擴展的，只要經過網絡接入數據中心，就能隨時獲取、實時使用、按需擴展計算和存儲資源。它 具備資源共享、無多餘功能開發、資源共享、系統延續性好等特色。 

1.2 google雲計算
　　Google 是最大的雲計算技術的使用者，它擁有全球最大的搜索引擎。爲了解決搜索引擎以及其它的大規 模業務的海量數據存儲和快速處理問題，它研發出了讓百萬臺計算機協同工做的技術。Google 雲計算平臺體 系架構包括 4 個相互獨立又緊密結合在一塊兒的系統：Google 創建在集羣之上的 Google File System 分佈式操 做系統，針對 google 應用程序的特色提出的 Map/Reduce 編程模式，分佈式的鎖機制 Chubby 以及 google 開 發的模型簡化的大規模分佈式數據庫 BigTable。 Google 已發表的論文，認爲其雲計算的三大法寶是：體系架構中的 Google File System(GFS)、MapReduce 和 Bigtable。其中，Google File System，即 google 文件系統，是一種分佈式的文件系統。

2 GFS 體系架構
　　GFS 架構中有三類角色：客戶（client）、主服務器（master server）和數據塊服務器（chunk server）。這 三類角色的節點會構成一個 GFS 羣，這個羣包含一個單個的 Master 節點、多臺 Chunk 服務器，多個客戶端， 下面對這三類角色進行介紹。

圖片待整理

2.1 各組件的介紹
2.1.1 Client

　　所謂的 client，是一套相似於傳統文件系統的 API 接口函數，是一組專用接口，不遵照 POSIX 規範，應 用程序經過訪問這些接口來實現操做，支持經常使用的操做，如建立新文件、刪除文件、打開文件、關閉文件、 讀和寫文件，另外，還提供了快照和記錄追加操做。根據 google 應用程序的具體狀況，提供記錄追加操做是 由於對文件的隨機寫入操做幾乎不存在，讀操做也一般是按順序的，絕大部分文件的修改是採用在文件尾部 追加數據，這樣的記錄追加操做容許多個客戶端同時對一個文件進行數據追加，對於實現多路結果合併，以 及「生產者-消費者」隊列很是有用。而且記錄追加操做要保證每一個客戶端的追加操做都是原子性的，多個客 戶端能夠在不須要額外的同步鎖定的狀況下，同時對一個文件追加數據。快照以很低的成本，幾乎瞬間完成 建立一個文件或者目錄樹的拷貝。提供快照操做能夠迅速建立一個巨大的數據集的分支拷貝，或備份當前的操做狀態從而之後可以輕鬆的提交或者回滾到備份時的狀態。客戶端代碼封裝爲庫函數，以庫函數的方式提 供給客戶程序，被連接到客戶程序裏，它實現了文件系統的接口函數，應用程序與 master 節點和 chunk 服務 器通信，以及對數據進行讀寫操做。 

2.1.2   Chunk 服務器

　　Chunk 服務器負責具體的存儲工做，它要作的是把 chunk 保存在本地硬盤上、讀寫塊數據。存儲的文件 都被分紅固定大小的 chunk，每個 chunk 在建立時會被 master 分配一個不變的、全球惟一的 64 位 chunk 標 識，chunk 服務器要根據這個標識和字節範圍來讀寫塊數據，chunk 在保存時是以本地文件形式保存的。爲了 保證可靠性，Chunk 在不一樣的機器中複製多份，默認爲三份，副本的有三個用途：Chunk 建立，從新複製和 從新負載均衡。Chunk 的複製是由 master 負責的。 2.1.3   Master 節點 Master 節點管理全部的文件系統元數據、管理系統範圍內的活動。master 服務器存儲的元數據有三類： 文件和 chunk 的命名空間、文件和 chunk 的對應關係、每一個 chunk 副本的存放地點。這些信息存儲在 master 服務器的內存中，保證了 master 服務器的操做速度。前兩種類型的元數據也會以記錄變動日誌的方式記錄在 操做系統的系統日誌文件中，而日誌文件存儲在本地磁盤上，同時日誌會被複制到其餘的遠程 master 服務器 上。第三種元數據 chunk 的存放地點不會被持久保存，只是在 master 服務啓動或者有新的 chunk 服務器加入 時，由 master 向各個 chunk 服務器輪詢他們所存儲的 chunk 信息。master 管理的系統範圍內的活動，好比， 管理整個系統內全部 chunk 的副本，決定 chunk 的存儲位置，建立新 chunk 和它的副本，協調各類各樣的系 統活動以保證 chunk 被徹底複製，在全部的 chunk 服務器之間進行負載均衡，回收再也不使用的存儲空間等。 

2.2 各組件之間的交互
2.2.1 Client 與 master 節點

　　Client 在訪問文件系統時，首先訪問 master 節點，獲取與之進行交互的 chunk 服務器信息，而後直接訪 問這些 chunk 服務器，完成數據存取工做，client 並不經過 master 節點讀寫文件數據，經過這樣減小對 master 節點的讀寫，能夠避免大量的讀寫操做形成的 master 節點成爲系統的瓶頸，而且客戶端一般會在一次請求中 查詢多個 chunk 信息，避免了客戶端和 master 節點的屢次通信。在客戶端上的應用程序須要向主服務器發送 要操做的文件名和 chunk 索引，向主服務器查詢所要操做的文件的具體的 chunk 位置。主服務器在收到客戶 端的信息後返回給客戶端 chunk 句柄和 chunk 的位置。 2.2.2 Client 與 chunk 服務器 客戶端在獲得主服務器的 chunk 句柄和 chunk 位置後，能夠根據這些信息訪問具體的 chunk 服務器，即 GFS 數據塊服務器，得到文件數據。client 能夠直接訪問 chunk 服務器，從 chunk 服務器中獲得 chunk 數據。 2.2.3 Master 與 chunk 服務器 Master 節點使用心跳信息週期地和每一個 chunk 服務器通信、發送指令到各個 chunk 服務器並接受 chunk 服務器的狀態信息，這樣也能保證 master 服務器持有的信息始終是最新的。在 master 服務啓動或者有新的 chunk 服務器加入時，master 要向各個 chunk 服務器輪詢他們所存儲的 chunk 信息。Master 與 chunk 服務器之 間，master 想 chunk 服務器發送指令，chunk 服務器向 master 發送數據塊服務器狀態。
2.3 GFS架構的特色
　　(1)採用單一的 master 節點策略。單一的 master 節點策略可以簡化分佈式文件系統的設計，能夠經過 全局的信息精肯定位 chunk 的位置以及進行復制策略，因爲只有一個 master，全部的雲數據只有一 份，於是不存在元數據的一致性問題。

　　(2) 採用中心服務器模式。某些分佈式文件系統的架構，好比 xFS、GPFS，去掉了中心服務器，只依賴 於分佈式算法來保證一致性和關聯性。選擇中心服務器的方法可以簡化設計，增長可靠性，可以靈 活擴展，能夠方便的增長 chunk 服務器，而且因爲中心服務器能夠獲知全部子服務器的狀態，於是能夠很方便的得知各個子服務器的負載情況等。可是中心服務器模式也有一個比較致命的缺點，那 就是單點故障，當單點故障發生在中心服務器時，將致使整個系統的不可用。另外，經過一些具體 的設計可以使分佈式文件系統的性能獲得保證： 

　　　　(a)經過由處於中心位置的 Master 服務器保存幾乎全部的 Chunk 相關信息、控制 Chunk 的全部變 更記錄，可以極大地簡化本來很是複雜的 Chunk 分配和複製策略的實現方法，而且方便進行 負載均衡。所謂負載均衡是 master 在全部 chunk 服務期間進行的負載均衡，master 檢查副本 的分佈狀況，而後移走那些剩餘空間低於平均值的 chunk 服務器上的副本，從而更好的利用硬 盤空間，平衡系統總體的硬盤使用率。

　　　　(b)經過減小 Master 服務器保存的狀態信息的數量，將 Master 服務器的狀態複製到其它節點，能 夠保證了系統的災難冗餘能力。對 Master 服務器狀態的更改能夠經過預寫日誌的方式實現持 久化。

　　　　(c) 經過影子 Master 服務器機制保證了系統的擴展能力和高可用性。影子服務器在主 Master 服務 器宕機的時候提供文件系統的只讀訪問。對於那些不常常改變的文件、或者那些容許獲取的 數據有少許過時的應用程序，影子 Master 服務器可以提升讀取的效率。 

　　(3)client 和 master 之間只有控制流，而沒有數據流，因爲控制流只需傳送指令和狀態，數據量小，這 點可以下降了 master 的負載，提升 master 的速度。　　　　

　　(4)client 與 chunk 服務器之間可以直接傳輸數據流，同時因爲文件被分紅多個 chunk 進行分佈式存儲， 所以 client 能夠同時並行訪問多個 chunk 服務器，從而提升了系統的 I/O 並行度。

3 GFS 架構應用
　　GFS 的框架是 google 公司針對自身應用程序的狀況設計的，在這個框架上搭建了 GFS，即 google 文件系 統。
3.1 GFS
　　GFS 是 Google 雲存儲的基石，其它存儲系統，如 Google Bigtable，Google Megastore，Google Percolator 均直接或者間接地構建在 GFS 之上。另外，Google 大規模批處理系統 MapReduce 也須要利用 GFS 做爲海量 數據的輸入輸出。GFS 除了擁有過去的分佈式文件系統的可伸縮性、可靠性、可用性等特色外，它的設計還 受到 Google 應用負載和技術環境的影響，GFS 在設計上的特色有如下幾點：

　　 服務器集羣中個別服務器的故障是一種正常現象，而不是意外事件。因爲 google 集羣的節點數目非 常龐大，使用上千個服務器進行共同計算，每時每刻總會有服務器處於出故障狀態，它經過軟件程 序模塊，監視系統的動態運行情況，偵測錯誤，將容錯以及自動回覆系統集成在系統中。

　　 Google 系統中的文件大小一般以 G 字節計，這一點與一般文件系統中的文件大小概念不同，並 且一個大文件可能包含大量數目的一般意義上的小文件。這一點會影響設計預期和參數，好比塊尺 寸和 I/O 操做。

　　 絕大部分文件的修改是採用在文件尾部追加數據，而不是覆蓋原有數據的方式。

　　 應用程序和文件系統 API 協同設計，提升了整個系統的靈活性。

3.2 基於GFS框架的GFS實現
　　Google 針對不一樣的應用部署多套 GFS 集羣，一個 GFS 集羣包含一個單個的 Master 節點、多臺 Chunk 服 務器，而且被多個客戶端訪問。全部的做爲 master、chunk、client 的節點機器一般都是普通的 linux 機器。

　　Google 文件系統的全部操做的實現都是經過 Master、client 與 chunk 服務器之間的交互來完成的，包括創 建新文件、刪除文件、打開文件、關閉文件、讀寫文件、追加記錄和快照功能。這裏介紹這三類組件經過交 互實現的簡單的讀操做、寫操做。

3.2.1 讀操做

　　客戶端請求讀操做時，主要是向 master 節點詢問應聯繫的 chunk 服務器，獲得相關的元數據信息後，直 接和 chunk 服務器進行數據讀操做。

　　具體的交互過程以下： 首先，客戶端與 master 的交互。客戶根據固定的 chunk 大小，把文件名和程序制定的字節偏移轉換成文 件的 chunk 索引，再把文件名和轉換獲得的 chunk 索引起送給 master 節點。master 節點根據保存在內存中的 元數據，將相應的 chunk 標識和副本的位置信息發還給客戶端。客戶端用文件名和 chunk 索引做爲關鍵字緩 存獲得的 chunk 標識和副本位置信息。

　　而後是客戶端與 chunk 服務器的交互。客戶端從副本中選擇一個最近的副本發送讀操做請求。請求信息 包括 chunk 標識和字節範圍。

3.2.2 寫操做

　　客戶端請求寫操做時，主要是向 master 節點詢問應聯繫的 chunk 服務器，獲得相關的元數據信息後，直接對 chunk 服務器和全部的副本進行數據寫操做。

　　在介紹寫操做的交互前要引入 GFS 中的租約機制。所謂租約機制就是設定一個主 chunk，由主 chunk 來 對全部的更改操做進行序列化，從而保證多個副本間變動順序的一致性。持有租約的 chunk 副本爲主 chunk， chunk 的租約是由 Master 節點創建的。

　　具體的交互過程以下： 首先，客戶端與 master 的交互。客戶機詢問 master 節點哪個 chunk 服務器持有租約，以及其它副本的 位置。若 master 沒有找打持有租約的 chunk，則爲其中一個副本創建一個租約。Master 返回給客戶端 Chunk 的標識符和其它副本的位置。客戶機緩存 chunk 的標示符和其餘副本位置。

　　而後是客戶端和 chunk 服務器的交互。客戶端以任意的順序把數據推送到全部的副本上。Chunk 服務器 將接受到的數據保存在它的內部 LRU 緩存中。全部的副本確認接收到了數據後，客戶機主 Chunk 服務器發 送寫請求。這個請求標識了早前推送到全部副本的數據。

　　最後是主 chunk 和其餘副本之間的交互。主 Chunk 爲接收到的全部操做分配連續的序列號，而後以序列 號的順序把操做應用到它本身的本地狀態中。主 Chunk 把寫請求傳遞到全部的副本。每一個副本依照序列號的 順序執行這些操做。在完成操做後，全部的副本回復主 Chunk 它們已經完成了操做。

　　主 Chunk 服務器回覆客戶機。在這個過程當中，任何副本產生的任何錯誤都會返回給客戶端。
4 GFS 質量屬性
4.1 可靠性
　　GFS 具備高可靠性，雖然 GFS 集羣中的節點採用的是可靠性較差的普通 PC，可是 GFS 針對節點失效的 問題提供了 master 容錯和 master 備份。另外有提供了數據校驗、負載均衡和心跳消息機制來保證 GFS 的高 可靠性。

　　Master 服務器內存中保存着元數據，其中文件和 chunk 的命名空間和映射表的變動記錄在操做日誌中， 經過這種方式，對兩種元數據提供了容錯功能，而 chunk 副本位置信息保存在各個 chunk 服務器上，所以如 果磁盤數據保存無缺的話，在 master 發生故障時可以迅速恢復以上元數據。

　　Master 備份了 master 的狀態、操做記錄和檢查點，這樣，master 或硬盤失敗的話，系統監視器會發現並 經過改變域名啓動它的一個備份機，而因爲客戶端僅僅是使用名稱來當問，所以不會發現 master 服務器的改 變。

　　在讀取 chunk 副本時，chunk 服務器會將讀取的數據和檢驗和進行比較，若是不匹配就會返回錯誤，然 後使客戶端選擇其餘 chunk 服務器上的副本。

　　Master 經過按期從新進行均衡，把副本調整到更好的磁盤和負載分佈，不會致使 chunk 服務器的過載。

　　Chunk 服務器會週期性的主動想 master 報告運行狀態和數據狀態，若是必定時間內 master 沒有收到這些 信息，就認爲 chunk 服務器已經宕機，而後進行復制來保證設置的副本數。
4.2 可用性
　　系統的可用性定義系統正常運行的時間比例，系統的可用性關注如下幾個方面：如何檢測系統故障，出 現故障時會發生什麼狀況，何時能夠安全地出現故障，如何防止故障的發生，發生故障時要求進行哪些 通知等。

　　GFS 在設計時採起個別服務器的故障是一種正常現象的策略，爲了保證系統的正常運行，GFS 經過軟件 程序模塊，監視系統的動態運行情況，偵測錯誤，並將容錯以及自動恢復系統集成在系統中。這一點是經過 兩種策略來實現的：快速恢復和複製。快速恢復是指在 master 服務器或 chunk 服務器發生故障時，他們能夠 在數秒內恢復他們的狀態並從新啓動。複製包括 chunk 的複製和 master 服務器的複製。

　　當有 chunk 服務器離線，或發現損壞的數據時，master 節點會克隆已有的副本，保證每一個 chunk 都被完 整複製。這樣的複製使得能夠對 chunk 服務器的失效進行容錯。在主服務器宕機時，影子 master 服務器會提 供系統的只讀訪問。

　　另外，在系統故障的檢測方面，GFS 經過持續監控來檢測系統中是否有故障。
4.3 性能
　　性能這一質量屬性常常用在單位時間內所能完成的處理數量或系統爲完成一個處理所要消耗的時間來表 示。在 GFS 的性能方面，主要經過兩種途徑來保證系統的性能。一方面是避免 master 成爲系統性能的瓶頸， 保證系統能快速的響應，處理請求。另外一方面是經過緩存機制的應用使用來提升訪問速度。

　　防止 master 成爲系統性能的瓶頸。GFS 經過控制元數據的規模、對 Master 進行遠程備份、控制信息和 數據分流等機制來實現的。

　　緩存機制的合理應用。GFS 在 chunk 服務器中不提供緩存機制，而對於 master 中存儲的元數據採用了緩 存策略。雖然緩存機制是提高文件系統性能的一個手段，可是對於 GFS 的應用場景，客戶端大部分是流式順 序讀寫，並不存在大量的重複讀寫，緩存數據對系統性能提升做用不大。另外一方面，master 須要對其元數據 進行頻繁操做，經過緩存機制可以提升操做的效率。所以對於系統性能的提高有幫助。
5 結論
　　經過上述調研，針對 google 公司具體狀況而設計的 GFS 框架將一個計算機羣分爲三類角色：客戶、主 服務器和數據塊服務器，客戶提供一系列操做的接口，數據塊服務器存放文件的數據塊，主服務器管理全部 的文件系統元數據、管理系統範圍內的活動，這個框架的設計不只具備可伸縮性、可靠性、可用性等特色， 還知足了 google 的應用負載和技術環境。其中的一些思想，也能夠應用在其餘分佈式文件系統的設計中。

文中參考:

史強. GFS雲存儲技術可靠性簡介[J]. 福建電腦, 2012, 28(1): 76-77.
劉鵬. 雲計算[M]. 北京:電子工業出版社. 2011.
萬川梅. 雲計算應用技術[M]. 成都:西南交通大學出版社. 2013.
李天目，韓進. 雲計算技術架構與實踐[M]. 北京:清華大學出版社. 2014.

蔡鍵, 王樹梅. 基於 Google 的雲計算實例分析[J]. 電腦知識與技術: 學術交流, 2009, 5(9): 7093-7095.