gfs分布式文件系統


1、介紹

    gfs是構建在廉價服務器之上的大型分布式文件系統。

設計原則:

  • gfs組件失效是常態事件,而不是意外事件。gfs構建在普通商業PC之上,這些PC的穩定性並沒有很高的保障,任何時間都可能發生組件無法工作。
  • gfs文件系統中存儲的文件大部分是數GB的大文件。
  • 絕大部分文件的修改是在文件末尾追加數據,而不是覆蓋原有數據的方式。文件隨機寫入在實際中幾乎不存在。一旦寫完之后,對文件的操作就只有讀,而且通常是順序讀。

2、整體架構

    gfs文件系統的整體架構如圖所示:

 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 的版本號,然后通知最新的副本


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM