Google File System(GFS)整理

 

1.服務器的各類不穩定性是個問題。

2.文件太小去管理，尺寸是個問題。

3.不斷增長的海量數據加內存性能不合適的問題。

4.多客戶端並行追加，提供了API和靈活性。

二.設計概述

1.隨機大量小規模讀取文件，能夠把操做作一個排序，而後批量的執行要強於先後的來回移動。多進程併發的讀寫文件。或消費時讀取。不少時候更突出高速率大批量處理數據（吞吐量效率，像火車站人流似的）。

2.結構對多客戶端，實現多路結果合併，同時對同個文件追加。文件追加和快照對分佈式應用是很是重要的。

三.架構

1.能夠爲不一樣的命名空間指定設定不一樣的設定級別。是一個Master控制管理一堆chunk信息，並探測地址和他們的通訊調度等。

2.注意客戶端只是從Master得到元數據，全部的數據操做都是由客戶端和chunk服務器直接交互的。

3.客戶端和chunk都不緩存數據，chunk以本地文件的方式保存，linux的文件系統會把常常訪問的數據緩存再內存中。

4.Master單一節點，能夠根據名稱和偏移量定位文件chunk集合位置，避免客戶端和chunk通訊時頻繁和Master交互。

5.Chunk尺寸，減小網絡通訊，對同個塊屢次操做，較大的減小元數據量。問題是某些chunk可能變成熱點，比較好的解決方法是把客戶端的數據也能做爲服務數據提供上傳。

二.元數據

1.元數據，chunk空間，關係，在那裏，會保存在Master一個變動日誌信息，也能傳遞，但不會永遠保存在內存中，有新機器加入時會輪詢chunk服務器中他們存儲的chunk信息。

2.內存數據結構

chunk信息保存在master中，當發生chunk失效，垃圾收集能夠及時的複製數據和收集垃圾，雖然把chunk保存在master的內存中，可是會受到系統承載能力的限制。絕大多數chunk都是滿的。master增長有限的費用就能增長更到的chunk容量，提升簡潔，高效，靈活。

3.chunk位置信息

master先保存chunk位置信息，而後會不斷輪詢chunk服務器，心跳檢測，仍是chunk服務本身最知道本身狀況，因此沒有在master中維護一個全局的信息。

4.操做日誌

只有保證元數據變動歷史及記錄，並且是在元數據變動持久化以後日誌文件被複制到別的機器以後纔對客戶端所見。並且有B-tree空間的功能和checkpoint功能，checkpoint足夠小，恢復的時候也足夠快。

5.一致性模型

a.region（一致），region&能夠看到寫入（已定義），若是是未定義的region，應用程序不必再去細分。

b.順序一致性，chunk版本號。

c.master會定時和chunk服務器握手，checksum是否損壞，若是有就會馬上用好的副本進行復制。通常檢測窗口時間是幾分鐘。

6.程序的實現

a.典型的是順序寫入後的追加操做，有一些驗證。

b.writers/reader都有一些checksum驗證有效性。記錄I/O功能包含在程序共享庫中，也適用其餘文件接口實現。

7.系統交互原則是最小化全部操做和master的操做

a.lease機制會以主chunk接受到的操做序列進行分派的方式，而後將其餘二級副本返回的信息傳遞給client端，判斷是操做是否成功，能保證一致性。lease就是master會租用一個primaryReplica做其餘副本的代理。

b.數據流主要是線性的管道推送方式，避免拓撲推送時候均衡帶寬。

c.原子的記錄追加時用到了多生產/單消費的模式，避免競爭。不是每一個chunk都有相同的字節，只會保證至少一次原子的事物性。這個原子性能保證region是一致性的。

d.快照，在找租約chunk前有個與master交互的過程就是快照的機會。若是發現有快照指向的chunk,那麼再請求寫數據時會建立個新的chunk直接寫入。

8.master節點的操做，名稱空間，如快照操做取消租約，名稱空間的region上的鎖保證正確順序，雖然GFS有名稱空間絕對路徑對應的鎖，但不可列出全部文件。暫時先了解文件父目錄只有讀取鎖，能夠防止被修改。鎖是惰性所，在一個層級有排序，委會一個全局的一致性。

9.副本的位置，除了防丟失，主要還有考慮帶寬的利用率。

a.建立chunk時，首先選擇低磁盤利用率。

b.但願限制最近chunk操做的次數。

c.複製chunk有游下級別，如丟失的多的，活躍高的，影響流程的 。

