MFS分佈式文件系統簡介

分佈式原理

• 分佈式文件系統就是把一些分散在多臺計算機上的共享文件夾，集合到一個共享文件夾內，用戶要訪問這些文件夾的時候，只要打開一個文件夾，就可以的看到所有鏈接到此文件夾內的共享文件夾。

MFS概述

• MFS是一個具有容錯性的網絡分佈式文件系統，它把數據分散存放在多個物理服務器上，而呈現給用戶的則是一個統一的資源。

MFS特性

MooseFS是一個分佈式存儲的框架，其具有如下特性：

• Free(GPL)
• 通用文件系統，不需要修改上層應用就可以使用。
• 可以在線擴容，體系架構可伸縮性極強。
• 部署簡單。
• 高可用，可設置任意的文件冗餘程度（提供比raid1+0更高的冗餘級別，而絕對不會影響讀或者寫的性能，只會加速！）
• 可回收在指定時間內刪除的文件（“回收站”提供的是系統級別的服務，不怕誤操作了，提供類似oralce 的閃回等高級dbms的即時回滾特性！）
• 提供netapp，emc，ibm等商業存儲的snapshot特性。（可以對整個文件甚至在正在寫入的文件創建文件的快照）
• google filesystem的一個c實現。
• 提供web gui監控接口。
• 提高隨機讀或寫的效率（有待進一步證明）。
• 提高海量小文件的讀寫效率（有待進一步證明）。

可能的瓶頸

1. master 本身的性能瓶頸。mfs 系統 master 存在單點故障如何解決?moosefs+drbd+heartbeat
   來保證 master 單點問題?不過在使用過程中不可能完全不關機和間歇性的網絡中斷!
2. 體系架構存儲文件總數的可遇見的上限。(mfs 把文件系統的結構緩存到 master 的內存中,文
   件越多,master 的內存消耗越大,8g 對應 2500w 的文件數,2 億文件就得 64GB 內存 )。
   master 服務器 CPU 負載取決於操作的次數,內存的使用取決於文件和文件夾的個數。

MFS的組成

• 元數據服務器（Master，也稱爲管理服務器）：在整個體系中負責管理文件系統，維護元數據，負責各個數據存儲服務器的管理，文件讀寫調度，文件空間回收以及恢復，多節點拷貝。
• 元數據日誌服務器（MetaLogger）：備份Master服務器的變化日誌文件，當master服務器損壞，可以從日誌服務器中取得文件恢復。
• 數據存儲服務器（Chunk Server）：真正存儲數據的服務器，服務器越多，容量就越大，可靠性越高，性能越好。負責連接管理服務器，聽從管理服務器調度，提供存儲空間，併爲客戶提供數據傳輸。
• 客戶機掛載使用（ client computers）： 可以像掛載NFS一樣，掛載MFS文件系統。通過fuse 內核接口掛接遠程管理服務器上所管理的數據存儲服務器，看起來共享的文件系統和本地unix 文件系統使用一樣的效果。
  

MFS讀數據的處理過程

• 客戶端當需要一個數據時，首先向元數據服務器（master）發出讀請求；
• 元數據服務器檢索自己的數據，獲取到數據所在的存儲服務器chunk server的ip|prot|chunkid；
• 元數據服務器把chunk server存儲服務器的地址等告知客戶端；
• 客戶端向已知的Chunk Server請求獲取數據；
• Chunk Server向客戶端發送數據 。
  

MFS的寫數據的過程

• 當客戶端有數據寫需求時，首先，客戶端向元數據服務器（master）發送寫入請求，向master服務器提供文件元數據信息請求存儲地址（元數據信息比如：文件名|大小|份數）；
• 元數據服務器與Chunk Server進行交互，但元數據服務器只在某些服務器創建新的分塊Chunks，創建成功後由chunk Servers告知元數據服務器操作成功；
• 元數據服務器告知客戶端，可以在哪個Chunk Server的哪些Chunks寫入數據；
• 客戶端向指定的Chunk Server寫入數據
• 該Chunk Server與其他Chunk Server進行數據同步，同步成功後Chunk Server告知客戶端數據寫入成功；
• 客戶端告知元數據服務器本次寫入完畢 。
  
  注意：原始的讀/寫速度很明顯是主要取決於所使用的硬盤的性能、網絡的容量和拓撲結構的,使用的硬
  盤和網絡的吞吐量越好,整個系統的性能也就會越好。

MFS的刪除文件過程

• 客戶端有刪除操作時，首先向元數據服務器Master發送刪除信息；
• Master定位到相應元數據信息進行刪除，並將chunk server上塊的刪除操作加入隊列異步清理；
• 響應客戶端刪除成功的信號。

MFS修改文件內容的過程

• 客戶端有修改文件內容時，首先向Master發送操作信息；
• Master申請新的塊給.swp文件；
• 客戶端關閉文件後，會向Master發送關閉信息；
• Master會檢測內容是否有更新，若有，則申請新的塊存放更改後的文件，刪除原有塊和.swp文件塊；
• 若無，則直接刪除.swp文件塊。

MFS重命名文件的過程

• 客戶端重命名文件時，會向Master發送操作信息；
• Master直接修改元數據信息中的文件名；
• 返回重命名完成信息；

MFS遍歷文件的過程

• 遍歷文件不需要訪問chunk server，當有客戶端遍歷請求時，向Master發送操作信息；
• Master返回相應元數據信息；
• 客戶端接收到信息後顯示。

注意

• Master記錄着管理信息，比如：文件路徑|大小|存儲的位置(ip,port,chunkid)|份數|時間等，元數據信息存在於內存中，會定期寫入metadata.mfs.back文件中，定期同步到metalogger，操作實時寫入changelog.*.mfs，實時同步到metalogger中。master啓動將metadata.mfs載入內存，重命名爲metadata.mfs.back文件。
• 文件以chunk大小存儲，每chunk最大爲64M，小於64M的，該chunk的大小即爲該文件大小（驗證實際chunk文件略大於實際文件），超過64M的文件將被切分，以每一份（chunk）的大小不超過64M爲原則；塊的生成遵循規則：目錄循環寫入(00-FF 256個目錄循環，step爲2)、chunk文件遞增生成、大文件切分目錄連續。
• Chunkserver上的剩餘存儲空間要大於1GB（Reference Guide有提到），新的數據纔會被允許寫入，否則，你會看到No space left on device的提示，實際中，測試發現當磁盤使用率達到95%左右的時候，就已經不行寫入了，當時可用空間爲1.9GB。
• 文件可以有多份copy，當goal爲1時，文件會被隨機存到一臺chunkserver上，當goal的數大於1時，copy會由master調度保存到不同的chunkserver上，goal的大小不要超過chunkserver的數量，否則多出的copy，不會有chunkserver去存。