主流分布式文件系統對比

　　分布式文件系統是分布式領域的一個基礎應用，其中最著名的毫無疑問是HDFS/GFS。如今該領域已經趨向于成熟，但了解它的設計要點和思想，對我們將來面臨類似場景/問題時，具有借鑒意義。并且，分布式文件系統并非只有HDFS/GFS這一種形態，在它之外，還有其他形態各異、各有千秋的產品形態，對它們的了解，也對擴展我們的視野有所俾益。本文試圖分析和思考，在分布式文件系統領域，我們要解決哪些問題、有些什么樣的方案、以及各自的選擇依據。

　　在幾十年以前，分布式文件系統就已經出現了，以Sun在1984年開發的“Network File System (NFS)”為代表，那時候解決的主要問題，是網絡形態的磁盤，把磁盤從主機中獨立出來。這樣不僅可以獲得更大的容量，而且還可以隨時切換主機，還可以實現數據共享、備份、容災等，因為數據是電腦中最重要的資產。NFS的數據通信圖如下

　　部署在主機上的客戶端，通過TCP/IP協議把文件命令轉發到遠程文件Server上執行，整個過程對主機用戶透明。

　　到了互聯網時代，流量和數據快速增長，分布式文件系統所要解決的主要場景變了，開始需要非常大的磁盤空間，這在磁盤體系上垂直擴容是無法達到的，必須要分布式，同時分布式架構下，主機都是可靠性不是非常好的普通服務器，因此容錯、高可用、持久化、伸縮性等指標，就成為必須要考量的特性。

　　對一個分布式文件系統而言，有一些特性是必須要滿足的，否則就無法有競爭力。主要如下：

　　應該符合POSIX的文件接口標準，使該系統易于使用，同時對于用戶的遺留系統也無需改造；

　　對用戶透明，能夠像使用本地文件系統那樣直接使用；

　　持久化，保證數據不會丟失；

　　具有伸縮性，當數據壓力逐漸增長時能順利擴容；

　　具有可靠的安全機制，保證數據安全；

　　數據一致性，只要文件內容不發生變化，什么時候去讀，得到的內容應該都是一樣的；

　　還有些特性，是加分項：

　　支持的空間越大越好；

　　支持的并發訪問請求越多越好；

　　性能越快越好；

　　硬件資源的利用率越高越合理，就越好；

　　從業務模型和邏輯架構上，分布式文件系統需要這幾類組件：

　　存儲組件：負責存儲文件數據，它要保證文件的持久化、副本間數據一致、數據塊的分配/合并等等；

　　管理組件：負責meta信息，即文件數據的元信息，包括文件存放在哪臺服務器上、文件大小、權限等，除此之外，還要負責對存儲組件的管理，包括存儲組件所在的服務器是否正常存活、是否需要數據遷移等；

　　接口組件：提供接口服務給應用使用，形態包括SDK(Java/C/C++等)、CLI命令行終端、以及支持FUSE掛載機制；

　　而在部署架構上，有著“中心化”和“無中心化”兩種路線分歧，即是否把“管理組件”作為分布式文件系統的中心管理節點。兩種路線都有很優秀的產品，下面分別介紹它們的區別。

　　有中心節點

　　以GFS為代表，中心節點負責文件定位、維護文件meta信息、故障檢測、數據遷移等管理控制的職能，下圖是GFS的架構圖

　　GFS架構

　　該圖中GFS master即為GFS的中心節點，GF chunkserver為GFS的存儲節點。其操作路徑如下：

　　Client向中心節點請求“查詢某個文件的某部分數據”

　　中心節點返回文件所在的位置(哪臺chunkserver上的哪個文件)以及字節區間信息

　　Client根據中心節點返回的信息，向對應的chunk server直接發送數據讀取的請求

　　chunk server返回數據

　　在這種方案里，一般中心節點并不參與真正的數據讀寫，而是將文件meta信息返回給Client之后，即由Client與數據節點直接通信。其主要目的是降低中心節點的負載，防止其成為瓶頸。這種有中心節點的方案，在各種存儲類系統中得到了廣泛應用，因為中心節點易控制、功能強大。

