Google文件系統（二）

譯自The Google File System

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

2.4 單一Master節點

單一Master節點大大簡化了設計，能夠經過全局信息精肯定位數據塊的位置並進行復制決策。另外，咱們必須減小對Master節點的讀寫，避免Master節點成爲系統的瓶頸。客戶端不經過Master節點讀寫文件數據，而是向Master節點詢問其應該聯繫的數據塊服務器。客戶端將這些元數據信息緩存一段時間，後續的操做則直接與數據塊服務器交互。

圖1爲一次簡單的讀取流程。首先，客戶端根據固定數據塊的大小把文件名和程序指定的字節轉換成文件的數據塊索引；而後把文件名和數據庫索引起送給Master節點。

圖1 GFS架構

Master節點將相應的數據塊標識和副本的位置信息發還給客戶端。客戶端以文件名和數據塊索引爲key來緩存這些信 息。以後客戶端將請求發送給最近的副本。請求信息包括數據塊標識和字節大小範圍。 若是緩存的元數據信息沒有過時或文件沒有被從新打開，則對該數據塊進行後續讀取操做時，客戶端不須要再與Master節點通信。實際上，客戶端通常會在一次請求中查詢多個數據塊信息，Master節點的迴應也可能包含與被請求數據塊相鄰的數據塊的信息。在實際應用中，這部分額外信息可以減小客戶端和Master節點的通信次數。

2.5 數據塊大小

數據塊大小是一項設計重點。咱們選擇了64MB，遠大於通常文件系統的數據塊大小。每一個數據塊副本都以普通Linux文件的形式保存在數據塊服務器上，須要時能夠擴大。惰性空間分配策略避免了內部碎片形成的空間浪費。

數據塊較大有如下幾項優勢。首先，減小了客戶端和Master節點的通信需求，由於對同一個數據塊的讀寫只須要與Master節點通訊一次便能得到數據塊的位置信息，從而顯著下降工做負載。即便是小規模的隨機讀取，較大的數據塊也帶能讓客戶端輕鬆緩存數TB的工做數據集上全部數據塊的位置信息。其次，支持客戶端對一個塊進行屢次操做，經過與數據塊服務器保持較長時間的TCP鏈接減小網絡負載。第三，減小了 Master 節點須要保存的元數據量。這樣就能夠把全部元數據放在內存中。

另外一方面，即便配合惰性空間分配，採用較大的 Chunk也有其缺陷。小文件的數據塊數量較少，有時只有一個數據塊。多個客戶端訪問同一個小文件時，存儲數據塊的服務器便會變成熱點。在實際應用中，因爲咱們的程序一般是連續讀取包含多個數據塊的大文件，所以熱點還不是主要問題。

但把GFS用於批處理隊列系統時，熱點問題仍是出現了：一個可執行文件在GFS上保存爲單數據塊文件，隨後該文件在數百臺機器上同時啓動。存放該可執行文件的數據塊服務器被數百個客戶端同時訪問，致使系統局部過載。爲了解決這個問題，咱們使用更大的複製參數來保存可執行文件，並錯開批處理隊列系統程序的啓動時間。長效解決方案是容許客戶端從其它客戶端讀取數據。

2.6 元數據

Master服務器主要存儲三種類型的元數據，包括文件和數據塊的命名空間、文件和數據塊的對應關係以及每一個數據塊副本的存儲位置。全部的元數據都保存在Master服務器的內存中。前兩種類型的元數據同時也會以記錄變動日誌的方式持久化Master本地磁盤上，同時也會被複制到遠程機器上。

經過保存變動日誌，可以簡單可靠地更新Master服務器的狀態，且不用擔憂Master服務器崩潰會致使數據不一致。Master服務器不會持久保存數據塊的位置信息。啓動時或新的數據塊服務器加入時，Master服務器向各個數據塊服務器輪詢其所存儲的數據塊的信息。

2.6.1 內存中的數據結構

因爲元數據存儲在內存中，所以Master操做速度很快。此外，Master服務器能夠在後臺簡單高效地週期性掃描其保存的所有狀態信息。這種週期性的狀態掃描也用於數據塊的垃圾收集、數據塊服務器失效時的數據從新複製、經過數據塊的遷移實現跨數據塊服務器的負載均衡以及磁盤使用情況統計等功能。

