1、FastDFS7Fastdfs 簡介7Fastdfs 系統結構圖7FastDFS 和mogileFS 的對比8MogileFS10Mogilefs 簡介10Mogilefs 組成部分10數據庫（MySQL）部分100）節點111）.112） trackers（工具113）Client114）Mogilefs 的特點121.應用層沒有特殊的組件要求122.3.無單點失敗12. 12自動的文件4. “比RAID 好多了”125.傳輸中立，無特殊協議136.簡單名空間137. 不用共享任何東西138. 不需要RAID139.碰到文件系統本身的不可知情況13HDFS14HDFS 簡介14特點和目標14

2、硬件故障141.142. 流式的數據簡單一致性模型153.通信協議154.基本概念151.數據塊(block)152. 元數據節點(Namenode)和數據節點(datanode)162.1 這些結點的用途162.2 元數據節點文件夾結構172.3 文件系統命名空間映像文件及修改日志182.4 從元數據節點的目錄結構212.5 數據節點的目錄結構21文件讀寫221.文件221.11.2文件示意圖22的過程23文件2. 寫入文件24寫入文件示意圖242.12.2寫入文件的過程24HDFS 不能提供的特點251. 低延時2. 大量. 25件263.多用戶寫，任意文件修改27TFS27TFS 簡介2

3、7TFS 系統的基本情況28應用規模28性能參數28TFS 的邏輯架構圖29結合架構圖做了進一步說明29TFS 的不足之處301、通用性方面。302、性能方面。303、用戶接口。304、代碼方面。305、技術文檔。316、件優化。31MooseFS（簡稱MFS）31MFS 簡介31MFS 的優點31網絡示意圖(如下)32MFS 文件系統結構33. 33包含的 4 種u .管理服務器 managing server (master)33u 元數據日志服務器Mogger serve（Mogger）33u 數據服務器data servers (chunkservers)34u .客戶端 client

4、 computers34的協作過程354 種MFS 讀寫進程35MFS 讀進程35MFS 寫進程36KFS38KFS 簡介38KFS 的特性38擴充381.自動2.有效性38粒度383.文件. 384.還原5.負載平衡396.數據完整性397.文件寫入398.契約399.支持FUSE3910.支持C+,Java,Python 方式的調用4011.提供了豐富的工具程序40.4012.提供了啟動和停止服務的KFS 高級特性40KFS 與HDFS 的比較401.體系結構圖的比較402.特點的比較41Ceph42的目標42Ceph系統42Ceph可以大致劃分為四部分42系統的概念架構43Ceph架構視

5、圖 1432.44架構視圖組件44Ceph客戶端45Ceph元數據服務器47Ceph. 49Ceph 對象其他有趣功能49的地位和未來50Ceph其他分布式文件系統50展望未來50FastDFSFastdfs 簡介 國人在mogileFS 基礎上進行改進的key-value 型文件系統，不支持FUSE,提供比 mogileFS 更好的性能 輕量級（移植性比較強，依賴性小？）的開源分布式文件系統 解決的問題：1.大容量的文件2.高并發的3.文件存取時的負載均衡 特色：實現了軟件方式的 RAID;支持服務器擴充；支持相同的文件只存一份，節省了磁盤空間限制：只能通過client api 方式，不支持

6、posix 方式適合范圍：大中型用來文件（如圖片、文檔、音頻、音頻等），即以文件為載體的服務FastDFS 服務端有兩個：（）和節點（），跟蹤器總要做調度工作，在上做負載均衡的作用，且可用多臺服務器進行均衡，這樣可避免單點故障的發生。文件支持HTTP通信協議：有專門協議，Fastdfs 系統結構圖FastDFS 和mogileFS 的對比1.FastDFS 完善程度較高，不需要二次開發即可直接使用；2.和MogileFs 相比，FastDFS 裁減了跟蹤用的數據庫，只有兩個角3.在系統中增加任何的服務器都很容易：增加tracker 服務器色：tracker 和storage。FastDFS 的

7、架構既簡化了系統，同時也消除了性能瓶頸；4. FastDFS 比MogileFS 更高效。表現在如下幾個方面：5. FastDFS 有著詳細的設計和使用文檔，而MogileFS 的文檔相對比較缺乏。6. FastDFS 的日志非常詳細，系統運行時發生的任何錯誤信息7. FastDFS 還對文件附加屬性（即meta data，如文件大小、圖都會到日志文件中，當出現問題時方便管理員錯誤所在。1） 參見上面的第 2 點，FastDFS 和MogileFS 相比，沒有文件索引數據庫，FastDFS 整體性能更高；2） 從采用的開發語言上看，FastDFS 比MogileFS 更底層、更高效。FastD

8、FS 用C 語言編寫，代碼量不到 2 ，沒有依賴其他開源軟件或程序包，安裝和部署特別簡潔；而MogileFS 用 perl 編寫；3） FastDFS 直接使用socket 通信方式，相對于 MogileFS 的H TTP 方式，效率更高。并且FastDFS 使用sendfile 傳輸文件，采用了內存零拷貝，系統開銷更 件傳輸效率更高。時，只需要修改 storage 和client 的配置文件（增加一行 tra cker 配置）；增加storage 服務器時，通常不需要修改任何配置文件，系統會自動將該卷中已有文件到該服務器；片寬度、高度等）進行存取，應用不需要使用數據庫來存儲這些信息。8. F

9、astDFS 從 V1.14 開始支持相同文件內容只保存一份，這樣可以節省空間，提高文件性能。MogileFSMogilefs 簡介 一種分布式文件系統，可支持文件自動備份的功能，提供可用性和擴展性，用 Perl 語言編寫，由于有依賴模塊的問題，安裝過程需要其他庫和模塊的支持，安裝不算容易。key-value文件系統，不支持 FUSE，應用程序它需要API，主要在web 領域處理海量小圖片，效率高，適用性：不支持對一個文件的隨機讀寫，只適合做一部分應用。比如圖片服務，靜態html 服務，即文件寫入后基本上那個不需要修改的應用。Mogilefs 組成部分0）數據庫（MySQL）部分mogdbse

10、tup 程序可用來初始化數據庫。數據庫保存了Mogilefs 的所有元數據，你可以單獨拿數據庫服務器來做，也可以跟其他程序跑在一起，數據庫部分非常重要，類似郵件系統的認證中心那么重要，如果這兒掛了，那么整個 Mogilefs將處于不可用狀態。因此最好是HA 結構。1）節點mogstored 程序的啟動將使本機成為一個節點。啟動時默認去讀/etc/mogilefs/mogstored.conf ，具體配置可以參考配置部分。mogstored 啟動后，便可以通過mogadm 增到cluster 中。一臺加這臺可以只運行一個mogstored 作為節點即可，也可以同時運行其他程序。2）tracker

11、s（）mogilefsd 即trackers 程序，類似 mogilefs 的wiki 上介紹的，trackers 做了很多工作，Replication ，Deletion，Query，Reaper，Monitor 等等。mogadm,mogtool 的所有操作都要跟trackers 打交道，Client 的一些操作也需要定義好trackers，因此最好同時運行多個trackers 來做負載均衡。trackers 也可以只運行在一臺上，也可以跟其他程序運行在一起，只要你配置好他的配置文件即可，默認在/etc/mogilefs/mogilefsd.conf。3）工具主要就是mogadm，mogt

12、ool 這兩個工具了，用來在命令行下控制整個mogilefs 系統以及查看狀態等等。4）ClientClient 實際上是一個 Perl 的pm，可以寫程序調用該pm 來使用mogilefs 系統，對整個系統進行讀寫操作。Mogilefs 的特點1. 應用層沒有特殊的組件要求2. 無單點失敗MogileFS 啟動的三個組件（節點、跟蹤用的數據庫），均可運行在多個上，因此沒有單點失敗。（你也可以將和節點運行在同一臺上，這樣你就沒有必要用 4 臺）推薦至少兩臺。3. 自動的文件基于不同的文件“分類”，文件可以被自動的到多個有足夠空間的節點上，這樣可以滿足這個“類別”的最少要求。比，你可以設置原始的

13、 JPEG 圖片需要如你有一個圖片至少三份，但實際只有 1 or 2 分拷貝，如果丟失了數據，那么 Mogile 可以重新建立遺失的拷貝數。用這種辦法，MogileFS (不做 RAID)可以節約磁盤，否則你將同樣的拷貝多份，完全沒有必要。4. “比RAID 好多了”區域網絡的 RAID（non-SAN RAID）的建立中，磁在一個非盤是冗余的，但主機不是，如果你整個壞了，那么文件也將不能o MogileFS 在不同的之間進行文件，因此文件始終是可用的。5. 傳輸中立，無特殊協議MogileFS 客戶端可以通過 NFS 或 HTTP 來和 MogileFS 的節點來通信，但首先需要告知一下。6

14、.簡單名空間文件通過一個給定的 key 來確定，是一個全局名空間。你可以生成多個命名空間，只要你愿意，但是這樣可能在同一 MogileFSkey。中，會造成7.不用共享任何東西MogileFS 不需要依靠昂貴的 SAN 來共享磁盤，每個只用維護好的磁盤。8.不需要RAID在MogileFS 中的磁盤可以是做了RAID 的也可以是沒有，如果是為了安全性著想的話RAID 沒有必要買了，因為MogileFS 已經提供了。9.碰到文件系統本身的不可知情況在 MogileFS 中的節點的磁盤可以被格式化成多種格（ext3,reiserFS 等等）。MogilesFS 會做內部目錄的，所以它碰到文件系統本

15、身的一些限制，比如一個目錄中的最大文件數。你可以放心的使用。HDFSHDFS 簡介HDFS 全稱是 Hadoop Distributed FileSystem。目前 HDFS 支持的使用接口除了Java 的還有，Thrift、C、FUSE、WebDAV、HTTP 等。HDFS 主要是Namenode（master）和一系列的 Datanode（workers）。特點和目標HDFS 使應用程序流式地它們的數據集。HDFS 是設計成適合批量處理的，而不是用戶交互式的。所以其重視數據吞吐量，而不1. 硬件故障硬件故障是計算機常見的問題。整個 HDFS 系統由數百或數千個存儲著文件數據片斷的服務器組成

16、。實際上它里面有非常巨大的組成部分，每一個組成部分都會頻繁地出現故障，這就意味著 HDFS 里的一些組成部分總是失效的，因此，故障的檢測和自動快速恢復是 HDFS 一個 的目標。2. 流式的數據的反應速度。亦即HDFS是為以流的方式存取大文件而是數據設計的。適用于幾百MB，GB以及TB，并寫一次讀多次的場合。而對于低延時數據、大量件、同時寫和任意的文件修改，則并不是十分適合。所有的通信協議都是在 TCP/IP 協議之上的。一個客戶確的配置端口的名字節點建立連接之后，它和名字節點的協議是 ClientProtocal 。數據節點和名字節點之間用DatanodeProtocal。基本概念1. 數據

17、塊(block)Ø HDFS(Hadoop Distributed File System)默認的最基本的存是 64M 的數據塊。儲Ø 和普通文件系統相同的是，HDFS 中的文件是被分成 64M 一塊的數據塊的。3. 簡單一致性模型大部分的 HDFS 程序對文件操作需要的是一次寫入，多次的。一個文件一旦創建、寫入、關閉之后就不需要修改了。這個假定簡化了數據一致的問題和高吞吐量的數據。4. 通信協議Ø 不同于普通文件系統的是，HDFS 中，如果一個文件小于一個數據塊的大小，并不占用空間。之所以將默認的block 大小設置為 64MB整個數據塊這么大，是因為block

18、-sized 對于文件很有幫助，同件更使傳輸的時間遠大于文件尋找的時間，這樣可以最大化地減少文件的時間在整個文件獲取總時間中的比例 。2. 元數據節點(Namenode)和數據節點(datanode)2.1 這些結點的用途2.1.1 元數據節點用來管理文件系統名空間1)其將所有的文件和文件夾的元數據保存在一個文件系統樹中。2)這些信息也會在硬盤上保存成以下文件：命名空間鏡像(namespace image)及修改日志(edit log)3)其還保存了一個文件包括哪些數據塊，分布在哪些數據節點上。然而這些信息并不在硬盤上，而是在系統啟動的時候從數據節點收集而成的。2.1.2 數據節點是文件系統中

19、真正數據的地方。1）客戶端(client)或者元數據信息(namenode)可以向數據節點請求寫入或者讀出數據塊。2) 其周期性的向元數據節點回報其的數據塊信息。2.1.3從元數據節點(secondary namenode)1)從元數據節點并不是元數據節點出現問題時候的備用節點，它和元數據節點負責不同的事情。2)其主要功能就是周期性將元數據節點名空間鏡像文件和修改日志合并，以防日志文件過大。這點在下面會相信敘述。3)合并過后名空間鏡像文件也在從元數據節點保存了一份，以防元數據節點失敗的時候，可以恢復。2.2 元數據節點文件夾結構· VERSION 文件是java properties

20、文件，保存了HDFS 的版本號。layoutVersion 是一個負整數，保存了HDFS 的持續化在硬盤o上的數據結構的格式版本號。namespaceID 是文件系統的o唯一標識符，是在文件系統初次格式化時生成的。cTime 此處為 0storageType 表示此文件夾中oo保存的是元數據節點的數據結構。2.3 文件系統命名空間映像文件及修改日志· 當文件系統客戶端(client)進行寫操作時，首先把它在修改日志中(edit log)· 元數據節點在內存中保存了文件系統的元數據信息。在了修改日志后，元數據節點則修改內存中的數據結構。namespaceID=12327370

21、62 cTime=0 storageType=NAME_NODE layoutVersion=-18· 每次的寫操作之前，修改日志都會同步(sync)到文件系統。· fsimage 文件，也即命名空間映像文件，是內存中的元數據在硬盤上的checkpoint，它是一種序列化的格式，并不能夠在硬盤上直接修改。· 同數據的機制相似，當元數據節點失敗時，則最新checkpoint 的元數據信息從fsimage 加載到內存中，然后逐一重新執行修改日志中的操作。· 從元數據節點就是用來幫助元數據節點將內存中的元數據信息checkpoint 到硬盤上的· c

22、heckpoint 的過程如下：o 從元數據節點通知元數據節點生成新的日志文件，以后的日志都寫到新的日志文件中。o 從元數據節點用 http get 從元數據節點獲得fsimage 文件及舊的日志文件。o 從元數據節點將fsimage 文件加載到內存中，并執行日志文件中的操作，然后生成新的fsimage 文件。從元數據節點獎新的fsimage文件用 http post 傳回元數據o節點元數據節點可以將舊的ofsimage 文件及舊的日志文件，換為新的fsimage 文件和新的日志文件(第一的)，然后更新fstime 文件，寫入此次checkpoint 的時間。這樣元數據節點中的fsimage文

23、件保存了最新的checkpointo的元數據信息，日志文件也重新開始，變的很大了。2.4 從元數據節點的目錄結構2.5 數據節點的目錄結構數據節點的 VERSION 文件格式如下：blk_<id>保存的是 HDFS 的數據塊，其中保存了具體的二進制數據。blk_<id>.meta 保存的是數據塊的屬性信息：版本信息，類型信息，和 checksum當一個目錄中的數據塊到達一定數量的時候，則創建子文件夾來保存數據塊及數據塊屬性文件讀寫1.文件1.1文件示意圖namespaceID=1232737062storageID=DS-1640411682--500

24、10-1254997319480cTime=0 storageType=DATA_NODE layoutVersion=-181.2 文件的過程使用 HDFS 提供的客戶端開發庫，的 Namenode 發起 RPC（Remote ProcedureCall）請求；Namenode 會視情況返回文件的部分或者全部block 列表，對于每個block，Namenode 都會返回有該block 拷貝的datanode 地址；客戶端開發庫會選取離客戶端最接近的datanode 來block；完當前 block 的數據后，關閉與當前的 datanode 連接，并為讀取下一個block 尋找最佳的data

25、node；當讀完列表的block 后，且文件還沒有結束，客戶端開發庫會繼續向Namenode 獲取下一批的block 列表。完一個 block 都會進行 checksum 驗證，如果datanode 時出現錯誤，客戶端會通知Namenode，然后再從下一個擁有該block拷貝的datanode 繼續讀。2. 寫入文件2.1寫入文件示意圖2.2寫入文件的過程1）使用 HDFS 提供的客戶端開發庫，的Namenode 發起RPC請求；2）Namenode 會檢查要創建的文件是否已經存在，創建者是否限進行操作，則會為文件創建一個，否則會讓客戶端拋出異常；3）當客戶端開始寫入文件的時候，開發庫會將文件

26、切分成多個packets，并在內部以"data queue"的形式管理這些 packets，并向Namenode 申請新的 blocks ， 獲取用來replicas 的合適的datanodes 列表，列表的大小根據在 Namenode 中對replication 的設置而定。4）開始以 pipeline（管道）的形式將 packet 寫入所有的replicas 中。開發庫把 packet 以流的方式寫入第一個 datanode，該 datanode 把該 packet之后， 再將其傳遞給在此 pipeline 中的下一個datanode，直到最后一個 datanode，這

