分散式檔案系統

天府雲創發表於2018-09-05
分散式

分散式檔案系統

相對於本機端的檔案系統而言，分散式檔案系統（英語：Distributed file system, DFS），或是網路檔案系統（英語：Network File System），是一種允許檔案通過網路在多臺主機上分享的檔案系統，可讓多機器上的多使用者分享檔案和儲存空間。 在這樣的檔案系統中，客戶端並非直接訪問底層的資料儲存區塊，而是通過網路，以特定的通訊協議和伺服器溝通。藉由通訊協議的設計，可以讓客戶端和伺服器端都能根據訪問控制清單或是授權，來限制對於檔案系統的訪問。 相對地，在一個分享的磁碟檔案系統（英語：shared disk file system）中，所有節點對資料儲存區塊都有相同的訪問權，在這樣的系統中，訪問許可權就必須由客戶端程式來控制。 分散式檔案系統可能包含的功能有：透通的資料複製（英語：replication (computer science)）與容錯（英語：fault tolerance）。也就是說，即使系統中有一小部分的節點離線，整體來說系統仍然可以持續運作而不會有資料損失（英語：data loss）。 分散式檔案系統和分散式資料儲存的界線是模糊的，但一般來說，分散式檔案系統是被設計用在區域網，比較強調的是傳統檔案系統概念的延伸，並通過軟體方法來達成容錯。而分散式資料儲存，則是泛指應用分散式運算技術的檔案和資料庫等提供資料儲存服務的系統。

分散式系統（distributed system）是建立在網路之上的軟體系統。正是因為軟體的特性，所以分散式系統具有高度的內聚性和透明性。因此，網路和分散式系統之間的區別更多的在於高層軟體（特別是作業系統），而不是硬體。內聚性是指每一個資料庫分佈節點高度自治，有本地的資料庫管理系統。透明性是指每一個資料庫分佈節點對使用者的應用來說都是透明的，看不出是本地還是遠端。在分散式資料庫系統中，使用者感覺不到資料是分佈的，即使用者不須知道關係是否分割、有無副本、資料存於哪個站點以及事務在哪個站點上執行等。

傳統紙筆——>磁碟磁帶光碟——>單機時代——>獨立檔案伺服器——>儲存伺服器/裝置——>分散式檔案系統-->未來量子通訊

專業測評

常見的分散式檔案系統有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自適用於不同的領域。它們都不是系統級的分散式檔案系統，而是應用級的分散式檔案存 儲服務。

分散式軟體系統(Distributed Software Systems)是支援分散式處理的軟體系統,是在由通訊網路互聯的多處理機體系結構上執行任務的系統。它包括分散式作業系統、分散式程式設計語言及其編譯(解釋)系統、分散式檔案系統和分散式資料庫系統等。

分散式作業系統

負責管理分散式處理系統資源和控制分散式程式執行。它和集中式作業系統的區別在於資源管理、程式通訊和系統結構等方面。

分散式程式設計語言

用於編寫執行於分散式計算機系統上的分散式程式。一個分散式程式由若干個可以獨立執行的程式模組組成，它們分佈於一個分散式處理系統的多臺計算機上被同時執行。它與集中式的程式設計語言相比有三個特點：分佈性、通訊性和穩健性。

分散式檔案系統

具有執行遠端檔案存取的能力,並以透明方式對分佈在網路上的檔案進行管理和存取。

分散式資料庫系統

由分佈於多個計算機結點上的若干個資料庫系統組成,它提供有效的存取手段來操縱這些結點上的子資料庫。分散式資料庫在使用上可視為一個完整的資料庫,而實際上它是分佈在地理分散的各個結點上。當然,分佈在各個結點上的子資料庫在邏輯上是相關的。

分散式郵件系統

分散式郵件系統的部署設計，即同一域名下，跨地域部署的郵件系統。適用 於在各地設有分部的政府機構或者大型集團，有效管理各地的人員結構，同時提高了郵件伺服器應用效率。 

分散式郵件系統由多個資料中心組成，大量分支機構或較小的分散站點與資料中心的連線。分支機構需要建立自己的郵件伺服器，來加快處理當地分支機構的郵件。承載相應的資料處理量。以提高郵件處理能力，郵件收發速度，郵件功能模組化。

名詞解釋

網路檔案系統

早期的unix和nethud也是一種網路作業系統，網路作業系統和網路檔案系統是一種包含關係。

(NFS) 最早由Sun微系統公司作為TCP/IP網上的檔案共享系統開發。Sun公司估計現在大約有超過310萬個系統在執行NFS，大到大型計算機、小至PC機，其中至少有80%的系統是非Sun平臺。

Andrew檔案系統

(AFS) 結構與NFS相似，由卡內基·梅隆大學資訊科技中心(ITC)開發、現由前ITC職員組成的Transarc公司負責開發和銷售。AFS較NFS有所增強。

分散式檔案系統

(DFS) 是AFS的一個版本，作為開放軟體基金會(OSF)的分散式計算環境(DCE)中的檔案系統部分。

如果檔案的訪問僅限於一個使用者，那麼分散式檔案系統就很容易實現。可惜的是，在許多網路環境中這種限制是不現實的，必須採取併發控制來實現檔案的多使用者訪問，表現為如下幾個形式：

只讀共享 任何客戶機只能訪問檔案，而不能修改它，這實現起來很簡單。

受控寫操作 採用這種方法，可有多個使用者開啟一個檔案，但只有一個使用者進行寫修改。而該使用者所作的修改並不一定出現在其它已開啟此檔案的使用者的螢幕上。

併發寫操作 這種方法允許多個使用者同時讀寫一個檔案。但這需要作業系統作大量的監控工作以防止檔案重寫，並保證使用者能夠看到最新資訊。這種方法即使實現得很好，許多環境中的處理要求和網路通訊量也可能使它變得不可接受。

分散式系統的優點

分散式系統與集中式系統相比較而言的優點

系統傾向於分散式發展潮流的真正驅動力是經濟。25年前，計算機權威和評論家Herb Grosch指出CPU的計算能力與它的價格的平方成正比，後來成為Grosch定理。也就是說如果你付出兩倍的價錢，就能獲得四倍的效能。這一論斷與當時的大型機技術非常吻合，因而使得許多機構都盡其所能購買最大的單個大型機。

隨著微處理機技術的發展，Grosch定理不再適用了。到了二十一世紀初期，人們只需花幾百美元就能買到一個CPU晶片，這個晶片每秒鐘執行的指令比80年代最大的大型機的處理機每秒鐘所執行的指令還多。如果你願意付出兩倍的價錢，將得到同樣的CPU，但它卻以更高的時鐘速率執行。因此，最節約成本的辦法通常是在一個系統中使用集中在一起的大量的廉價CPU。所以，傾向於分散式系統的主要原因是它可以潛在地得到比單個的大型集中式系統好得多的價效比。實際上，分散式系統是通過較低廉的價格來實現相似的效能的。

與這一觀點稍有不同的是，我們發現微處理機的集合不僅能產生比單個大型主機更好的效能價格比，而且還能產生單個大型主機無論如何都不能達到的絕對效能。例如，按二十一世初期的技術，我們能夠用10,000個現代CPU晶片組成一個系統，每個CPU晶片以50 MIPS（每秒百萬指令）的速率執行，那麼整個系統的效能就是500,000 MIPS。而如果單個處理機（即CPU）要達到這一效能，就必需在2×10-12 秒（2 微微秒，0.002納秒）的時間內執行一條指令，然而沒有一個現存的計算機能接近這個速度，從理論上和工程上考慮都認為能達到這一要求的計算機都是不可能存在的。理論上，愛因斯坦的相對論指出光的傳播速度最快，它能在2 微微秒內傳播0.6毫米。實際上，一個包含於邊長為0.6 毫米大小的立方體內的具有上面所說的計算速度的計算機產生大量的熱量就能將它自己立即熔掉。所以，無論是要以低價格獲得普通的效能還是要以較高的價格獲得極高的效能，分散式系統都能夠滿足。

另一方面，一些作者對分散式系統和並行系統進行了區分。他們認為分散式系統是設計用來允許眾多使用者一起工作的，而並行系統的唯一目標就是以最快的速度完成一個任務，就像我們的速度為500,000 MIPS的計算機那樣。我們認為，上述的區別是難以成立的，因為實際上這兩個設計領域是統一的。我們更願意在最廣泛的意義上使用“分散式系統”一詞來表示任何一個有多個互連的CPU協同工作的系統。

建立分散式系統的另一原因在於一些應用本身是分散式的。一個超級市場連鎖店可能有許多分店，每個商店都需要採購當地生產的商品（可能來自本地的農場）、進行本地銷售，或者要對本地的哪些蔬菜因時間太長或已經腐爛而必須扔掉作出決定。因此，每個商店的本地計算機能明瞭存貨清單是有意義的，而不是集中於公司總部。畢竟，大多數查詢和更新都是在本地進行的。然而，連鎖超級市場的高層管理者也會不時地想要了解他們還有多少甘藍。實現這一目標的一種途徑就是將整個系統建設成對於應用程式來說就像一臺計算機一樣，但是在實現上它是分佈的，像我們前面所描述的一個商店有一臺機器。這就是一個商業分散式系統。

另一種固有的分散式系統是通常被稱為計算機支援下的協同工作系統（CSCW，Computer Supported Cooperative Work）。在這個系統中，一組相互之間在物理上距離較遠的人員可以一起進行工作，例如，寫出同一份報告。就計算機工業的長期發展趨勢來說，人們可以很容易的想像出一個全新領域--計算機支援的協同遊戲（CSCG：Computer Supported Cooperative Games）。在這個遊戲中，不在同一地方的遊戲者可以實時的玩遊戲。你可以想像，在一個多維迷宮中玩電子捉迷藏，甚至是一起玩一場電子空戰，每個人操縱自己的本地飛行模擬器去試著擊落別的遊戲者，每個遊戲者的螢幕上都顯示出其飛機外的情況，包括其它飛入它的視野的飛機。

同集中式系統相比較，分散式系統的另一個潛在的優勢在於它的高可靠性。通過把工作負載分散到眾多的機器上，單個晶片故障最多隻會使一臺機器停機，而其它機器不會受任何影響。理想條件下，某一時刻如果有5%的計算機出現故障，系統將仍能繼續工作，只不過損失5%的效能。對於關鍵性的應用，如核反應堆或飛機的控制系統，採用分散式系統來實現主要是考慮到它可以獲得高可靠性。

最後，漸增式的增長方式也是分散式系統優於集中式系統的一個潛在的重要的原因。通常，一個公司會買一臺大型主機來完成所有的工作。而當公司繁榮擴充、工作量就會增大，當其增大到某一程度時，這個主機就不能再勝任了。僅有的解決辦法是要麼用更大型的機器（如果有的話）代替現有的大型主機，要麼再增加一臺大型主機。這兩種作法都會引起公司運轉混亂。相比較之下，如果採用分散式系統，僅給系統增加一些處理機就可能解決這個問題，而且這也允許系統在需求增長的時候逐漸進行擴充。表1-1中總結了以上這些優點。

專案

描述

經濟

微處理機提供了比大型主機更好的效能價格比

速度

分散式系統總的計算能力比單個大型主機更強

固有的分佈性

一些應用涉及到空間上分散的機器

可靠性

如果一個機器崩潰,整個系統還可以運轉

漸增

計算能力可以逐漸有所增加

從長遠的角度來看，主要的驅動力將是大量個人計算機的存在和人們共同工作與資訊共享的需要，這種資訊共享必需是以一種方便的形式進行的，而不受地理或人員、資料，機器的物理分佈的影響。

分散式系統與獨立PC機相比較的優點

既然使用微處理機是一種節省開支的辦法，那麼為什麼不給每個人一臺個人計算機，讓他們各自獨立地工作呢？一則，許多使用者需要共享資料。例如，機票預訂處的工作人員需要訪問儲存航班以及現有座位資訊的主資料庫。假如給每個工作人員都備份整個資料庫，那麼在實際中這是無法工作的，因為沒有人知道其他工作人員已經賣出了哪些座位。共享的資料是上例和許多其它應用的基礎，所以計算機間必須互連。而計算機互連就產生了分散式系統。

共享並不只是僅僅涉及資料。昂貴的外設，例如彩色鐳射印表機，照相排版機以及大型儲存裝置（如自動光碟點唱機）都是共享資源。

