換個視角深入理解GlusterFS，GlusterFS缺點分析

轉自 http://blog.sina.com.cn/s/blog_6b89db7a0101gbcy.html

換個角度深入理解GlusterFS

GlusterFS（GNU ClusterFile
System）是一個開源的分散式檔案系統，它的歷史可以追溯到2006年，最初的目標是代替Lustre和GPFS分散式檔案系統。經過八年左右的蓬勃
發展，GlusterFS目前在開源社群活躍度非常之高，這個後起之秀已經儼然與Lustre、MooseFS、CEPH並列成為四大開源分散式檔案系
統。由於GlusterFS新穎和KISS（KeepIt
as Stupid and
Simple）的系統架構，使其在擴充套件性、可靠性、效能、維護性等方面具有獨特的優勢，目前開源社群風頭有壓倒之勢，國內外有大量使用者在研究、測試和部署
應用。

當然，GlusterFS不是一個完美的分散式檔案系統，這個系統自身也有許多不足之處，包括眾所周知的後設資料效能和小檔案問題。沒有普遍適用各種應用場
景的分散式檔案系統，通用的意思就是通通不能用，四大開源系統不例外，所有商業產品也不例外。每個分散式檔案系統都有它適用的應用場景，適合的才是最好
的。這一次我們反其道而行之，不再談GlusterFS的各種優點，而是深入談談GlusterFS當下的問題和不足，從而更加深入地理解
GlusterFS系統，期望幫助大家進行正確的系統選型決策和規避應用中的問題。同時，這些問題也是GlusterFS研究和研發的很好切入點。

1、後設資料效能

GlusterFS使用彈性雜湊演算法代替傳統分散式檔案系統中的集中或分散式後設資料服務，這個是GlusterFS最核心的思想，從而獲得了接近線性的高
擴充套件性，同時也提高了系統效能和可靠性。GlusterFS使用演算法進行資料定位，叢集中的任何伺服器和客戶端只需根據路徑和檔名就可以對資料進行定位
和讀寫訪問，檔案定位可獨立並行化進行。

這種演算法的特點是，給定確定的檔名，查詢和定位會非常快。但是，如果事先不知道檔名，要列出檔案目錄（ls或ls
-l），效能就會大幅下降。對於Distributed雜湊卷，檔案通過HASH演算法分散到叢集節點上，每個節點上的名稱空間均不重疊，所有叢集共同構成
完整的名稱空間，訪問時使用HASH演算法進行查詢定位。列檔案目錄時，需要查詢所有節點，並對檔案目錄資訊及屬性進行聚合。這時，雜湊演算法根本發揮不上作
用，相對於有中心的後設資料服務，查詢效率要差很多。

從我接觸的一些使用者和實踐來看，當叢集規模變大以及檔案數量達到百萬級別時，ls檔案目錄和rm刪除檔案目錄這兩個典型後設資料操作就會變得非常慢，建立和
刪除100萬個空檔案可能會花上15分鐘。如何解決這個問題呢？我們建議合理組織檔案目錄，目錄層次不要太深，單個目錄下檔案數量不要過多；增大伺服器內
存配置，並且增大GlusterFS目錄快取引數；網路配置方面，建議採用萬兆或者InfiniBand。從研發角度看，可以考慮優化方法提升後設資料性
能。比如，可以構建全域性統一的分散式後設資料快取系統；也可以將後設資料與資料重新分離，每個節點上的後設資料採用全記憶體或資料庫設計，並採用SSD進行後設資料
持久化。

2、小檔案問題

理論和實踐上分析，GlusterFS目前主要適用大檔案儲存場景，對於小檔案尤其是海量小檔案，儲存效率和訪問效能都表現不佳。海量小檔案LOSF問題
是工業界和學術界公認的難題，GlusterFS作為通用的分散式檔案系統，並沒有對小檔案作額外的優化措施，效能不好也是可以理解的。

對於LOSF而言，IOPS/OPS是關鍵效能衡量指標，造成效能和儲存效率低下的主要原因包括後設資料管理、資料佈局和I/O管理、Cache管理、網路
開銷等方面。從理論分析以及LOSF優化實踐來看，優化應該從後設資料管理、快取機制、合併小檔案等方面展開，而且優化是一個系統工程，結合硬體、軟體，從
多個層面同時著手，優化效果會更顯著。GlusterFS小檔案優化可以考慮這些方法，這裡不再贅述，關於小檔案問題請參考“海量小檔案問題綜述”一文。