　　無中心節點

　　以ceph為代表，每個節點都是自治的、自管理的，整個ceph集群只包含一類節點，如下圖(最下層紅色的RADOS就是ceph定義的“同時包含meta數據和文件數據”的節點)

　　ceph架構

　　A [Ceph Node] leverages commodity hardware and intelligent daemons, and a [Ceph Storage Cluster] accommodates large numbers of nodes, which communicate with each other to replicate and redistribute data dynamically. Ceph provides an infinitely scalable [Ceph Storage Cluster] based upon RADOS

　　無中心化的最大優點是解決了中心節點自身的瓶頸，這也就是ceph號稱可以無限向上擴容的原因。但由Client直接和Server通信，那么Client必須要知道，當對某個文件進行操作時，它該訪問集群中的哪個節點。ceph提供了一個很強大的原創算法來解決這個問題——CRUSH算法。

　　對于文件系統來說，持久化是根本，只要Client收到了Server保存成功的回應之后，數據就不應該丟失。這主要是通過多副本的方式來解決，但在分布式環境下，多副本有這幾個問題要面對：

　　如何保證每個副本的數據是一致的?

　　如何分散副本，以使災難發生時，不至于所有副本都被損壞?

　　怎么檢測被損壞或數據過期的副本，以及如何處理?

　　該返回哪個副本給Client?

　　如何保證每個副本的數據是一致的

　　同步寫入是保證副本數據一致的最直接的辦法。當Client寫入一個文件的時候，Server會等待所有副本都被成功寫入，再返回給Client。

　　這種方式簡單、有保障，唯一的缺陷就是性能會受到影響。假設有3個副本，如果每個副本需要N秒，則可能會阻塞Client 3N秒的時間，有幾種方式，可以對其進行優化：

　　并行寫：由一個副本作為主副本，并行發送數據給其他副本；

　　鏈式寫：幾個副本組成一個鏈(chain)，并不是等內容都接受到了再往后傳播，而是像流一樣，邊接收上游傳遞過來的數據，一邊傳遞給下游；

　　還有一種方式是采用CAP中所說的W+R>N的方式，比如3副本(N=3)的情況，W＝2，R＝2，即成功寫入2個就認為成功，讀的時候也要從2個副本中讀。這種方式通過犧牲一定的讀成本，來降低寫成本，同時增加寫入的可用性。這種方式在分布式文件系統中用地比較少。

　　如何分散副本，以使災難發生時，不至于所有副本都被損壞

　　這主要避免的是某機房或某城市發生自然環境故障的情況，所以有一個副本應該分配地比較遠。它的副作用是會帶來這個副本的寫入性能可能會有一定的下降，因為它離Client最遠。所以如果在物理條件上無法保證夠用的網絡帶寬的話，則讀寫副本的策略上需要做一定考慮?？梢詤⒖纪綄懭胫粚?副本、較遠副本異步寫入的方式，同時為了保證一致性，讀取的時候又要注意一些，避免讀取到異步寫入副本的過時數據。

　　怎么檢測被損壞或數據過期的副本，以及如何處理

　　如果有中心節點，則數據節點定期和中心節點進行通信，匯報自己的數據塊的相關信息，中心節點將其與自己維護的信息進行對比。如果某個數據塊的checksum不對，則表明該數據塊被損壞了；如果某個數據塊的version不對，則表明該數據塊過期了。

　　如果沒有中心節點，以ceph為例，它在自己的節點集群中維護了一個比較小的monitor集群，數據節點向這個monitor集群匯報自己的情況，由其來判定是否被損壞或過期。

　　當發現被損壞或過期副本，將它從meta信息中移除，再重新創建一份新的副本就好了，移除的副本在隨后的回收機制中會被收回。

　　該返回哪個副本給Client

　　這里的策略就比較多了，比如round-robin、速度最快的節點、成功率最高的節點、CPU資源最空閑的節點、甚至就固定選第一個作為主節點，也可以選擇離自己最近的一個，這樣對整體的操作完成時間會有一定節約。

　　存儲節點的伸縮