把一組孤立的計算機連成一個分散式系統的第三個原因是它可以增強人與人之間的溝通，電子郵件比信件、電話和傳真有更多的誘人之處。它比信件快的多，不像電話需要兩人同時都在，也不像傳真，它所產生的檔案可在計算機中進行編輯、重排和儲存，也可以由文字處理程式來處理。

最後，分散式系統可能比給每個使用者一個獨立的計算機更靈活。儘管一種可能的模式是給每個人一臺個人計算機並把它們通過LAN聯在一起，但這種方式並不是唯一的。另外還存在一種模式是將個人計算機和共享計算機混合連線在一起（這些機器的型號可能並不完全相同），使工作能夠在最合適的計算機上完成，而並不總是在自己的計算機上完成。這種方式可以使工作負荷能更有效地在計算機系統中進行分配。系統中某些計算機的失效也可以通過使其工作在其它計算機上進行而得到補償。表1-2總結了以上所介紹的各點。

專案

描述

資料共享

允許多個使用者訪問一個公共的資料庫

裝置共享

允許多個使用者共享昂貴的外圍裝置(如彩色印表機)

通訊

使得人們之間的通訊更加容易,如通過電子郵件

靈活性

用最有效的方式將工作負荷分配到可用的機器上

主流開源分散式系統架構都有哪些？

分散式檔案系統（Distributed File System）是指檔案系統管理的物理儲存資源不一定直接連線在本地節點上，而是通過計算機網路與節點相連。分散式檔案系統的設計基於客戶機/伺服器模式。一個典型的網路可能包括多個供多使用者訪問的伺服器。另外，對等特性允許一些系統扮演客戶機和伺服器的雙重角色。例如，使用者可以“發表”一個允許其他客戶機訪問的目錄，一旦被訪問，這個目錄對客戶機來說就像使用本地驅動器一樣，下面是三個基本的分散式檔案系統。

中文名：分散式檔案系統      外文名：Distributed File System

基    於：客戶機/伺服器模式    分    類：NFS AFS KASS DFS

項鍊方式：通過計算機網路與節點相連（這樣就決定網路架構必須要採用內網或者專線，不然分散式檔案儲存毫無意義）    

相關名詞：分散式檔案儲存和分散式計算

一些常見的分散式系統大類：

a）支援持久化儲存的分散式儲存系統；

b）著重計算的分散式計算框架；

c）分散式訊息佇列

根據不同的應用的領域，把上述分類細化，常見分散式儲存系統分為：

  1. 分散式協同系統（分散式日誌複製）
  2. 分散式任務排程框架
  3. 流計算框架
  4. 分散式檔案/物件系統
  5. 分散式NoSQL儲存
  6. 分散式關聯式資料庫（OLAP、OLTP）；
  7. 各種訊息佇列mq
  • 分散式協調系統（日誌複製系統）其實就是paxos演算法及其變體的實現，典型的有zookeeper、etcd；一般來說只存少量的後設資料資訊，重點在高可用強一直，是很多分散式系統不可或缺的元件；
  • 開源的分散式檔案/物件系統比較有名的包括Lustre（HPC）GlusterFS（NAS NFS）、HDFS（hadoop）、ceph（虛機塊儲存）、swift（restful物件儲存），各有不同的領域。
  • NoSQL分散式儲存種類和數量最多，按照Martin Fowler大師的分類，包括Aggregated Oriented NoSQL和圖資料庫NoSql；Aggregated Oriented NoSQL大致分為3類：

1.Key-value NoSQL，例如Redis Riak等；

2.column family NoSQL(wide column store)，典型的是Hbase Cassandra；

3.document NoSQL,典型的是mongodb

有幾個大的維度來區分：  有狀態、無狀態；著重儲存還是著重計算；long service還是批處理。

功能分: olap, oltp, 分散式日誌，share-nothing, numa, MapReduce, DAG.
資料分:表格，物件，檔案，關係。
架構分: 類bigtable, 類dynamo
日誌複製分: primary-backup，gossip，quorum.同步，半同步，非同步。
資料切分分:hash,range
workload分:很多種
membership分:自己選主，主控節點選主，dlm選主。
CAP折衷分:強一致性犧牲可用性，最終一致性更高的可用性。

既然是關於分散式檔案系統的，就多說幾句