3、叢集管理模式

GlusterFS叢集採用全對等式架構，每個節點在叢集中的地位是完全對等的，叢集配置資訊和卷配置資訊在所有節點之間實時同步。這種架構的優點是，每
個節點都擁有整個叢集的配置資訊，具有高度的獨立自治性，資訊可以本地查詢。但同時帶來的問題的，一旦配置資訊發生變化，資訊需要實時同步到其他所有節
點，保證配置資訊一致性，否則GlusterFS就無法正常工作。在叢集規模較大時，不同節點併發修改配置時，這個問題表現尤為突出。因為這個配置資訊同步模型是網狀的，大規模叢集不僅資訊同步效率差，而且出現資料不一致的概率會增加。

實際上，大規模叢集管理應該是採用集中式管理更好，不僅管理簡單，效率也高。可能有人會認為集中式叢集管理與GlusterFS的無中心架構不協調，其實
不然。GlusterFS
2.0以前，主要通過靜態配置檔案來對叢集進行配置管理，沒有Glusterd叢集管理服務，這說明glusterd並不是GlusterFS不可或缺的
組成部分，它們之間是鬆耦合關係，可以用其他的方式來替換。從其他分散式系統管理實踐來看，也都是採用叢集式管理居多，這也算一個佐
證，GlusterFS
4.0開發計劃也表現有向集中式管理轉變的趨勢。

4、容量負載均衡

GlusterFS的雜湊分佈是以目錄為基本單位的，檔案的父目錄利用擴充套件屬性記錄了子卷對映資訊，子檔案在父目錄所屬儲存伺服器中進行分佈。由於檔案目
錄事先儲存了分佈資訊，因此新增節點不會影響現有檔案儲存分佈，它將從此後的新建立目錄開始參與儲存分佈排程。這種設計，新增節點不需要移動任何檔案，但
是負載均衡沒有平滑處理，老節點負載較重。GlusterFS實現了容量負載均衡功能，可以對已經存在的目錄檔案進行Rebalance，使得早先建立的老目錄可以在新增儲存節點上分佈，並可對現有檔案資料進行遷移實現容量負載均衡。

GlusterFS目前的容量負載均衡存在一些問題。由於採用Hash演算法進行資料分佈，容量負載均衡需要對所有資料重新進行計算並分配儲存節點，對於那
些不需要遷移的資料來說，這個計算是多餘的。Hash分佈具有隨機性和均勻性的特點，資料重新分佈之後，老節點會有大量資料遷入和遷出，這個多出了很多數
據遷移量。相對於有中心的架構，可謂節點一變而動全身，增加和刪除節點增加了大量資料遷移工作。GlusterFS應該優化資料分佈，最小化容量負載均衡
資料遷移。此外，GlusterFS容量負載均衡也沒有很好考慮執行的自動化、智慧化和並行化。目前，GlusterFS在增加和刪除節點上，需要手工執
行負載均衡，也沒有考慮當前系統的負載情況，可能影響正常的業務訪問。GlusterFS的容量負載均衡是通過在當前執行節點上掛載卷，然後進行檔案復
制、刪除和改名操作實現的，沒有在所有叢集節點上併發進行，負載均衡效能差。

5、資料分佈問題

Glusterfs主要有三種基本的叢集模式，即分散式叢集(Distributed cluster)、條帶叢集(Stripe
cluster)、複製叢集(Replica
cluster)。這三種基本叢集還可以採用類似堆積木的方式，構成更加複雜的複合叢集。三種基本叢集各由一個translator來實現，分別由自己獨
立的名稱空間。對於分散式叢集，檔案通過HASH演算法分散到叢集節點上，訪問時使用HASH演算法進行查詢定位。複製叢集類似RAID1，所有節點資料完全
相同，訪問時可以選擇任意個節點。條帶叢集與RAID0相似，檔案被分成資料塊以Round
Robin方式分佈到所有節點上，訪問時根據位置資訊確定節點。

雜湊分佈可以保證資料分散式的均衡性，但前提是檔案數量要足夠多，當檔案數量較少時，難以保證分佈的均衡性，導致節點之間負載不均衡。這個對有中心的分佈
式系統是很容易做到的，但GlusteFS缺乏集中式的排程，實現起來比較複雜。複製捲包含多個副本，對於讀請求可以實現負載均衡，但實際上負載大多集中
在第一個副本上，其他副本負載很輕，這個是實現上問題，與理論不太相符。條帶卷原本是實現更高效能和超大檔案，但在效能方面的表現太差強人意，遠遠不如哈
希卷和複製卷，沒有被好好實現，連官方都不推薦應用。

