GFS閱讀筆記
摘要
GFS：google file system，谷歌的分佈式文件系統，運行在廉價的PC上，但仍能提供高可靠，高性能的服務。
1.簡介
設計目標：
（1）高性能（performance）；
（2）可擴展（scalability）；
（3）高可靠性（reliability）；
（4）高可用（availability）；
假設與設計思路：
（1）組件失效是常態（component normal failures），因此持續監控、錯誤檢測、災難冗餘、自動恢復機制必須具備；
（2）大文件是常態（GB files common），因此IO操作，block size都需要重新考慮；
（3）追加寫設計（data appending），幾乎沒有隨機寫，這樣考慮的原因是基於性能優化與操作原子性；
（4）提供API以簡化應用程序，例如提供原子性寫，而無需應用程序來同步互斥以保證數據一致性；
2.設計概覽
2.1設計預期
（1）假設與設計思路中的第一點；
（2）假設與設計思路中的第二點；
（3）應用工作負載有兩種讀取模式：大量流式順序讀，少量隨機讀；
（4）應用工作負載寫入模式：大量順序追加寫入；
（5）系統必須明確定義多客戶端併發追加寫的行爲；
（6）高速、高性能並行遠比低延時重要（意味着吞吐量比響應速度更重要）；
2.2接口
支持文件，文件以分層目錄形式組織，用路徑名稱來標識。
（1）支持傳統常用文件操作：創建、刪除、打開、關閉、讀、寫；
（2）支持快照（snapshot）：低成本創建文件或目錄樹的拷貝；
（3）支持記錄追加（record append）：允許多個客戶端同時對一個文件進行數據追加，且保證追加操作的原子性；
2.3架構
（1）一個GFS集羣由單master，多chunkserver，多client組成；
圖一：GFS經典圖例
（2）文件被切分爲多個固定大小（fixed-size）的chunk，每個chunk有一個64bit的唯一標識（handle），每個chunk在多個chunkserver上保存有多副本（默認爲3份）；
（3）master維護元數據（metadata），元數據包括名字空間（namespace），訪問控制信息（acl），文件到chunk的映射（mapping from file to chunk）,chunk的位置信息（location of chunks）；master還負責chunk的lease管理，孤兒chunk的回收，chunk的自動遷移；master定期向chunkserver發送心跳，維護其狀態信息；
（4）client的API以庫的形式提供；
（5）client和chunkserver都不緩存文件數據（數據太大了），但會緩存元數據，如chunkserver的信息；
2.4單master策略
此處的單master指邏輯上的master單點。
（1）單master的設計極大的簡化了設計；它具有全局視野，可以輕易實施chunk定位與遷移，複製策略。爲了避免單master成爲系統的瓶頸，必須減少client對master的讀寫：client向master詢問它應該訪問的chunkserver，並緩存chunkserver信息，後續都只會通過chunkserver讀寫數據；
（2）簡單解釋下讀寫流程：
首先，客戶端把文件名與字節偏移，計算出chunk索引；
然後，將chunk索引發送置master，master將返回chunk表示與副本的位置信息；此時客戶端會緩存這些信息；
之後，客戶端發送請求至其中一個副本（一般選最近的），請求包含chunk的標識與讀寫字節範圍；之後就不需要再與master交互了（除非過期）；
2.5chunk大小
GFS的chunk大小選擇爲64M，優點如下：
（1）大chunk存儲容量大，減少客戶端與master的交互；
（2）大chunk存儲容量大，儘量使一次寫操作只與一個chunkserver交互，保持tcp連接，減少網絡負載；
（3）減少master中元數據的存儲量（全部保存至內存）；
缺點如下：
（1）小文件往往只存儲在一個chunk中，使存儲這些chunk的chunkserver容易成爲熱點；
解決辦法：
（1）對於讀熱點，增加冗餘份數；
（2）應用層可以增加如“從其他客戶端讀取數據”等類似策略；
2.6元數據
master存儲3種主要元數據，且都放在內存中：
（1）文件和chunk的名字空間；
（2）文件和chunk的對應關係；
（3）每個chunk副本的位置。
前兩種元數據的任何變更同時也會記錄到日誌中（當然刷到磁盤上），日誌會進行冗餘複製。
原因：
（1）master掛掉不會導致數據不一致；
（2）chunk副本位置不記錄日誌，master啓動、有chunkserver加入時，會向各個chunkserver輪詢其存儲的chunk信息。
2.6.1內存中的數據結構
潛在問題：
（1）元數據放在內存中，內存是否夠用：64字節的struct管理64MB的chunk信息，不是問題；
（2）名字空間使用前綴壓縮算法壓縮，也在64字節以下；
2.6.2chunk位置信息
（1）定時向各個chunkserver輪詢chunk位置信息；
（2）輪詢避免了chunkserver加入、離開、更名、失效、重啓時出現的數據不一致情況；
2.6.3日誌
日誌記錄元數據的歷史變更記錄，它是元數據唯一的持久化存儲，同時它還保存操作時間線；
chunk、文件連同它們的版本，都由它們創建的時間永久標識；
日誌寫成功後，纔會響應客戶端；
日誌必須足夠小；
容災恢復需要最近一次checkpoint以及其後的日誌；
2.7一致性模型
2.7.1機制
（1）名字空間的修改是原子性的，它們由master節點控制；
（2）master節點的日誌保證了元數據操作的順序性；
（3）讀寫順序可能引發的不一致：
數據庫經典圖二
2.7.2實現
（1）只追加寫，不覆蓋寫；
（2）checkpoint，checkpoint包含程序級別的校驗和；
（3）寫操作自驗證；
（4）記錄自標識；
3.系統交互
原則：最小化與master節點的交互
3.1lease與寫操作順序
寫操作會改變chunk內容，或者元數據內容，如果進行寫操作，會改變chunk的所有副本；
（1）使用lease保證多副本間寫入順序的一致性：
master爲chunk的一個副本創建一個lease，使之成爲主chunk；
主chunk對所有寫入操作進行序列化；
所有其他副本遵從主副本的序列化操作；
lease機制是爲了最小化master的負擔，主chunk對lease的持有有超時設置；
在chunk被修改時，主chunk可以申請延長lease持有時間；
master可以取消lease，例如master要取消文件上的修改；
（2）寫操作的流程
圖二：寫操作控制流與數據流
step1.客戶端向master詢問，哪個chunkserver持有lease，以及chunk的位置；如果沒有chunk持有lease，則指定一個；
step2.master將主chunk，其他chunk的位置反饋給客戶端，客戶端會緩存這些元信息；
step3.客戶端將數據傳給chunkserver，數據流一定要推送給主chunk；
step4.數據傳遞給所有chunkserver後，控制流發往主chunk，主chunk對操作進行序列化；
step5.將序列化後的“操作序列”發往其他chunkserver；
step6.其他chunkserver執行完後返回主chunkserver；
step7.所有chunkserver執行完後返回客戶端；
3.2數據流
（1）爲了提高網絡消息，數據流與控制流分離；
（2）爲了避免延時，每臺機器會選擇一臺“最近”的機器作爲數據推送目標，“最近”可簡單的由IP地址計算出；
（3）服務器間數據傳遞使用TCP長連接；
經驗結論是，1M的數據約80ms就能分發完畢。
3.3原子性記錄追加操作
多個客戶端同時寫入一個文件，原子性實現有以下兩種方法：
（1）分佈式鎖；
（2）使用多個生產者，單個消費者的隊列系統，合併多個客戶端的寫入；
GFS使用了方法（2）。
3.4快照
如同AFS（Andrew File System）一樣，使用標準的copy-on-write技術實現快照：
（1）收到快照請求時，master會取消所有文件的chunk租約；
（2）master將操作日誌刷到硬盤上（元數據的寫操作日誌，量是很小的）；
（3）master備份多份操作日誌，完成快照；
4.master的操作
master的職能：
（1）所有名字空間操作；
（2）管理chunk副本元信息，包括決定chunk位置，創建chunk等；
（3）實現chunk負載均衡，回收垃圾chunk；
4.1名字空間管理和鎖
（1）GFS不支持文件或目錄的鏈接，邏輯上，名字空間就是目錄樹；
（2）每個目錄是一個節點，對應一個讀寫鎖；
（3）操作某個文件，必須遞歸獲取各上級目錄的鎖；
例如：要操作文件/d1/d2/d3/file1，就必須先獲取/d1/d2/d3，/d1/d2，/d1三把鎖。
（4）讀寫鎖的衝突方式，與普通數據庫讀寫鎖，文件讀寫鎖的衝突方式一致；
優點：
（1）支持同一目錄下多個文件的並行操作；
（2）使用全局鎖視野避免死鎖；
4.2副本的位置
副本放置的三大目標：
（1）最大化數據可靠性；
（2）最大化數據可用性；
（3）最大化網絡帶寬利用率；
副本放置方式：
（1）一個副本多份；
（2）每份副本在不同機器上；
（3）機器儘量分佈在不同機架上；
4.3副本的創建、複製與均衡
master創建副本將考慮的因素：
（1）均衡chunkserver磁盤使用率；
（2）均衡chunkserver寫操作頻率；
（3）均衡各機架的chunkserver；
副本的複製：
（1）某chunkserver不可用了，master會複製其上的chunk到其他機器；
（2）增加了副本數配置也會引起副本的複製；
（3）複製策略與創建策略相同；
4.4垃圾回收
（1）文件被刪除時，master會將刪除日誌記錄下來，但並不馬上回收資源；
（2）被刪除的chunk會記錄時間戳，並置刪除標記（所以刪除是高效的，刪除後chunk未被寫入前，恢復是可行的）；
（3）獨立任務掃描chunk，孤兒chunk將被刪除，同時向master發消息以刪除元數據；
5.容錯與診斷
挑戰：
（1）集羣中有機器掛掉怎麼辦；
（2）產生不完整的數據怎麼辦；
5.1高可用性
（1）快速恢復技術：不管master和chunkserver如何關閉，可以在秒級時間恢復並重啓，這可以用重試加心跳機制檢測可用性，用重試來避免少量顛簸引起的丟包或延時；
（2）chunk複製技術：chksum校驗能輕易發現損壞或者不完整的數據，並複製損壞的chunk；
（3）master的複製：master的日誌、checkpoint文件都會有冗餘；
（4）master冗餘：多個影子master存在，一旦master掛掉，影子master可以馬上恢復；
5.2數據完整性
（1）chunk分塊：chunk分爲64KB的小塊，每塊對應32bit的checksum；
（2）checksum獨立保存：checksum與數據分開存儲，永久保存，獨立日誌；
（3）獨立檢測單元：chunkserver會定時檢測chunk各個分塊的checksum，發現錯誤，立刻複製；
5.3診斷工具
（1）一些輔助手段判斷系統是否正常運行，如顯示當前系統運行狀況等；
（2）線下日誌挖掘、監控手段等；
n.結束語
GFS展示了一個使用普通硬件支持大規模數據處理的系統特性，雖然有一些定製化，但還是有很多類似規模和成本的處理任務：
（1）可預見的特性：失效是常態、追加寫、順序讀、簡易接口等；
（2）監控、冗餘、快速自動恢復來容災；
（3）分離控制流與數據量，提高吞吐量。