1.GlusterFS 檔案系統標準的posix介面支援，可以做分散式NAS，也有人HPC，甚至支援KVM的虛機卷；做分散式NAS最多，其他方面用的不多，很多網際網路視訊公司用GlusterFS來做片庫；

2.ceph，支援塊ceph RBD，物件ceph RGW，檔案cephfs；ceph RBD和ceph RGW比較成熟，在openstack社群比較火，做虛機塊儲存用的很多，cephfs的前期bug比較多，社群目前也在解決這些問題；

3.Lustre，比較老牌的分散式檔案系統，部署在多個san陣列上，不支援副本，支援分散式鎖，主要做HPC高效能運算；

4.HDFS只支援追加寫，設計中沒有考慮修改寫、截斷寫、稀疏寫等複雜的posix語義，目的並不是通用的檔案系統，一般作為hadoop ecosystem的儲存引擎；

5.moosefs 比較接近GoogleFS的c++實現，通過fuse支援了標準的posix，算是通用的檔案系統，可惜社群不是太活躍；

6.IBM的GPFS也是一個很老牌的分散式檔案系統，非常強大，有兩個分支，一個是通用檔案系統，一個是相容hadoop mapreduce，可惜沒有開源，國內也沒人買的起；

7.facebook Haystack是一個專有的圖片儲存系統的原型，適合小檔案和worm場景（write once read many），本身並沒有開源，github上已經有一個比較成熟的實現Terry-Mao/bfs（不是百度的BFS）

這裡有一個混淆的概念，分散式檔案系統vs分散式計算。
我看題目的描述，你需要分散式計算（音視訊處理放在雲端），所以你後來提到的GlusterFS等等不能解決你的問題。它們只是分散式檔案系統。

分散式計算至少要求任務是可分解的，音視訊要看你具體的檔案格式，沒有通用的解決方案。
傳統的處理音訊視訊大檔案的方法是SAN，用一臺很貴的機器，接一個很貴的網，連上很貴的儲存。

主要看你的具體業務和儲存+訪問場景，其實現在音視訊比如製播之類用得多的還是類似於SAN之類的東西。

FastDFS 針對大量小檔案儲存有優勢，這種場景嗯...沒有用過。
hadoop的hdfs適合大檔案儲存，順序讀取型別的應用，你看看你們的應用場景是否適合，btw,hdfs隨機訪問延時挺大的. 順序訪問也要優化好才吞吐高啊。

Atitit 分散式檔案系統總結 fastdfs nfs smb webdav ftp

webdav 是個好的方案。。。Server client都有

ftp也方便java lib實現server client。。。

Smb 服務端麻煩。。沒有好的java lib server實現。。。

nfs 也是沒有好的 java libserver實現

fastdfs 沒有lib實現模式，只能原始碼安裝

FastDFS特性及問題思考

FastDFS是國人開發的一款分散式檔案系統，目前社群比較活躍。系統中存在三種節點：Client、Tracker、Storage，在底層儲存上通過邏輯的分組概念，使得通過在同組內配置多個Storage，從而實現軟RAID10，提升簡單負載均衡、併發IO的效能、及資料的冗餘備份；同時通過線性的新增新的邏輯儲存組，從容實現儲存容量的線性擴容。

檔案下載上，除了支援通過API方式，目前還提供了apache和nginx的外掛支援，同時也可以不使用對應的外掛，直接以Web靜態資源方式對外提供下載。目前FastDFS(V4.x)程式碼量大概6w多行，內部的網路模型使用比較成熟的libevent三方庫，具備高併發的處理能力

優點

1）系統無需支援POSIX(可移植作業系統)，降低了系統的複雜度，處理效率更高
2）支援線上擴容機制，增強系統的可擴充套件性
3）實現了軟RAID，增強系統的併發處理能力及資料容錯恢復能力
4）支援主從檔案，支援自定義副檔名
5）主備Tracker服務，增強系統的可用性

缺點

1）不支援斷點續傳，對大檔案將是噩夢(FastDFS不適合大檔案儲存)
2）不支援POSIX通用介面訪問，通用性較低
3）對跨公網的檔案同步，存在較大延遲，需要應用做相應的容錯策略
4）同步機制不支援檔案正確性校驗，降低了系統的可用性
5）通過API下載，存在單點的效能瓶頸