6、資料可用性問題

副本（Replication）就是對原始資料的完全拷貝。通過為系統中的檔案增加各種不同形式的副本，儲存冗餘的檔案資料，可以十分有效地提高檔案的可用性，避免在地理上廣泛分佈的系統節點由網路斷開或機器故障等動態不可測因素而引起的資料丟失或不可獲取。GlusterFS主要使用複製來提供資料的高可用性，通過的叢集模式有複製卷和雜湊複製卷兩種模式。複製卷是檔案級RAID1，具有容錯能力，資料同步寫到多個brick上，每個副本都可以響應讀請求。當有副本節點發生故障，其他副本節點仍然正常提供讀寫服務，故障節點恢復後通過自修復服務或同步訪問時自動進行資料同步。

一般而言，副本數量越多，檔案的可靠性就越高，但是如果為所有檔案都儲存較多的副本數量，儲存利用率低（為副本數量分之一），並增加檔案管理的複雜度。目
前GlusterFS社群正在研發糾刪碼功能，通過冗餘編碼提高儲存可用性，並且具備較低的空間複雜度和資料冗餘度，儲存利用率高。

GlusterFS的複製卷以brick為單位進行映象，這個模式不太靈活，檔案的複製關係不能動態調整，在已經有副本發生故障的情況下會一定程度上降低系統的可用性。對於有後設資料服務的分散式系統，複製關係可以是以檔案為單位的，檔案的不同副本動態分佈在多個儲存節點上；當有副本發生故障，可以重新選
擇一個儲存節點生成一個新副本，從而保證副本數量，保證可用性。另外，還可以實現不同檔案目錄配置不同的副本數量，熱點檔案的動態遷移。對於無中心的
GlusterFS系統來說，這些看起來理所當然的功能，實現起來都是要大費周折的。不過值得一提的是，4.0開發計劃已經在考慮這方面的副本特性。

7、資料安全問題

GlusterFS以原始資料格式（如EXT4、XFS、ZFS）儲存資料，並實現多種資料自動修復機制。因此，系統極具彈性，即使離線情形下檔案也可以通過其他標準工具進行訪問。如果使用者需要從GlusterFS中遷移資料，不需要作任何修改仍然可以完全使用這些資料。

然而，資料安全成了問題，因為資料是以平凡的方式儲存的，接觸資料的人可以直接複製和檢視。這對很多應用顯然是不能接受的，比如雲端儲存系統，使用者特別關心
資料安全。私有儲存格式可以保證資料的安全性，即使洩露也是不可知的。GlusterFS要實現自己的私有格式，在設計實現和資料管理上相對複雜一些，也
會對效能產生一定影響。

GlusterFS在訪問檔案目錄時根據擴充套件屬性判斷副本是否一致，這個進行資料自動修復的前提條件。節點發生正常的故障，以及從掛載點進行正常的操作，
這些情況下發生的資料不一致，都是可以判斷和自動修復的。但是，如果直接從節點系統底層對原始資料進行修改或者破壞，GlusterFS大多情況下是無法
判斷的，因為資料本身也沒有校驗，資料一致性無法保證。

8、Cache一致性

為了簡化Cache一致性，GlusterFS沒有引入客戶端寫Cache，而採用了客戶端只讀Cache。GlusterFS採用簡單的弱一致性，資料
快取的更新規則是根據設定的失效時間進行重置的。對於快取的資料，客戶端週期性詢問伺服器，查詢檔案最後被修改的時間，如果本地快取的資料早於該時間，則
讓快取資料失效，下次讀取資料時就去伺服器獲取最新的資料。

GlusterFS客戶端讀Cache重新整理的時間預設是1秒，可以通過重新設定卷引數Performance.cache-refresh-
timeout進行調整。這意味著，如果同時有多個使用者在讀寫一個檔案，一個使用者更新了資料，另一個使用者在Cache重新整理週期到來前可能讀到非最新的數
據，即無法保證資料的強一致性。因此實際應用時需要在效能和資料一致性之間進行折中，如果需要更高的資料一致性，就得調小快取重新整理週期，甚至禁用讀快取；
反之，是可以把快取週期調大一點，以提升讀效能。