27、種寫數據的流水線的形式。5）最后一個 datanode之后會返回一個 ack packet，在pipeline 里傳遞至客戶端， 在客戶端的開發庫內部維護著"ackqueue"，收到 datanode 返回的 ack packet 后會從"ack queue"移除相應的packet。如果傳輸過程中，有某個 datanode 出現了故障，那么當前的 pipeline會被關閉，出現故障的 datanode 會從當前的pipeline 中移除，剩余的block 會繼續剩下的datanode 中繼續以pipeline 的形式傳輸，同時Namenode 會分配一個

28、新的datanode，保持 replicas 設定的數量。HDFS 不能提供的特點1.低延時HDFS 不太適合于那些要求低延時（數十毫秒的應用程序，因為HDFS 是設計用于大吞吐量數據的，這是以一定延時為代價的。HDFS 是單Master 的，所有的對文件的請求都要經過它，當請求多時，肯定會有延時。當前，對于那些有低延時要求的應用程序，HBase是一個更好的選擇。現在 HBase 的版本是 0.20，相對于以前的版就是 goes real time。本，在性能上有了很大的提升，它的使用緩存或多 master 設計可以降低 client 的數據請求，以減少延時。還有就是對 HDFS 系統內部的修

29、改，這就得權衡大吞，HDFS 不是萬能的銀彈。吐量與低2.大量件因為Namenode 把文件系統的元數據放置在內存中，所以文件系統所能容納的文件數目是由Namenode 的內存大小來決定。一般來說，每一個文件、文件夾和 Block 需要占據 150 字節左右的空間， 所以，如果你有 100 萬個文件，每一個占據一個 Block，你就至少需要 300MB 內存。當前來說，數百萬的文件還是可行的，當擴展到數十億時，對于當前的硬件水平來說就沒法實現了。還有一個問題就是，因為 Map task 的數量是由 splits 來決定的，所以用 MR 處理件時，就會產生過多的 Map task，線程管理開銷將

30、會增大量的加作業時間。舉個例子，處理 10000M 的文件，若每個 split 為 1M， 那就會有 10000 個Map tasks，會有很大的線程開銷；若每個 split為 100M，則只有 100 個 Map tasks，每個Map task 將會有的事情做，而線程的管理開銷也將減小很多。要想讓HDFS 能處理好件，有不少方法：1、利用 SequenceFile、MapFile、Har 等方式歸檔件歸檔起來管理，HBase 就是基于件，這個方法的原理就是把此的。對于這種方法，如果想找回原來的件內容，那就必須得知道與歸檔文件的關系。2、橫向擴展，一個 Hadoop 集群能管理的件有限，那就

31、把幾個Hadoop 集群拖在一個虛擬服務器后面，形成一個大的 Hadoop集群。也是這么干過的。3、多Master 設計，這個作用顯而易見了。正在研發中的GFSII 也要改為分布式多Master 設計，還支持 Master 的Failover，而且Block 大小改為 1M，有意要調優處理件啊。附帶個 Alibaba DFS 的設計，也是多 Master 設計，它把 Metadata了，由多個 Metadata的和管理節點和一個Master 節點組成。3.多用戶寫，任意文件修改目前 Hadoop 只支持單用戶寫，不支持并發多用戶寫。可以使用 Append 操作在文件的末尾添加數據，但不支持在文

32、件的任意位置進行修改。這些特性可能會在將來的版本中加入，但是這些特性的加入將會降低Hadoop 的效率。利用 Chubby、ZooKeeper 之類的分布式協調服務來解決一致性問題。TFSTFS 簡介File System（TFS）作為淘寶的分布式文件系統，是一個擴展、用、高性能、面向互聯網服務的分布式文件系統，其設計目標是“支持海量的非結構化數據”。海量件的隨機讀寫性能做了特殊優化，承載著淘寶主站所有圖片、商品描述等數據。TFS 系統的基本情況1.完全扁平化的數據組織結構，拋棄了傳統文件系統的目錄結構。2.在塊設備基礎上建立自有的文件系統，減少 EXT3 等文件系統數據碎片帶來的性能損耗。3

33、.單進程管理單塊磁盤的方式，摒除RAID5 機制。4.帶有 HA 機制的節點，在安全穩定和性能復雜度之間取得平衡。5.盡量縮減元數據大小，將元數據全部加載入內存，提升速度。6.跨機架和IDC 的負載均衡和冗余安全策略。7.完全平滑擴容。應用規模達到“數百臺PCServer，PB 級數據量，百億數據級別”性能參數TFS 在淘寶的部署環境中前端有兩層緩沖，到達 TFS 系統的請求非常離散，所以 TFS 內部是沒有任何數據的內存緩沖的，包括傳統文件系統的內存緩沖也不存在基本上可以達到單塊磁盤隨機IOPS（即I/O per second）理論最大值的 60%左右，整機的輸出隨增加而線性增加。TFS 的