　　當在集群中加入一臺新的存儲節點，則它主動向中心節點注冊，提供自己的信息，當后續有創建文件或者給已有文件增加數據塊的時候，中心節點就可以分配到這臺新節點了，比較簡單。但有一些問題需要考慮：

　　如何盡量使各存儲節點的負載相對均衡?

　　怎樣保證新加入的節點，不會因短期負載壓力過大而崩塌?

　　如果需要數據遷移，那如何使其對業務層透明?

　　如何盡量使各存儲節點的負載相對均衡

　　首先要有評價存儲節點負載的指標。有多種方式，可以從磁盤空間使用率考慮，也可以從磁盤使用率+CPU使用情況+網絡流量情況等做綜合判斷。一般來說，磁盤使用率是核心指標。

　　其次在分配新空間的時候，優先選擇資源使用率小的存儲節點；而對已存在的存儲節點，如果負載已經過載、或者資源使用情況不均衡，則需要做數據遷移。

　　怎樣保證新加入的節點，不會因短期負載壓力過大而崩塌

　　當系統發現當前新加入了一臺存儲節點，顯然它的資源使用率是最低的，那么所有的寫流量都路由到這臺存儲節點來，那就可能造成這臺新節點短期負載過大。因此，在資源分配的時候，需要有預熱時間，在一個時間段內，緩慢地將寫壓力路由過來，直到達成新的均衡。

　　如果需要數據遷移，那如何使其對業務層透明?

　　在有中心節點的情況下，這個工作比較好做，中心節點就包辦了——判斷哪臺存儲節點壓力較大，判斷把哪些文件遷移到何處，更新自己的meta信息，遷移過程中的寫入怎么辦，發生重命名怎么辦。無需上層應用來處理。

　　如果沒有中心節點，那代價比較大，在系統的整體設計上，也是要考慮到這種情況，比如ceph，它要采取邏輯位置和物理位置兩層結構，對Client暴露的是邏輯層(pool和place group)，這個在遷移過程中是不變的，而下層物理層數據塊的移動，只是邏輯層所引用的物理塊的地址發生了變化，在Client看來，邏輯塊的位置并不會發生改變。

　　中心節點的伸縮

　　如果有中心節點，還要考慮它的伸縮性。由于中心節點作為控制中心，是主從模式，那么在伸縮性上就受到比較大的限制，是有上限的，不能超過單臺物理機的規模。我們可以考慮各種手段，盡量地抬高這個上限。有幾種方式可以考慮：

　　以大數據塊的形式來存儲文件——比如HDFS的數據塊的大小是64M，ceph的的數據塊的大小是4M，都遠遠超過單機文件系統的4k。它的意義在于大幅減少meta data的數量，使中心節點的單機內存就能夠支持足夠多的磁盤空間meta信息；

　　中心節點采取多級的方式——頂級中心節點只存儲目錄的meta data，其指定某目錄的文件去哪臺次級總控節點去找，然后再通過該次級總控節點找到文件真正的存儲節點。

　　中心節點共享存儲設備——部署多臺中心節點，但它們共享同一個存儲外設/數據庫，meta信息都放在這里，中心節點自身是無狀態的。這種模式下，中心節點的請求處理能力大為增強，但性能會受一定影響。iRODS就是采用這種方式。

　　中心節點的高可用

　　中心節點的高可用，不僅要保證自身應用的高可用，還得保證meta data的數據高可用。

　　meta data的高可用主要是數據持久化，并且需要備份機制保證不丟。一般方法是增加一個從節點，主節點的數據實時同步到從節點上。也有采用共享磁盤，通過raid1的硬件資源來保障高可用。顯然增加從節點的主備方式更易于部署。

　　meta data的數據持久化策略有幾種方式:

　　直接保存到存儲引擎上，一般是數據庫。直接以文件形式保存到磁盤上，也不是不可以，但因為meta信息是結構化數據，這樣相當于自己研發出一套小型數據庫來，復雜化了。

　　保存日志數據到磁盤文件(類似MySQL的binlog或Redis的aof)，系統啟動時在內存中重建成結果數據，提供服務。修改時先修改磁盤日志文件，然后更新內存數據。這種方式簡單易用。

