公司使用moosefs做圖片存儲，最近學習了一下，在此小小總結一下，主要分以下幾部分：
·MFS概述、特性和新版改進
·MFS 工作原理和設計架構
·MFS的安裝、部署、配置
·MFS的高級特性
·MFS的性能測試
·MFS集羣的維護
·MFS的常見問題和建議對策
一、MFS概述、特性和新版改進
MooseFS是一個分佈式存儲的框架，其具有如下特性：
Free(GPL)
通用文件系統，不需要修改上層應用就可以使用（那些需要專門api的dfs很麻煩！）。
可以在線擴容，體系架構可伸縮性極強。（官方的case可以擴到70臺了！）
部署簡單。（sa們特別高興，領導們特別happy！）
高可用，可設置任意的文件冗餘程度（提供比raid1+0更高的冗餘級別，而絕對不會影響讀或者寫的性能，只會加速！）
可回收在指定時間內刪除的文件（“回收站”提供的是系統級別的服務，不怕誤操作了，提供類似oralce 的閃回等高級dbms的即時回滾特性！）
提供netapp，emc，ibm等商業存儲的snapshot特性。（可以對整個文件甚至在正在寫入的文件創建文件的快照）
google filesystem的一個c實現。
提供web gui監控接口。
提高隨機讀或寫的效率（有待進一步證明）。
提高海量小文件的讀寫效率（有待進一步證明）。
MooseFS 1.6版本改進：
·修復1.5.x中在大批量操作時打開文件過多的bug。報的錯誤說是打開的文件過多，造成chunker server的鏈接錯誤。在1.6.x中解決此問題，就解決了很大的問題。
·新增加了masterlogger服務器。這是在1.5.x中所沒有的，就是做了master服務器的冗餘，進一步的加強的master服務器的穩定性。在mfs體系中master是要求最穩定以及性能要求最高的，因此務必保證master的穩定。
·修改1.5.x中存在的對於壞塊的修復功能。在mfs1.5.x中遇到chunker壞塊校驗，錯誤比較多的時候導致master將出現壞塊的chunker自動的剔除出去的情況，此次增加了對壞塊的修復功能，很方便的進行修復，簡化對壞塊的處理功能。
·對metadata和changelog的新認識。之前認爲changelog記錄的是文件的操作，定期的像數據庫的日誌一樣歸檔到metadata中。發現上面的理解存在誤區，真正的是changelog中記錄了對文件的操作，metadata記錄文件的大小和位置。因此metadata是比較重要的，在進行修復的過程中是採用metadata和最後一次的changelog進行修復的。
·MFS文檔中明確指出對於內存和磁盤大小的要求。
·指出了在測試的過程中多個chunker並不影響寫的速度，但是能加快讀的速度。在原來的基礎上增加一個chunker時，數據會自動同步到新增的chunker上以達到數據的平衡和均衡。
二、MFS 工作原理和設計架構
角色 | 角色作用 |
管理服務器 | 負責各個數據存儲服務器的管理,文件讀寫調 |
元數據日誌服務器 | 負責備份master 服務器的變化日誌文件，文 |
數據存儲服務器 | 負責連接管理服務器,聽從管理服務器調度, |
客戶機掛載使用 | 通過fuse 內核接口掛接遠程管理服務器上所 |
官方的網絡示意圖是這樣的：
讀寫原理：
MFS的讀數據過程
client當需要一個數據時，首先向master server發起查詢請求；
管理服務器檢索自己的數據，獲取到數據所在的可用數據服務器位置ip|port|chunkid；
管理服務器將數據服務器的地址發送給客戶端；
客戶端向具體的數據服務器發起數據獲取請求；
數據服務器將數據發送給客戶端；
MFS的寫數據過程
當客戶端有數據寫需求時，首先向管理服務器提供文件元數據信息請求存儲地址（元數據信息如：文件名|大小|份數等）；
管理服務器根據寫文件的元數據信息，到數據服務器創建新的數據塊；
數據服務器返回創建成功的消息；
管理服務器將數據服務器的地址返回給客戶端(chunkIP|port|chunkid)；
客戶端向數據服務器寫數據；
數據服務器返回給客戶端寫成功的消息；
客戶端將此次寫完成結束信號和一些信息發送到管理服務器來更新文件的長度和最後修改時間
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去存。