d.複製時也會均衡網絡間帶寬，機架，原chunk操做次數等的限制。

e.最後master還會逐步的根據帶寬利用率和複製因子平衡磁盤的使用狀況。

10.副本的刪除，是會標記一個隱藏的刪除時間戳，等待master掃描時進行判斷，同步元數據。master和chunk心跳檢測時，判斷哪些chunk已經再也不元數據中，chunk就能夠統一執行刪除。

不一樣的目錄能夠設定文件的刪除策略。過時失效的副本檢測會用版本號的方式判斷那些是有效並保證一致性。

11.容錯和診斷，硬盤網絡機器的故障不可避免，如何處理？2個策略，快速回復和複製。

a.快速恢復，毫秒級回覆機器狀態。

b.chunk,複製因子保證chunk數量和驗證和鏈路層網絡層不相關錯誤驗證，由於系統主要是隻讀和追加操做。

c.master操做保存到本機地址和備份節點，若是master失效，幾乎能夠馬上恢復機器狀態，客戶端甚至能夠指向又GFS外部新啓動的master進程。

d.master有個影子服務器，功能和master主服務器相似，提供狀態變動小的或不敏感狀態變化信息的chunk讀取操做。按期經過master副本log保持狀態，只有更新操做時會和master通訊更新本身的狀態。

12.數據完整性

a.由於磁盤可能壞道等緣由可能致使數據保存了未必正確或有可能丟失，如何檢查正確性，跨區是不實際的，每一個chunk都在內存和硬盤維護一個本身的checksum和日誌信息。

b.讀取操做前，會在要讀取的範圍內檢查checksum，若是有錯誤會通知請求端和master端，請求端會從別的chunk請求數據，master會負責修復損壞的副本，就緒後會刪除副本。同時checksum是頗有效率的，是很小的一部分，同時不須要I/O操做。checksum更新只同步最後增長的那個塊信息是頻率較高的操做。

c.寫前會檢查起始塊和最後一塊，若是不檢測，那麼新寫入的checksum可能會覆蓋以前損壞的數據。

d.checksum會在chunk服務器空閒的時候檢測那些chunk是否損壞，提前通知master修復或避免欺騙master副本數量。

13.診斷工具

a.日誌的記錄是有必要的，它帶來的好處遠大於系統的消耗，近期的信息放在內存中能夠提供持續不斷在線的監控行爲。

三.度量

1.理想的讀取測試時，當多個客戶同時讀取同一個chunk服務器的概率增長時，可能致使總體讀取效率的降低。

2.寫入的時候因爲網絡協議棧和管道的方式不相適應，加上可能多個客戶機對同個chunk進行寫入，致使寫入的延遲和下降。

3.記錄追加受限於最後一個chunk服務器的帶寬。

四.實際中的集羣

1.存儲的文件多chunk數量就比較多。

2.元數據會保存在master和chunk服務器上，因此恢復速度都比較快，只用數秒時間就可讀取，master的元數據不會成爲GFS的瓶頸。

3.讀寫速率，讀是頻繁且有效率的。這也是有效利用資源的一種方式。

4.master負載通常均可以200-500以上，結構用二分法優化後速率達到每秒數千次。

5.能夠在服務器失效時快速的恢復副本。據測試的環境看速度在450m/s的速度。

五.工做符合分析

1.咱們能夠把一個操做分紅幾個詳細的RPC請求，經過分析日誌判斷和分析集羣運行狀況。

2.有些涉及到的小文件的讀取，由於隨機seek也會致使工做的負荷。

3.追加的操做通常要大於寫的操做。

4.集羣的工做負荷主要仍是findlocation,而後是release等。

六.經驗

1.GFS生產系統是嚴格受控的，有一些架構來防止用戶間干擾，也是漸漸完善的過程。還有一點是因爲linux內核和硬盤驅動的問題可能致使數據被破壞，因此用checksum來檢查可能協議不匹配的問題。

2.可能有文件所主網絡線程的狀況，linux開源的好處就是比較好的理解和探索系統行爲，甚至能夠聯合解決。

七.相關工做

1.與位置無關的命名空間，複製方式，流式讀取或seek少許讀取，master集羣管控方式的簡潔以及master狀態保存的災難冗餘。

八.結束語

1.持續監控 複製關鍵數據 快速自動恢復 控制流和數據流分離 大量併發讀寫操做提供高吞吐量。

2.分佈式操做日誌，全局均衡等。