　　當前內存服務+日志文件持久化是主流方式。一是純內存操作，效率很高，日志文件的寫也是順序寫；二是不依賴外部組件，獨立部署。

　　為了解決日志文件會隨著時間增長越來越大的問題，以讓系統能以盡快啟動和恢復，需要輔助以內存快照的方式——定期將內存dump保存，只保留在dump時刻之后的日志文件。這樣當恢復時，從最新一次的內存dump文件開始，找其對應的checkpoint之后的日志文件開始重播。

　　存儲節點的高可用

　　在前面“持久化”章節，在保證數據副本不丟失的情況下，也就保證了其的高可用性。

　　這些年隨著基礎設施的發展，局域網內千兆甚至萬兆的帶寬已經比較普遍，以萬兆計算，每秒傳輸大約1250M字節的數據，而SATA磁盤的讀寫速度這些年基本達到瓶頸，在300-500M/s附近，也就是純讀寫的話，網絡已經超過了磁盤的能力，不再是瓶頸了，像NAS網絡磁盤這些年也開始普及起來。

　　但這并不代表，沒有必要對讀寫進行優化，畢竟網絡讀寫的速度還是遠慢于內存的讀寫。常見的優化方法主要有

　　內存中緩存文件內容

　　預加載數據塊，以避免客戶端等待

　　合并讀寫請求，也就是將單次請求做些積累，以批量方式發送給Server端

　　緩存的使用在提高讀寫性能的同時，也會帶來數據不一致的問題：

　　會出現更新丟失的現象。當多個Client在一個時間段內，先后寫入同一個文件時，先寫入的Client可能會丟失其寫入內容，因為可能會被后寫入的Client的內容覆蓋掉；

　　數據可見性問題。Client讀取的是自己的緩存，在其過期之前，如果別的Client更新了文件內容，它是看不到的；也就是說，在同一時間，不同Client讀取同一個文件，內容可能不一致；

　　這類問題有幾種方法：

　　文件只讀不改：一旦文件被create了，就只能讀不能修改。這樣Client端的緩存，就不存在不一致的問題。

　　通過鎖：用鎖的話還要考慮不同的粒度。寫的時候是否允許其他Client讀? 讀的時候是否允許其他Client寫? 這是在性能和一致性之間的權衡，作為文件系統來說，由于對業務并沒有約束性，所以要做出合理的權衡，比較困難，因此最好是提供不同粒度的鎖，由業務端來選擇。但這樣的副作用是，業務端的使用成本抬高了。

　　由于分布式文件存儲系統，肯定是一個多客戶端使用、多租戶的一個產品，而它又存儲了可能是很重要的信息，所以安全性是它的重要部分。

　　主流文件系統的權限模型有這么幾種：

　　DAC: 全稱是Discretionary Access Control，就是我們熟悉的Unix類權限框架，以user-group-privilege為三級體系，其中user就是owner，group包括owner所在group和非owner所在的group、privilege有read、write和execute。這套體系主要是以owner為出發點，owner允許誰對哪些文件具有什么樣的權限。

　　MAC: 全稱是Mandatory Access Control，它是從資源的機密程度來劃分。比如分為“普通”、“機密”、“絕密”這三層，每個用戶可能對應不同的機密閱讀權限。這種權限體系起源于安全機構或軍隊的系統中，會比較常見。它的權限是由管理員來控制和設定的。Linux中的SELinux就是MAC的一種實現，為了彌補DAC的缺陷和安全風險而提供出來。關于SELinux所解決的問題可以參考What is SELinux?

　　RBAC: 全稱是Role Based Access Control，是基于角色(role)建立的權限體系。角色擁有什么樣的資源權限，用戶歸到哪個角色，這對應企業/公司的組織機構非常合適。RBAC也可以具體化，就演變成DAC或MAC的權限模型。

　　市面上的分布式文件系統有不同的選擇，像ceph就提供了類似DAC但又略有區別的權限體系，Hadoop自身就是依賴于操作系統的權限框架，同時其生態圈內有Apache Sentry提供了基于RBAC的權限體系來做補充。