NFS和AFS的區別

其實微軟的作業系統還有DFS分散式檔案管理系統嗎，不過使用的場景較少，此文不在講述，感興趣者可以自行百度。

NFS和AFS的區別在於對併發寫操作的處理方法上。當一個客戶機向伺服器請求一個檔案(或資料庫記錄)，檔案被放在客戶工作站的快取記憶體中，若另一個使用者也請求同一檔案，則它也會被放入那個客戶工作站的快取記憶體中。當兩個客戶都對檔案進行修改時，從技術上而言就存在著該檔案的三個版本(每個客戶機一個，再加上伺服器上的一個)。有兩種方法可以在這些版本之間保持同步：

無狀態系統 在這個系統中，伺服器並不儲存其客戶機正在快取的檔案的資訊。因此，客戶機必須協同伺服器定期檢查是否有其他客戶改變了自己正在快取的檔案。這種方法在大的環境中會產生額外的LAN通訊開銷，但對小型LAN來說，這是一種令人滿意的方法。NFS就是個無狀態系統。

回呼(Callback)系統 在這種方法中，伺服器記錄它的那些客戶機的所作所為，並保留它們正在快取的檔案資訊。伺服器在一個客戶機改變了一個檔案時使用一種叫回叫應答(callbackpromise)的技術通知其它客戶機。這種方法減少了大量網路通訊。AFS(及OSFDCE的DFS)就是回叫系統。客戶機改變檔案時，持有這些檔案拷貝的其它客戶機就被回叫並通知這些改變。

無狀態操作在執行效能上有其長處，但AFS通過保證不會被回叫應答充斥也達到了這一點。方法是在一定時間後取消回叫。客戶機檢查回叫應答中的時間期限以保證回叫應答是當前有效的。回叫應答的另一個有趣的特徵是向使用者保證了檔案的當前有效性。換句話說，若一個被快取的檔案有一個回叫應答，則客戶機就認為檔案是當前有效的，除非伺服器呼叫指出伺服器上的該檔案已改變了。

各種分散式檔案系統的比較

常見的分散式檔案系統有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自適用於不同的領域。它們都不是系統級的分散式檔案系統，而是應用級的分散式檔案存 儲服務。

適合做通用檔案系統的有 MooseFS，GlusterFS，Lustre。

適合儲存小檔案、圖片的分佈檔案系統有FastDFS、NFS和TFS。（傳統的方式是Rsync+inotify或者其他同步軟體）

MooseFS

支援FUSE，相對比較輕量級，對master伺服器有單點依賴，用perl編寫，效能相對較差，國內用的人比較多，易用，穩定，對小檔案很高效。

    + 支援檔案元資訊
    + mfsmount 很好用
    + 編譯依賴少，文件全，預設配置很好
    + mfshdd.cfg 加 * 的條目會被轉移到其它 chunk server，以便此 chunk server 安全退出
    + 不要求 chunk server 使用的檔案系統格式以及容量一致
    + 開發很活躍
    + 可以以非 root 使用者身份執行
    + 可以線上擴容
    + 支援回收站
    + 支援快照
    - master server 存在單點故障
    - master server 很耗記憶體

MogileFS

Key-Value型元檔案系統，不支援FUSE，應用程式訪問它時需要API，主要用在web領域處理海量小圖片，效率相比mooseFS高很多，據說對於 Web 2.0 應用儲存圖片啥的很好。

不適合做通用檔案系統，適合儲存靜態只讀小檔案，比如圖片

GlusterFS

支援FUSE，比mooseFS龐大，感覺廣告宣傳做的比產品本身好。

    + 無單點故障問題
    + 支援回收站
    + 模組化堆疊式架構
    - 對檔案系統格式有要求，ext3/ext4/zfs 被正式支援，xfs/jfs 可能可以，reiserfs 經測試可以

    - 需要以 root 使用者身份執行（用了 trusted xattr，mount 時加 user_xattr 選項是沒用的，官方說法是glusterfsd 需要建立不同屬主的檔案，所以必需 root 許可權)
    - 不能線上擴容(不 umount 時增加儲存節點)，計劃在 3.1 裡實現
    - 分佈儲存以檔案為單位，條帶化分佈儲存不成熟

