GFS讀後筆記

GFS讀後筆記

Q&A

• 爲何存儲三個副本？而不是兩個或者四個？

ANS: 可能取得某些平衡點

• Chunk的大小爲什麼選擇64MB？這個選擇主要基於哪些考慮？

ANS:

• GFS主要支持append，overwrite操做比較少。爲何這樣設計？如何基於一個只支持Append操做的文件系統構建分佈式表格系統Bigtable？

GFS主要是爲了追加（Append）而不是改寫（Overwrite）而設計的。一方面是由於是改寫的需求比較少，或者能夠經過追加來實現，好比能夠只使用GFS的追加功能構建分佈式表格系統Bigtable；另外一方面是由於追加的一致性模型相比改寫要更加簡單有效。考慮Chunk A的三個副本A1，A2，A3，有一個改寫操做修改了A1，A2但沒有修改A3，這樣，落到副本A3的讀操做可能讀到不正確的數據；相應地，若是有一個追加操做往A1，A2上追加了一個記錄可是追加A3失敗，那麼即便讀操做落到副本A3也只是讀到過時而不是不正確的數據。

• 爲何要將數據流和控制流分開？若是不分開，如何實現Append流程？

主要是爲了優化數據傳輸，每一臺機器都是把數據發送給網絡拓撲上」最近「的還沒有收到數據的機器。
若是不分開，能夠像傳統的主備複製的方法。

• GFS有時會出現重複記錄或者padding，爲何？

若是記錄追加操做在任何一個副本上失敗了， 客戶端就須要從新進行操做。從新進行記錄追加的結果是，同一個Chunk的不一樣副本可能包含不一樣的數據–重複包含一個記錄所有或者部分的數據。GFS並不保證Chunk的全部副本在字節級別是徹底一致的。它只保證數據做爲一個總體原子的被至少寫入一次。

• Lease是什麼？在GFS起什麼做用？它與heartbeat有何區別？

使用lease機制來保持多個副本間變動順序的一致性。目的是爲了最小化Master節點的管理負擔。首先由Master決定一個主chunk，主chunk對其餘的Chunk的全部更改操做進行序列化。HB是定時發送的，而Lease是用於變動時。客戶機把數據推送到全部的副本上。客戶機能夠以任意的順序推送數據。當全部的副本都確認接收到了數據，客戶機發送寫請求到主Chunk服務器。這個請求標識了早前推送到全部副本的數據。主 Chunk爲接收到的全部操做分配連續的序列號，這些操做可能來自不一樣的客戶機，序列號保證了操做順序執行。

• GFS append過程當中若是Secondary出現故障，如何處理？若是Primary出現故障，如何處理？

客戶端的請求被肯定爲失敗，被修改的region處理不一致的狀態，client經過重試執行失敗的操做來處理這樣的操做。若是primary掛了，操做不會被分配序列號，不能被傳遞。

• GFS Master須要存儲哪些信息？Master數據結構如何設計？

MASTER上保存了三種元數據信息：
1）命名空間NameSpace，也就是整個文件系統的目錄結構及Chunk基本信息；2）文件到CHUNK之間的映射；3）CHUNK副本的位置信息。
持久化前兩種元數據的映射。CHUNK數據由SERVER啓動時上報給MASTER.

• 假設服務一千萬個文件，每一個文件1GB，Master中存儲的元數據大概佔用多少內存？

管理每一個64MB的CHUNK服務器不到64byte。

• Master如何實現高可用性？負載的影響因素有哪些？如何計算一臺機器的load值？

快速恢復和複製。
 負載的影響因素包括：網絡拓撲、機器分佈、磁盤利用率等。
 load值：

• Master新建chunk時如何選擇ChunkServer？若是新機器上線，load值特別低，是否須要有些特殊考慮？

系統中有三種須要建立chunk副本的狀況：chunk建立，chunk從新複製（re-replication）以及從新平衡（rebalancing）。
當Master建立了一個chunk，它會根據以下因素來選擇chunk副本的初始位置：(1) 新副本所在的Chunk Server的磁盤利用率低於平均水平；(2) 限制每一個Chunk Server」最近」建立的數量。（3）每一個chunk的全部副本不能在同一個機架。
第二點容易忽略但卻很重要，由於建立完chunk之後一般須要立刻寫入數據，若是不限制」最近」建立的數量，當一臺空的Chunk Server上線時，因爲磁盤利用率低，可能致使大量的chunk瞬間遷移到這臺機器從而將它壓垮。

• 若是某臺ChunkServer報廢，GFS如何處理？

RE-BALANCE。當有 Chunk服務器離線了，或者經過 Chksum 校驗（參考5.2節）發現了已經損壞的數據，Master節點經過克隆已有的副本保證每一個 Chunk 都被完整複製 。

• 若是ChunkServer下線後過一會從新上線，GFS如何處理？

Master節點在這個Chunk服務器從新啓動，而且向 Master 節點報告它擁有的 Chunk 的集合以及相應的版本號的時候，就會檢測出它包含過時的Chunk。若是 Master 節點看到一個比它記錄的版本號更高的版本號，Master 節點會認爲它和Chunk服務器簽定租約的操做失敗了，所以會選擇更高的版本號做爲當前的版本號。

• 如何實現分佈式文件系統的快照操做？

增長引用，寫時拷貝。

• ChunkServer數據結構如何設計？

64MB的CHUNK，儘量均勻地分佈在不一樣的磁盤之中。

• 磁盤可能出現「位翻轉」錯誤，ChunkServer如何應對？

Chunk Server會對存儲的數據維持校驗和。GFS以64MB爲Chunk大小來劃分文件，每個Chunk又以Block爲單位進行劃分，大小爲64KB，每個Block對應一個32位的校驗和。當讀取一個Chunk副本時，Chunk Server會將讀取的數據和校驗和進行比較，若是不匹配，就會返回錯誤，客戶端將選擇其它Chunk Server上的副本。

• ChunkServer重啓後可能有一些過時的chunk，Master如何可以發現？

當 Chunk 服務器失效時，Chunk 的副本有可能因錯失了一些修改操做而過時失效。Master 節點保存了每一個 Chunk 的版本號，用來區分當前的副本和過時副本。