34、邏輯架構圖結合架構圖做了進一步說明1.TFS 尚未對最終用戶提供傳統文件系統API ， 需要通過TFSClient 進行接口，現有JAVA、JNI、C、PHP 的客戶端2.TFS 的NameServer 作為中心節點，所有數據節點的運行狀況，負責讀寫調度的負載均衡，同時管理一級元數據用來幫助客戶端需要的數據節點3.TFS 的DataServer 作為數據節點，負責數據實際發生的負載均衡和數據冗余，同時管理元數據幫助客戶端獲取真實的業務數據。TFS 的不足之處TFS 與目前一些主流的開源分布式文件系統設計思想是相似的，如HDFS, MFS, KFS, Sector。其擴展、用性是很好的，然而也存

35、在一定不足，如通用性、用戶接口、性能等方面。1、通用性方面。TFS 目前只支持件的應用，大文件應用是不支持的。對小圖片、網頁等幾十 KB 內的數據點播 VOD、文件非常適用，但對等應用暫時無法適用。2、性能方面。Client 寫文件是同步處理的，需要等所有 dataserver 寫后才能返回，這很是影響性能。3、用戶接口。TFS 沒有提供POSIX 接口，提供的 API 也與標準接口不一致。另外，TFS 有的文件命名規則，如果用戶使用自定義的文件名，則需要自已維護文件名與TFS 文件名之間的關系。4、代碼方面。使用了C+實現，感覺相對臃腫一點，如果用純C 實現應該會簡潔不少。代碼注釋基本沒有，

36、代碼質量也不是很好。5、技術文檔。有一些文檔，但顯然非常不夠深入和全面。6、件優化。稱海量件的隨機讀寫性能做了特殊優化，現在只看件存放與一個Block 中，這與 Squid 中的COSS 原理到把眾多相似。其他特殊優化措施未知，LOFS(Lost of small files)是個難點問題。MooseFS（簡稱 MFS）MFS 簡介MFS 是一款網絡分布式 文件系統。它把數據分散在多臺服務器上，但對于用戶來講，看到的只是一個源。MFS 也像其他類unix 文件系統一樣，包含了層級結構（目錄樹），著文 件屬性（權限，最后和修改時間），可以創建特殊的文件（塊設備，字符設備，管道，套接字），符號，硬

37、。MFS 的優點1.開源2.通用文件系統，不需要修改上層應用就可以使用3.可以擴容，體系架構可伸縮性極強4.部署簡單5.體系架構用，所有組件無單點故障6.文件對象用，可任意設置文件的冗余程度，而絕對影響讀或寫的性能，只會。7.提供windows 回收站的功能8.提供類似java 語言的回收（GC）9.提供netapp,emc,ibm 等商業的snapshot 特性。10.GFS 的一個c 實現11.提供web gui接口12.提高隨機讀或寫的效率13.提高海量件的讀寫效率網絡示意圖(如下)MFS 文件系統結構包含的 4 種u 管理服務器managing server (master)負責各個數

38、據服務器的管理,文件讀寫調度,文件空間回收以及恢復.多節點拷貝u 元數據日志服務器Mogger serve（Mogger）負 責 備 份 master 服 務 器 的 變 化 日 志 文 件 ， 文 件 類 型 為changelog_ml.*.mfs，以便于在 master server 出問題的時候接替其進行工作。元數據在Master 的內存中，同時會保存一份在硬盤上（作為臨時更新的二進制文件和立即更新的增量日志方式）u 數據服務器data servers (chunkservers)負責連接管理服務器,聽從管理服務器調度,提供空間，并為客戶提供數據傳輸. 數據文件被分成 64Mb 大小的塊

39、，每個塊被分散的存塊服務器的硬盤上，同時塊服務器上還會其他塊服務器上塊文件的副本。u 客戶端client computers通過 fuse 內核接口掛接管理服務器上所管理的數據服務器,.看起來共享的文件系統和本地 unix 文件系統使用一樣的效果.客戶端只需要mount 上MFS 就可像操作其他文件系統的文件一樣操作MFS 中的文件了。操作系統的內核把對文件的操作傳遞給 FUSE 模塊，這個模塊用來和mfsmount 進程進行通信。mfsmount 進程后續通過網絡和管理服務器和數據塊服務器進行通信。整個過程對用戶來講是透明的。4 種的協作過程在對所有元數據文件（文件創建，文件刪除，讀文件夾，