GFS2

http://sourceware.org/cluster/wiki/DRBD_Cookbook
http://www.smop.co.uk/blog/index.php/2008/02/11/gfs-goodgrief-wheres-the-documentation-file-system/
http://wiki.debian.org/kristian_jerpetjoen
http://longvnit.com/blog/?p=941
http://blog.chinaunix.net/u1/53728/showart_1073271.html (基於紅帽RHEL5U2 GFS2+ISCSI+XEN+Cluster 的高可性解決方案)
http://www.yubo.org/blog/?p=27 (iscsi+clvm+gfs2+xen+Cluster)
http://linux.chinaunix.net/bbs/thread-777867-1-1.html

並不是 distributed file system, 而是 shared disk cluster file system，需要某種機制在機器 
之間共享磁碟，以及加鎖機制，因此需要 drbd/iscsi/clvm/ddraid/gnbd 做磁碟共享，以及 dlm 做鎖管理) 
- 依賴 Red Hat Cluster Suite (Debian: aptitude install redhat-cluster-suite， 圖形配置工具包 
system-config-cluster, system-config-lvm) 
- 適合不超過約 30 個節點左右的小型叢集，規模越大，dlm 的開銷越大，預設配置 8 個節點

OCFS2

GFS 的 Oracle 翻版，據說效能比 GFS2 好 (Debian: aptitude install ocfs2-tools, 圖形配置工具包 ocfs2console) 
不支援 ACL、flock，只是為了 Oracle database 設計

OpenAFS/Coda

是很有特色的東西。

     + 成熟穩定
    + 開發活躍，支援 Unix/Linux/MacOS X/Windows
    - 效能不夠好

Ceph

支援FUSE，客戶端已經進入了linux-2.6.34核心，也就是說可以像ext3/rasierFS一樣，選擇ceph為檔案系統。徹底的分散式，沒有單點依賴，用C編寫，效能較好。基於不成熟的btrfs，其本身也非常不成熟 。

是加州大學聖克魯茲分校的Sage weil攻讀博士時開發的分散式檔案系統。並使用Ceph完成了他的論文。
說 ceph 效能最高，C++編寫的程式碼，支援Fuse，並且沒有單點故障依賴， 於是下載安裝， 由於 ceph 使用 btrfs 檔案系統， 而btrfs 檔案系統需要 Linux 2.6.34 以上的核心才支援。
可是ceph太不成熟了，它基於的btrfs本身就不成熟，它的官方網站上也明確指出不要把ceph用在生產環境中。【可是現在聚集了大量國內社群的熱衷，並且得到很多雲端計算公司的青睞，此項技術已經越來越受用和成熟。時代變啦】
　　

Lustre

Oracle公司的企業級產品，非常龐大，對核心和ext3深度依賴 
複雜，高效，適合大型叢集。

    * 適合大型叢集
    + 很高效能
    + 支援動態擴充套件
    - 需要對核心打補丁，深度依賴 Linux 核心和 ext3 檔案系統

PVFS2

搭配定製應用會很好，據說曙光的並行檔案系統就是基於 PVFS。　　fastDFS：國人在mogileFS的基礎上進行改進的key-value型檔案系統，同樣不支援FUSE，提供比mogileFS更好的效能。

    * 高效能
    - 沒有鎖機制，不符合 POSIX 語意，需要應用的配合，不適合做通用檔案系統
      (See pvfs2-guide chaper 5:  PVFS2 User APIs and Semantics)
    - 靜態配置，不能動態擴充套件

Coda

    * 從伺服器複製檔案到本地，檔案讀寫是本地操作因此很高效
    * 檔案關閉後傳送到伺服器
    + 支援離線操作，連線後再同步到伺服器上
    - 快取基於檔案，不是基於資料塊，開啟檔案時需要等待從伺服器快取到本地完畢
    - 併發寫有版本衝突問題
    - 併發讀有極大的延遲，需要等某個 client 關閉檔案，比如不適合 tail -f some.log
    - 研究專案，不夠成熟，使用不廣

Hadoop HDFS

本地寫快取，夠一定大小 (64 MB) 時傳給伺服器 
不適合通用檔案系統