但把元數據所有保存在內存中也存在問題：數據塊的數量以及整個系統的承載能力都受限於Master服務器的內存大小。但實際應用中，這個問題並不嚴重，由於對於一個64MB的數據塊，其元數據的大小不到64個字節。因爲大多數文件包含多個數據塊，所以除了最後一個數據塊之外，絕大多數數據塊都是滿的。一樣，每一個文件的命名空間數據一般也不到64字節，由於保存的文件名是用前綴壓縮算法壓縮過的。

若是須要支持更大的文件系統，能夠擴大Master服務器內存，以較低的成本把元數據所有保存在內存裏，改善了系統的簡潔性、可靠性、高性能和靈活性。

2.6.2 數據塊位置信息

Master服務器並不會持久化保存數據塊服務器存儲指定數據塊副本的記錄，只是在啓動的時候輪詢服務器，從而獲取這些信息。Master服務器管理着全部數據塊位置的分配，且經過週期性的心跳信息監控數據塊服務器的狀態，於是可以得到最新信息。

最初，咱們計劃把數據塊的位置信息持久保存在Master服務器上，後來發如今啓動的時候輪詢數據塊服務器並按期輪詢更新更簡單。這種設計簡化了數據塊服務器加入集羣、離開集羣、改名、失效以及重啓時，Master服務器和數據塊服務器數據同步的問題。 在由數百臺服務器構成的集羣中，這類狀況會頻繁出現。

從另外一個角度來講，只有數據塊服務器才能最終肯定一個數據塊是否在其硬盤上。咱們沒有考慮在Master服務器上維護這些信息的全局視圖，由於數據塊服務器的錯誤（如硬盤損壞或沒法訪問）可能會致使數據塊自動消失，操做人員也可能重命名數據塊服務器。

2.6.3 操做日誌

操做日誌包含了關鍵元數據的變動歷史記錄，對GFS很是重要。由於操做日誌不只是元數據惟一的持久化存儲記錄，也是判斷同步操做順序的邏輯時間基線。文件數據塊及其版本都由其建立的邏輯時間來惟一永久標識。

操做日誌很是重要，咱們必須妥善保存日誌文件，確保元數據的變動持久化後，這些變動才能對客戶端可見。不然，即便數據塊自己沒有出現任何問題，仍有可能丟失整個文件系統或丟失客戶端最近的操做。因此，咱們會把日誌複製到多臺遠程機器上，把相應的日誌記錄寫入到本地及遠程機器的硬盤後，纔會響應客戶端的操做請求。Master服務器收集多個日誌記錄後進行批量處理，從而減小寫入磁盤和複製對系統總體性能的影響。

在災難恢復時，Master服務器會重放操做日誌，把文件系統恢復到最近的狀態。爲了縮短Master啓動時間，咱們必須控制日誌大小。當日志增加到必定量時，Master服務器會對系統狀態作一次Checkpoint，把全部的狀態數據寫入一個Checkpoint文件。在災難恢復時，Master服務器會從磁盤上讀取Checkpoint文件，重放Checkpoint以後的有限個日誌文件，從而恢復系統。Checkpoint文件按照壓縮B-樹的形式存儲數據，能夠直接映射到內存，且用於命名空間查詢時無需額外的解析，從而大大提升了恢復速度和可用性。

因爲建立一個Checkpoint文件須要必定的時間，因此Master服務器的內部狀態的組織格式要確保Checkpoint過程不會延遲正在進行的修改操做。Master服務器使用獨立的線程切換到新的日誌文件，建立新的Checkpoint文件。新的Checkpoint文件包括切換前的全部修改。對於一個包含數百萬個文件的集羣，建立一個Checkpoint文件須要1分鐘左右。建立完成後，Checkpoint文件會被寫入本地和遠程硬盤。

Master服務器恢復只須要最新的Checkpoint文件和後續的日誌文件。舊的Checkpoint文件和日誌文件能夠被刪除，但爲了應對災難性故障，咱們一般會多保存一些歷史文件。Checkpoint失敗不會對正確性產生任何影響，由於恢復功能的代碼能夠檢測並跳過沒有完成的Checkpoint文件。

參考資料

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