40、和更改屬性，改變文件大小等等涉及到在 MFSMETA 上的特殊文件）進行操作的過程中，mfsmount 和管理服務器建立通信，然后開始和寫入數據。數據到所有數據服務器中有相關文件塊的一臺上。在完成寫操作之后，管理服務器收到文件長度和最后修改時間的更新信息。而且，數據服務器之間進行通信，保證每個塊在不同的塊服務器上都有拷貝。因為文件塊存在多個拷貝，所以，任何一臺數據服務器不可用都是影響到文件的正常的。整體來看 moosfs，他的設計理念還是很符合gfs 的，從架構圖來看，整個系統實現起來還是很容易的。不過有一點值得注意的還是，對于master 主機來說，這個是一個單點，會存在隱患，在正式環境應用

41、的時候，如何解決這里，是個關鍵。MFS 讀寫進程MFS 讀進程MFS 寫進程PS: MFS 提供文件系統級回收站的配置，這個回收站在整個文件系統工作。那樣如果用戶刪除一個文件，這個文件可以一直存在回收站中，只要管理員想留著它。回收站中的文件會在一段配置時間之后自動清理。KFSKFS 簡介KFS（KOSMOS DISTRIBUTED FILE SYSTEM），一個類似 GFS、Hadoop中HDFS 的一個開源的分布式文件系統。可以應用在諸如圖片、搜索引擎、網格計算、數據挖掘這樣需要處理大數據量的網絡應用中。與hadoop 集成得也比較好，這樣可以充分利用了hadoop 一些現成的功能，基于C+

42、。KFS 的特性1.自動擴充添加新的chunckserver,系統自動感知2.有效性機制保證文件有效性，一般文件會被以三種方式，當其中一個chunkserver 出現錯誤的時候，影響數據的；3.文件粒度可以配置文件的粒度，最大可以被64 份4.還原當其中一個Chunckserver 出現故障的時候，Metaserver 會強制使用其他的chunckserver5.負載平衡系 統 周 期 地 檢 查 chunkservers 的 磁 盤 利 用 ， 并 重 新 平 衡chunkservers 的磁盤利用，HDFS 現在還沒有支持6.數據完整性當要數據時檢查數據的完整性，如果檢驗出錯使用另外的備份

43、覆蓋當前的數據7.文件寫入當一個應用程序創建了一個文件，這個文件名會被立刻寫入文件系統，但為了性能，寫入的數據會被緩存在kfs 客戶端.并且周期性的從緩存中把數據更 新到 chunkserver 中。當然，應用程序也可以強制把數據更新到服務器上。一旦數據被更新到服務器，就可以被有效的了。（我怎么能知道這個文件什么時候可以了呢？）8.契約使用契約來保證Client 緩存的數據和文件系統中的文件保持一致性9.支持FUSE在linux 系統下，可以通過 Fuse一個文件夾，從而可以很方便的kfs 的文件10.支持C+,Java,Python 方式的調用11.提供了豐富的工具程序如kfsshell,c

44、p2kfs 等12.提供了啟動和停止服務的KFS 高級特性1.支持同一文件多次寫入和Append，不過不能在文件中間數據。（HDFS 支持一次寫入多次，不支持Append）2.文件及時生效，當應用程序創建一個文件時,文件名在系統馬上有效。（HDFS 文件只當輸入流關閉在系統中有效，因此，如果應用程序在關閉前出現異常導致沒有關閉輸入流，數據將會丟失。)這一點好像也不是很好，如果輸入流中斷，在 kfs 里會留下一個錯誤的文件，當時會出現錯誤，好像也沒有太大的意義。KFS 與 HDFS 的比較1.體系結構圖的比較2.特點的比較兩者都是GFS 的開源實現，而 HDFS 是Hadoop 的子項目，用 J

