1、介紹
gfs是構建在廉價服務器之上的大型分布式文件系統。
設計原則:
- gfs組件失效是常態事件,而不是意外事件。gfs構建在普通商業PC之上,這些PC的穩定性並沒有很高的保障,任何時間都可能發生組件無法工作。
- gfs文件系統中存儲的文件大部分是數GB的大文件。
- 絕大部分文件的修改是在文件末尾追加數據,而不是覆蓋原有數據的方式。文件隨機寫入在實際中幾乎不存在。一旦寫完之后,對文件的操作就只有讀,而且通常是順序讀。
2、整體架構
gfs文件系統的整體架構如圖所示:
gfs文件系統一共包含四個部分:
- gfs主控服務器(master)
- chunk server
- gfs客戶端
(2.1)主控服務器(master)
gfs的主控服務器是一個主從結構。有點是整個存儲系統存在一個全局的主控節點,管理相對簡單。缺點是很多的服務請求都需要經過主控服務器,所以很容易成為整個系統的瓶頸。
master的作用包括以下幾個方面:
i、維護系統中的元數據:命名空間(文件及chunk命名空間)、文件到chunk的映射關系、chunk的存儲位置信息。其中前兩種需要持久化存儲到磁盤,第三種可以通過chunkserver匯報獲取(master服務器只需要不到64個字節的元數據就能夠管理一個64M的chunk)
ii、負載均衡:包括chunk的創建、復制以及負載均衡
其中chunk的創建會根據以下因素來選擇chunk副本的存放位置:
1)新副本所在的chunkserver的磁盤利用率低於平均水平;
2)限制每個chunkserver最近創建的數量。因為創建chunk往往意味着后續有大量的寫入操作。
3)為了提高系統的可用性,gfs會盡量將同一個chunk的不通副本放在不同的機架上
iii、垃圾回收:gfd采用延時回收策略。當要刪除文件時,gfs只是在元數據中將文件改為一個隱藏的名字,並且包含一個刪除時間。master定期檢查,如果發現文件刪除超過一定時間,就會從內存中將元數據刪除。在chunkserver通過心跳匯報chunk信息時,master會回復master元數據中已經不存在的的chunk信息,然后chunkserver會釋放這些chunk副本。
iv、快照(可以瞬間完成,幾乎不會對正在進行其它操作造成任何干擾)
寫時復制生成快照。步驟如下:
1)通過租約機制收回對文件的每個chunk的寫操作權限(master把這個操作以日志的方式記錄到硬盤上),停止對文件的寫操作
2)master拷貝文件名等元數據生成一個新的快照文件
3)對執行快照的文件的所有chunk增加引用計數
在快照操作之后,客戶端向快照中涉及到的chunk寫數據步驟:
1)詢問master當前持有租約者
2)master發現當前chunk的引用大於1,通知chunkserver復制該chunk,客戶端的所有追加操作轉向新復制出來的chunk
(2.2)chunkserver
gfs中文件都是以固定大小(64M)來存儲的,每一個chunk通過全局唯一的64位chunk handle來標識。默認情況下,每個chunk會存儲3份。
3、關鍵問題
3.1、chunk size
對於gfs系統來說,chunk size 的默認大小是64M,比一般系統的block(4K?)要大
優點:
- 可以減少GFS client和GFS master的交互次數,chunk size比較大的時候,多次讀可能是一塊chunk的數據,這樣,可以減少GFS client向GFS master請求chunk位置信息的請求次數。
- 對於同一個chunk,GFS client可以和GFS chunkserver之間保持持久連接,提升讀的性能
- chunk size越大,chunk的metadata的總大小就越小,使得chunk相關的metadata可以存儲在GFS master的內存中
缺點:
- chunk size越大時,可能對部分文件來講只有1個chunk,那么這個時候對該文件的讀寫就會落到一個GFS chunkserver上,成為熱點
對於熱點問題,google給出的解決方案是應用層避免高頻地同時讀寫同一個chunk。還提出了一個可能的解決方案是,GFS client找其他的GFS client來讀數據
3.2、租約機制
gfs系統采用單一master節點設計,如果所有讀寫操作都通過master,那么master將成為系統瓶頸。因此在gfs中,master通過租約機制將chunk的寫權限交給chunkserver。擁有寫權限的chunkserver為主chunkserver,其他為備份。租約針對單個chunk。租約時長為60秒,且在租約結束后如果不出問題,master盡量將租約付給原持有租約的chunkserver。
3.3、一致性:gfs保證至少追加成功一次
1)出現異常:客戶端會重新請求追加,因此可能出現記錄在某些副本中被追加了多次,即重復記錄;也可能出現一些可識別的填充記錄。
2)gfs客戶端支持並發追加。多個客戶端之間的順序無法保證,同一客戶端連續追加成功的多個記錄也可能被打斷
3.4、容錯機制
1)master容錯機制:
i、操作日志和checkpoint。master服務器的所有操作日志和checkpoint文件都被復制到多台機器上。
ii、“影子”master服務器,非master的鏡像,它們比主服務器的更新要慢,通常不到1秒
iii、持久化命名空間和文件到chunk映射的元數據
2)chunserver容錯機制
i、存儲多個chunk副本
ii、對存儲數據進行checksum。gfs的每個chunk都分成一定大小的block,每個block都有對應的checksum。當讀取一個chunk副本時,chunkserver會將讀取的數據和校驗和進行比較。如果比匹配,則返回客戶端錯誤,並報告master服務器。客戶端收到錯誤后會請求其它副本讀取數據。同時master服務器也會從其它副本克隆數據進行恢復。當一個新副本就緒后,master服務器通知副本錯誤的chunkserver刪除錯誤的副本
3.5、追加流程
gfs系統的追加流程特點是流水線和分離數據流和控制流。流水線操作減少延時。分離數據流和控制流可以優化數據傳輸(數據流可以通過精心安排的數據傳輸線路進行傳輸,每次都傳到距離最近的一個chunkserver)。
3.6、過期失效的副本檢測
當 Chunk 服務器失效時, Chunk 的副本有可能因錯失了一些修改操作而過期失效。 Master 節點保存了每個 Chunk 的版本號,用來區分當前的副本和過期副本。
無論何時,只要 Master 節點和 Chunk 簽訂一個新的租約,它就增加 Chunk 的版本號,然后通知最新的副本