　　空間分配

　　有連續空間和鏈表空間兩種。連續空間的優勢是讀寫快，按順序即可，劣勢是造成磁盤碎片，更麻煩的是，隨著連續的大塊磁盤空間被分配滿而必須尋找空洞時，連續分配需要提前知道待寫入文件的大小，以便找到合適大小的空間，而待寫入文件的大小，往往又是無法提前知道的(比如可編輯的word文檔，它的內容可以隨時增大)；

　　而鏈表空間的優勢是磁盤碎片很少，劣勢是讀寫很慢，尤其是隨機讀，要從鏈表首個文件塊一個一個地往下找。為了解決這個問題，出現了索引表——把文件和數據塊的對應關系也保存一份，存在索引節點中(一般稱為i節點)，操作系統會將i節點加載到內存，從而程序隨機尋找數據塊時，在內存中就可以完成了。通過這種方式來解決磁盤鏈表的劣勢，如果索引節點的內容太大，導致內存無法加載，還有可能形成多級索引結構。

　　文件刪除

　　實時刪除還是延時刪除? 實時刪除的優勢是可以快速釋放磁盤空間；延時刪除只是在刪除動作執行的時候，置個標識位，后續在某個時間點再來批量刪除，它的優勢是文件仍然可以階段性地保留，最大程度地避免了誤刪除，缺點是磁盤空間仍然被占著。在分布式文件系統中，磁盤空間都是比較充裕的資源，因此幾乎都采用邏輯刪除，以對數據可以進行恢復，同時在一段時間之后(可能是2天或3天，這參數一般都可配置)，再對被刪除的資源進行回收。

　　怎么回收被刪除或無用的數據? 可以從文件的meta信息出發——如果meta信息的“文件-數據塊”映射表中包含了某個數據塊，則它就是有用的；如果不包含，則表明該數據塊已經是無效的了。所以，刪除文件，其實是刪除meta中的“文件-數據塊”映射信息(如果要保留一段時間，則是把這映射信息移到另外一個地方去)。

　　面向小文件的分布式文件系統

　　有很多這樣的場景，比如電商——那么多的商品圖片、個人頭像，比如社交網站——那么多的照片，它們具有的特性，可以簡單歸納下：

　　每個文件都不大

　　數量特別巨大

　　讀多寫少

　　不會修改針對這種業務場景，主流的實現方式是仍然是以大數據塊的形式存儲，小文件以邏輯存儲的方式存在，即文件meta信息記錄其是在哪個大數據塊上，以及在該數據塊上的offset和length是多少，形成一個邏輯上的獨立文件。這樣既復用了大數據塊系統的優勢和技術積累，又減少了meta信息。

　　文件指紋和去重

　　文件指紋就是根據文件內容，經過算法，計算出文件的唯一標識。如果兩個文件的指紋相同，則文件內容相同。在使用網絡云盤的時候，發現有時候上傳文件非常地快，就是文件指紋發揮作用。云盤服務商通過判斷該文件的指紋，發現之前已經有人上傳過了，則不需要真的上傳該文件，只要增加一個引用即可。在文件系統中，通過文件指紋可以用來去重、也可以用來判斷文件內容是否損壞、或者對比文件副本內容是否一致，是一個基礎組件。

　　文件指紋的算法也比較多，有熟悉的md5、sha256、也有google專門針對文本領域的simhash和minhash等。

　　分布式文件系統內容龐雜，要考慮的問題遠不止上面所說的這些，其具體實現也更為復雜。本文只是盡量從分布式文件系統所要考慮的問題出發，給予一個簡要的分析和設計，如果將來遇到類似的場景需要解決，可以想到“有這種解決方案”，然后再來深入研究。

　　同時，市面上也是存在多種分布式文件系統的形態，下面就是有研究小組曾經對常見的幾種分布式文件系統的設計比較

　　幾種分布式文件系統的比較

　　從這里也可以看到，選擇其實很多，并不是GFS論文中的方式就是最好的。在不同的業務場景中，也可以有更多的選擇策略。