Hadoop 實現了一個分散式檔案系統（Hadoop Distributed File System），簡稱HDFS。 Hadoop是Apache Lucene創始人Doug Cutting開發的使用廣泛的文字搜尋庫。它起源於Apache Nutch，後者是一個開源的網路搜尋引擎，本身也是Luene專案的一部分。Aapche Hadoop架構是MapReduce演算法的一種開源應用，是Google開創其帝國的重要基石。

FastDFS

是一款類似Google FS的開源分散式檔案系統，是純C語言開發的。
FastDFS是一個開源的輕量級分散式檔案系統，它對檔案進行管理，功能包括：檔案儲存、檔案同步、檔案訪問（檔案上傳、檔案下載）等，解決了大容量儲存和負載均衡的問題。特別適合以檔案為載體的線上服務，如相簿網站、視訊網站等等。

- 只能通過 API 使用，不支援 fuse

NFS

　　老牌網路檔案系統，具體不瞭解，反正NFS最近幾年沒發展，肯定不能用。 
　　

dCache

依賴 PostgreSQL

xtreemfs

* 服務端是 Java 實現的
- 效能不高

CloudStore (KosmosFS)

+ 被 Hadoop 作為分散式檔案系統後端之一
- 不支援檔案元資訊
- kfs_fuse 太慢，不可用
- 編譯依賴多，文件落後，指令碼簡陋
- 開發不活躍

NFSv4 Referrals

+ 簡單
- 沒有負載均衡，容錯

NFSv4.1 pNFS

- 沒有普及
  •  

spNFS

* pNFS 在 Linux 上的一個實現

Ceph (http://ceph.newdream.net/) 
- 開發初期，不穩定 
- 依賴 btrfs

GFarm

http://datafarm.apgrid.org/software/

MogileFS

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
由memcahed的開發公司danga一款perl開發的產品，目前國內使用mogielFS的有圖片託管網站yupoo等。
MogileFS是一套高效的檔案自動備份元件，由Six Apart開發，廣泛應用在包括LiveJournal等web2.0站點上。
MogileFS由3個部分組成：
　　第1個部分是server端，包括mogilefsd和mogstored兩個程式。前者即是 mogilefsd的tracker，它將一些全域性資訊儲存在資料庫裡，例如站點domain,class,host等。後者即是儲存節點(store node)，它其實是個HTTP Daemon，預設偵聽在7500埠，接受客戶端的檔案備份請求。在安裝完後，要執行mogadm工具將所有的store node註冊到mogilefsd的資料庫裡，mogilefsd會對這些節點進行管理和監控。
　　第2個部分是utils（工具集），主要是MogileFS的一些管理工具，例如mogadm等。
　　第3個部分是客戶端API，目前只有Perl API(MogileFS.pm)、PHP，用這個模組可以編寫客戶端程式，實現檔案的備份管理功能。

TFS

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
TFS（Taobao !FileSystem）是一個高可擴充套件、高可用、高效能、面向網際網路服務的分散式檔案系統，主要針對海量的非結構化資料，它構築在普通的Linux機器 叢集上，可為外部提供高可靠和高併發的儲存訪問。TFS為淘寶提供海量小檔案儲存，通常檔案大小不超過1M，滿足了淘寶對小檔案儲存的需求，被廣泛地應用 在淘寶各項應用中。它採用了HA架構和平滑擴容，保證了整個檔案系統的可用性和擴充套件性。同時扁平化的資料組織結構，可將檔名對映到檔案的實體地址，簡化 了檔案的訪問流程，一定程度上為TFS提供了良好的讀寫效能。
官網 ： http://code.taobao.org/p/tfs/wiki/index/

但是，現在開源雖好，但面對日益增長的使用者需求和複雜的架構變更，以上分散式檔案儲存系統已經不能滿足企業實際發展需要例如斷電或者網路抖動都會對儲存產生影響，很多公司都基於二次開發或者獨立研發自己的分散式檔案儲存系統，例如七牛和青雲等雲廠商公司。對於技術缺乏的公司建議使用商業的分散式儲存，這樣可以減少很多麻煩。

【參考資料】

1、百度百科、互動百度、搜狗百科、wiki百科、必應百科、知識百科

2、分散式檔案系統概述 - https://blog.csdn.net/c602273091/article/details/78643889

相關文章