45、ava 實現，為Hadoop 上層應用提供高吞吐量的可擴展的大文件服務。KFS 是一個高性能的分布式文件系統，主要網絡規模的應用，例如日志數據，Map/Reduce 數據等. 用C+實現。它們的元數據管理采用集中式方式實現，數據實體先分片然后分布式。CephCeph 的目標1.可輕松擴展到數 PB 容量2.對多種工作負載的高性能（每秒輸入/輸出操作IOPS和帶寬）3.靠性不幸的是，這些目標之間會互相競爭（例如，可擴展性會降低或者抑制性能或者影響可靠性）。Ceph 開發了一些非常有趣的概念（例如，動態元數據分區，數據分布和），這些概念在本文中只進行簡短地探討。Ceph 的設計還包括保護單一點故障

46、的容錯功能，它假設大規模（PB 級）故障是常見現象而不是例外情況。最后，它的設計并沒有假設某種特殊工作負載，但是包括適應變化的工作負載，提供最佳性能的能力。它利用 POSIX 的兼容性完成所有這些任務，它對當前依賴 POSIX 語義（通過以 Ceph 為目標的改進）的應用進行透明的部署。最后，Ceph 是開源分布式，也是主線Linux 內核（2.6.34）的一部分。Ceph系統可以大致劃分為四部分1. 客戶端（數據用戶），2. 元數據服務器（緩存和同步分布式元數據），3.一個對象集群（將數據和元數據作為對象，執行其他關鍵職能）4. 集群監視器（執行監視功能）。Ceph系統的概念架構架構視圖 1

47、如上圖 1 所示，客戶使用元數據服務器，執行元數據操作（來確定數據位置）。元數據服務器管理數據位置，以及在何處新數據。值集群（標為 “元數據 I/O”）。實得注意的是，元數據在一個際的文件 I/O 發生在客戶和對象集群之間。這樣一來，更次的 POSIX 功能（例如，打開、關閉、重命名）就由元數據服務器管理，不過 POSIX 功能（例如讀和寫）則直接由對象集群管理。架構視圖 2Ceph一系列服務器通過一個客戶界面系統，這就明白了元數據服務器和對象級器之間的關系。分布式系統可以在一設備的格式（Extent and B-tree-based些層中查看，包括一個Object File System E

48、BOFS 或者一個備選），還有一個設計用于管理數據，故障檢測，恢復，以及隨后的數據遷移的覆蓋管理層，叫做 Reliable Autonomic Distributed Object Storage（RADOS）。最后，監視器用于識別組件故障，包括隨后。Ceph 組件Ceph 和傳統的文件系統之間的重要差異之一就是，它將智能在了環境而不是文件系統本身。圖 3 顯示了一個簡單的 Ceph系統。Ceph Client 是Ceph 文件系統的用戶。Ceph Metadata Daemon 提供了元數據服務器，而 Ceph Object Storage Daemon 提供了實際（對數據和元數據兩者）。最

49、后，Ceph Monitor 提供了集群管理。要注意的是，Ceph 客戶，對象端點，元數據服務器（根據文件系統的容量）可以有許多，而且至少有一對冗余的監視器。Ceph 客戶端內核或用戶空間早 期 版 本 的 Ceph利 用 在 User SpacE （ FUSE ） 的Filesystems，它把文件系統推入到用戶空間，還可以很大程度上簡化其開發。但是今天，Ceph 已經被集成到主線內核，使其更快速，因為用戶空間上下文交換機對文件系統 I/O 已經不再需要。因為 Linux 顯示文件系統的一個公共界面（通過虛擬文件系統交換機 VFS），Ceph 的用戶圖就是透明的。管理員的圖肯定是不同的，考慮

50、到很多服務器會包含系統這一潛在因素。從用戶的角度看，他們大容量的系統，卻不知道下面聚一個大容量的池的元數據服務器，監視器，還有的對象設備。用戶只是簡單地看到一個安裝點，在這點上可以執行標準文件I/OCeph 文件系統 或者至少是客戶端接口 在 Linux 內核中實現。值得注意的是，在大多數文件系統中，所有的和智能在內核的文件系統源本身中執行。但是，在 Ceph 中，文件系統的智能分布在節點上，這簡化了客戶端接口，并為 Ceph 提供了大規模（甚至動態）擴展能力。Ceph 使用一個有趣的備選，而不是依賴分配列表（將磁盤上的到指定文件的元數據）。Linux塊圖中的一個文件會分配到一個來自元數據服務器的 inode number（INO），對于文件這是一個唯一的標識符。然后文件被推入一些對象中（根據文件的大小）。使用 INO 和 object number（ONO），每個對象都分配到一個對象ID（OID）。在 OID 上使用一個簡單的，每個對象都被分配到一個放置組。放置組（標識為