第1章 介紹
寫在前面，自己的理解。
對比nfs文件共享系統，其目的都是一樣的。nfs的運行過程是客戶端先向服務端的rpc服務請求nfs的端口號，然後客戶端再根據端口號找到對應的nfs服務，進行讀寫。
而mfs將nfs服務端的結構再進行細分，mfs的主服務端（master server）僅僅充當一個類似rpcbind的作用，而真正的數據存放在別的主機上（chunk server），客戶端向mfs主服務端請求存儲位置，主服務端回覆客戶端數據存放的位置，客戶端根據返回的位置尋找對應主機進行讀寫。
另mfs自帶高可用，它還有一個元數據備份服務器（metalogger Server），當主服務端（master server）產生問題時，它可以暫時頂替。
1.1介紹
MooseFS是一個具備冗餘容錯功能的分佈式網絡文件系統，它將數據分別存放在多個物理服務器或單獨磁盤或分區上，確保一份數據有多個備份副本。對於訪問的客戶端或者用戶來說，整個分佈式網絡文件系統集羣看起來就像一個資源一樣。從其對文件操作的情況看，MooseFS就相當於一個類UNIX文件系統:
1、mfs是一個分層的目錄樹結構
2、存儲支持POSIX標準的文件屬性（權限，最後訪問和修改時間）
3、支持特殊的文件，如：塊設備，字符設備，管道和套接字，鏈接文件（符號鏈接和硬鏈接）
4、支持基於IP地址和密碼的方式訪問文件系統
1.2特性
1、高可靠性，每一份數據可以設置多個副本（多份數據），並可以存儲在不同的主機上
2、高可擴展性，可以很輕鬆的通過增加主機磁盤容量或增加主機數量來動態擴展整個文件系統的存儲量
3、高可容錯性，我們可以通過對mfs進行系統設置，實現當數據文件被刪除後的一段時間內，依然存放於主機的回收站中，以備誤刪恢復數據
4、高數據一致性，即便文件被寫入/訪問時，我們依然可以完成對文件的一致性快照
1.3優缺點
優點：
1、由於MFS是基於GPL發佈的，因此完全免費，並且開發和社區都很活躍，資料也非常豐富
2、輕量、易部署、易配置、易維護
3、通用文件系統，不需要修改上層應用就可以使用（那些需要專門 API 的DFS確實有點麻煩）
4、擴容成本低、支持在線擴容，不影響業務，體系架構可伸縮性極強（官方的case可以擴到70臺了！）
5、體系架構高可用，所有組件無單點故障
6、文件對象高可用，可設置任意的文件冗餘程度（提供比 Raid 10 更高的冗餘級別）
7、提供系統負載，將數據讀寫分配到所有的服務器上，加速讀寫性能
8、提供諸多高級特性，比如類似Windows的回收站功能、類似JAVA語言的GC（垃圾回收）、快照功能等
9、MooseFS 是 Google Filesystem 的一個 c 實現
10、自帶 Web Gui 的監控接口
11、提高隨機讀或寫效率和海量小文件的讀寫效率（有待進一步證明）
缺點：
1、Master Server 本身的性能瓶頸。MFS的主備架構情況類似於MySQL的主從複製，從可以擴展，主卻不容易擴展。短期的對策就是按照業務來做切分。
2、隨着MFS體系架構中存儲文件的總數上升，Master Server對內存的需求量會不斷增大（MFS把文件系統的結構緩存到 Maset Server 的內存中）。根據官方提供的數據，8g對應2500kw的文件數，2億文件就得64GB內存。短期的對策也是按照業務來做切分。
3、Master server的單點解決方案的健壯性。目前官方自帶的是把數據信息從MasterServer同步到MetaloggerServer上，MasterServer一旦出問題MetaloggerServer可以恢復升級爲MasterServer，但是需要恢復時間。目前，也可以通過第三方的高可用方案（heartbeat+drbd+moosefs）來解決 Master Server 的單點問題。
4、Metalogger Server 複製元數據的間隔時間較長（可調整）
1.4應用場景
談及MooseFS的應用場景，其實就是去談分佈式文件系統的應用場景。
1、大規模高併發的數據存儲及訪問（小文件、大文件），TFS適合小文件（<1M）
2、大規模的數據處理，如日誌分析
1.5架構圖
整個架構中，主要有四個組件，分別是管理服務器 Master Server、備份服務器Metalogger Server、數據存儲服務器 Chunk Server 和 客戶端 Client。
管理服務器 Master Server負責所有數據存儲服務器的數據存儲管理，響應客戶端文件的讀寫請求，收回文件空間以及恢復文件，多存儲節點之間的文件複製；
元數據日誌服務器 Metalogger Server，對 Master Server 服務器的變化日誌文件進行備份，changelog_ml.*.mfs 是備份文件的類型，當 Master Server 出現故障時替換其繼續工作，避免 Master Server 的單點故障導致分佈式文件系統的不能正常運行；
數據存儲服務器chunkserver，服從 Master Server 的安排，定期向 Master Server 發送自己的狀態信息，除此之外，還能向客戶提供數據存儲空間，能夠向客戶傳輸數據；
客戶端 Client，通過 FUSE 內核接口掛載到數據存儲服務器上，在客戶端看來使用數據存儲服務器上的文件系統和使用本地Unix文件系統是一樣的。
組件 | 作用 |
管理服務器 Master Server | 這個組件的角色是管理整個mfs文件系統的主服務器，除了分發用戶請求外，還用來存儲整個文件系統中的每個數據文件的metadata信息，metadata（元數據）信息包括文件（也可以是目錄、socket、管道、設備等）的大小、屬性、文件位置路徑等，以及文件空間的回收和恢復，控制多chunk server節點的數據拷貝。很類似lvs負載均衡主服務器，不同的是lvs僅僅根據算法分發請求，而master根據內存裏的metadata信息來分發請求。這個master只能有一臺處於激活工作的狀態。 |
元數據備份服務器 metalogger Server | 這個組件的作用是備份管理服務器master的變化的metadata信息日誌文件，文件類型爲changelog_ml.*.mfs，以便於在主服務器出現問題的時候，可以經過簡單的操作即可讓新主服務器進行工作。這很類似Mysql的主從同步，只不過他不像mysql從庫那樣在本地應用數據，而只是接收主服務器上文件寫入時記錄的文件相關的metadata信息。這個backup可以有一臺或多臺，它很類似於lvs從負載均衡器。 |
數據存儲服務器組 Chunk Servers | 這個組件就是真正存放數據文件實體的服務器了，這個角色可以有多臺不同的物理服務器或不同的磁盤及分區來充當，當配置數據的副本多於一份時，劇寫入到一個數據服務器後，會根據算法在其他數據服務器上進行同步備份。這個很像lvs集羣的rs節點。 |
客戶機服務器組 Client | 這個組件就是掛載並使用mfs文件系統的客戶端，當讀寫文件時，客戶端首先連接主管理服務器獲取數據的metadata信息，然後根據得到的metadata信息，訪問數據服務器讀取或寫入文件實體。mfs客戶端通過FUSE mechanism實現掛載MFS文件系統的。因此，只要系統支持FUSE，就可以作爲客戶端訪問MFS整個文件系統。所謂的客戶端並不是網站用戶，而是前端訪問文件系統的應用服務器，如web |
1.6讀寫原理
1.6.1讀的原理
三角形爲master server 矩形是client 圓形是chunk server
①客戶端向master server發送請求
②master server告訴客戶端數據存放的位置
③客戶端向給出的位置即chunkserver 請求數據
④chunk server返回數據
1.6.2寫的流程
①客戶端向master server發送請求寫入數據
②主服務器master查詢緩存記錄，如果是新文件，則會聯繫後面的數據服務器創建對應的chunk對象準備存放文件。
③主服務器master把文件實體的位置等相關信息發給client客戶端。
④Client客戶端訪問對應的數據服務器寫數據
⑤多個chunk server同步用戶寫入的數據
⑥同步成功
⑦chunk server返回客戶端寫入成功的信號
⑧Client客戶端回報給主服務器master寫入結束
1.7生產環境各組件硬件要求
1.7.1Master Server
由於 Master Server 控制着整個 MooseFS 中的各個組件，並且負責對外提供服務，因此我們一定需要保證 MasterServer 處於非常穩定的狀態。比如，針對 Master Server採用雙電源雙路配置，多塊磁盤使用RAID1或RAID10，進行冗餘。
前面也提到，Master Server 將所有訪問的元數據信息都放在內存當中，提供用戶訪問。因此，當文件數量增加的時候，內存使用量也會增加。根據官方的數據，100萬個文件chunk信息，大概需要300M的內存空間來進行。對於磁盤來講，Master Server 對磁盤的使用量不是很大，這個取決於所用的文件和chunk塊的數目（記錄在主元數據文件）以及對文件作出操作的數量（記錄在元數據更改日誌），一般情況下 20G 可以用來存儲信息 2500 萬個文件變更記錄長達50小時。由此看來，作爲Master Server 內存量夠大才是重中之重。
總結：雙電源雙路，raid1或raid10，大內存
1.7.2Metalogger Server
由於需要做管理服務器的高可用備份，所以配置與Master Server一樣即可
1.7.3Chunk Server
作爲真正存儲數據的載體，重點保證磁盤性能即可。需要注意儘量保持個主機之間磁盤大小一致
第2章 mfs部署
2.1主機規劃
組件 | 主機名 | IP |
管理服務器 Master Server | master | 10.0.0.103 |
元數據備份服務器 Metalogger Server | metalogger | 10.0.0.104 |
數據存儲服務器1 Chunk Servers | chunk1 | 10.0.0.105 |
數據存儲服務器2 Chunk Servers | chunk2 | 10.0.0.106 |
客戶機服務器 Client | web | 10.0.0.107 |
2.2更新yum源及安裝
向包管理器添加相應的密鑰（以下兩步在所有主機執行）
[root@master ~]# curl"http://ppa.moosefs.com/RPM-GPG-KEY-MooseFS">/etc/pki/rpm-gpg/RPM-GPG-KEY-MooseFS 添加yum源 [root@master ~]# curl"http://ppa.moosefs.com/MooseFS-3-el6.repo"> /etc/yum.repos.d/MooseFS.repo master端安裝 [root@master ~]# yum install -y moosefs-mastermoosefs-cli moosefs-cgi moosefs-cgiserv chunk端安裝 [root@chunk01 ~]# yum install -ymoosefs-chunkserver metalogger端安裝 [root@metalogger ~]# yum install moosefs-metalogger-y 客戶端安裝 [root@web ~]# yum install moosefs-client -y
2.3配置
2.3.1配置master端
[root@master mfs]# ll /etc/mfs total 44 -rw-r--r-- 1 root root 4102 Oct 10 18:45mfsexports.cfg -rw-r--r-- 1 root root 4057 Aug 2 19:43 mfsexports.cfg.sample -rw-r--r-- 1 root root 8521 Oct 10 17:49mfsmaster.cfg -rw-r--r-- 1 root root 8521 Aug 2 19:43 mfsmaster.cfg.sample -rw-r--r-- 1 root root 1052 Oct 10 17:49mfstopology.cfg -rw-r--r-- 1 root root 1052 Aug 2 19:43 mfstopology.cfg.sample
這是mfs的三個配置文件
mfsmaster.cfg ：主文件
mfsexports.cfg ：mfs掛載權限設置，參考NFS文件系統中的exports.cfg
mfstopology.cfg ：機架感知
[root@master mfs]# vim mfsexports.cfg(把前面兩行沒註釋的刪掉) 10.0.0.0/24 / rw,alldirs,maproot=0:0 #類似nfs的export配置文件 [root@master mfs]# /etc/init.d/moosefs-master start
2.3.2配置chunk server端
[root@chunk01 ~]# sed -i '71a MASTER_HOST = 10.0.0.103'/etc/mfs/mfschunkserver.cfg [root@chunk01 ~]# echo "/tmp" >/etc/mfs/mfshdd.cfg #將/tmp目錄作爲存放數據的目錄 [root@chunk01 ~]# /etc/init.d/moosefs-chunkserverstart 這裏看一下tmp目錄，由於是塊狀文件，所以數據在chunk端是不可讀的。 [root@chunk02 ~]# ls /tmp/ 00 08 10 18 20 28 30 38 40 48 50 58 60 68 70 78 80 88 90 98 A0 A8 B0 B8 C0 C8 D0 D8 E0 E8 F0 F8 01 09 11 19 21 29 31 39 41 49 51 59 61 69 71 79 81 89 91 99 A1 A9 B1 B9 C1 C9 D1 D9 E1 E9 F1 F9 02 0A 12 1A 22 2A 32 3A 42 4A 52 5A 62 6A 72 7A 82 8A 92 9A A2 AA B2 BA C2 CA D2 DA E2 EA F2 FA 03 0B 13 1B 23 2B 33 3B 43 4B 53 5B 63 6B 73 7B 83 8B 93 9B A3 AB B3 BB C3 CB D3 DB E3 EB F3 FB 04 0C 14 1C 24 2C 34 3C 44 4C 54 5C 64 6C 74 7C 84 8C 94 9C A4 AC B4 BC C4 CC D4 DC E4 EC F4 FC 05 0D 15 1D 25 2D 35 3D 45 4D 55 5D 65 6D 75 7D 85 8D 95 9D A5 AD B5 BD C5 CD D5 DD E5 ED F5 FD 06 0E 16 1E 26 2E 36 3E 46 4E 56 5E 66 6E 76 7E 86 8E 96 9E A6 AE B6 BE C6 CE D6 DE E6 EE F6 FE 07 0F 17 1F 27 2F 37 3F 47 4F 57 5F 67 6F 77 7F 87 8F 97 9F A7 AF B7 BF C7 CF D7 DF E7 EF F7 FF
2.3.3配置metalogger端
[root@metalogger ~]# vim /etc/mfs/mfsmetalogger.cfg META_DOWNLOAD_FREQ = 1 #每隔1小時同步一下日誌 MASTER_HOST = 10.0.0.103
[root@metalogger ~]# /etc/init.d/moosefs-metaloggerstart
2.3.4客戶端配置
[root@web ~]# mfsmount /mnt -H 10.0.0.103 [root@web ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda3 8.8G 1.5G 6.9G 18% / tmpfs 238M 0 238M 0% /dev/shm /dev/sda1 190M 40M 141M 22% /boot 10.0.0.103:9421 17G 3.5G 14G 21% /mnt
測試一下
[root@web ~]# dd if=/dev/zero of=/mnt/1.txt bs=1M count=10 去chunk01端查看， [root@chunk01 ~]# tree /tmp/ /tmp/ ├── 00 │ └── chunk_0000000000000001_00000001.mfs ├── 01 ├── 02 ├── 03 同時chunk02 也同步了該數據 [root@chunk02 ~]# tree /tmp/ /tmp/ ├── 00 │ └── chunk_0000000000000001_00000001.mfs ├── 01 ├── 02 ├── 03 隨後我又找了一個客戶端 也掛載到/mnt下 也能發現1.txt這個文件 [root@m01 ~]# ll /mnt/ total 10240 -rw-r--r-- 1 root root 10485760 Oct 10 19:51 1.txt
其實搭建起來還是很簡單的，重點在於理解mfs服務的原理。
有關原理部分借鑑多個博客，如有侵權請聯繫刪除