換個角度深刻理解GlusterFS（三）

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

 

固然，GlusterFS不是一個完美的分佈式文件系統，這個系統自身也有許多不足之處，包括衆所周知的元數據性能和小文件問題。沒有廣泛適用各類應用場景的分佈式文件系統，通用的意思就是統統不能用，四大開源系統不例外，全部商業產品也不例外。每一個分佈式文件系統都有它適用的應用場景，適合的纔是最好的。這一次咱們反其道而行之，再也不談GlusterFS的各類優勢，而是深刻談談GlusterFS當下的問題和不足，從而更加深刻地理解GlusterFS系統，指望幫助你們進行正確的系統選型決策和規避應用中的問題。同時，這些問題也是GlusterFS研究和研發的很好切入點。

一、元數據性能

GlusterFS使用彈性哈希算法代替傳統分佈式文件系統中的集中或分佈式元數據服務，這個是GlusterFS最核心的思想，從而得到了接近線性的高擴展性，同時也提升了系統性能和可靠性。GlusterFS使用算法進行數據定位，集羣中的任何服務器和客戶端只需根據路徑和文件名就能夠對數據進行定位和讀寫訪問，文件定位可獨立並行化進行。

 

這種算法的特色是，給定肯定的文件名，查找和定位會很是快。可是，若是事先不知道文件名，要列出文件目錄（ls或ls -l），性能就會大幅降低。對於Distributed哈希卷，文件經過HASH算法分散到集羣節點上，每一個節點上的命名空間均不重疊，全部集羣共同構成完整的命名空間，訪問時使用HASH算法進行查找定位。列文件目錄時，須要查詢全部節點，並對文件目錄信息及屬性進行聚合。這時，哈希算法根本發揮不上做用，相對於有中心的元數據服務，查詢效率要差不少。

 

從我接觸的一些用戶和實踐來看，當集羣規模變大以及文件數量達到百萬級別時，ls文件目錄和rm刪除文件目錄這兩個典型元數據操做就會變得很是慢，建立和刪除100萬個空文件可能會花上15分鐘。如何解決這個問題呢？咱們建議合理組織文件目錄，目錄層次不要太深，單個目錄下文件數量不要過多；增大服務器內存配置，而且增大GlusterFS目錄緩存參數；網絡配置方面，建議採用萬兆或者InfiniBand。從研發角度看，能夠考慮優化方法提高元數據性能。好比，能夠構建全局統一的分佈式元數據緩存系統；也能夠將元數據與數據從新分離，每一個節點上的元數據採用全內存或數據庫設計，並採用SSD進行元數據持久化。

 

二、小文件問題

理論和實踐上分析，GlusterFS目前主要適用大文件存儲場景，對於小文件尤爲是海量小文件，存儲效率和訪問性能都表現不佳。海量小文件LOSF問題是工業界和學術界公認的難題，GlusterFS做爲通用的分佈式文件系統，並無對小文件做額外的優化措施，性能很差也是能夠理解的。

 

對於LOSF而言，IOPS/OPS是關鍵性能衡量指標，形成性能和存儲效率低下的主要緣由包括元數據管理、數據佈局和I/O管理、Cache管理、網絡開銷等方面。從理論分析以及LOSF優化實踐來看，優化應該從元數據管理、緩存機制、合併小文件等方面展開，並且優化是一個系統工程，結合硬件、軟件，從多個層面同時着手，優化效果會更顯著。GlusterFS小文件優化能夠考慮這些方法，這裏再也不贅述，關於小文件問題請參考「海量小文件問題綜述」一文。

 

三、集羣管理模式

GlusterFS集羣採用全對等式架構，每一個節點在集羣中的地位是徹底對等的，集羣配置信息和卷配置信息在全部節點之間實時同步。這種架構的優勢是，每一個節點都擁有整個集羣的配置信息，具備高度的獨立自治性，信息能夠本地查詢。但同時帶來的問題的，一旦配置信息發生變化，信息須要實時同步到其餘全部節點，保證配置信息一致性，不然GlusterFS就沒法正常工做。在集羣規模較大時，不一樣節點併發修改配置時，這個問題表現尤其突出。由於這個配置信息同步模型是網狀的，大規模集羣不只信息同步效率差，並且出現數據不一致的機率會增長。

 

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

 

四、容量負載均衡

GlusterFS的哈希分佈是以目錄爲基本單位的，文件的父目錄利用擴展屬性記錄了子卷映射信息，子文件在父目錄所屬存儲服務器中進行分佈。因爲文件目錄事先保存了分佈信息，所以新增節點不會影響現有文件存儲分佈，它將今後後的新建立目錄開始參與存儲分佈調度。這種設計，新增節點不須要移動任何文件，可是負載均衡沒有平滑處理，老節點負載較重。GlusterFS實現了容量負載均衡功能，能夠對已經存在的目錄文件進行Rebalance，使得早先建立的老目錄能夠在新增存儲節點上分佈，並可對現有文件數據進行遷移實現容量負載均衡。

 

GlusterFS目前的容量負載均衡存在一些問題。因爲採用Hash算法進行數據分佈，容量負載均衡須要對全部數據從新進行計算並分配存儲節點，對於那些不須要遷移的數據來講，這個計算是多餘的。Hash分佈具備隨機性和均勻性的特色，數據從新分佈以後，老節點會有大量數據遷入和遷出，這個多出了不少數據遷移量。相對於有中心的架構，可謂節點一變而動全身，增長和刪除節點增長了大量數據遷移工做。GlusterFS應該優化數據分佈，最小化容量負載均衡數據遷移。此外，GlusterFS容量負載均衡也沒有很好考慮執行的自動化、智能化和並行化。目前，GlusterFS在增長和刪除節點上，須要手工執行負載均衡，也沒有考慮當前系統的負載狀況，可能影響正常的業務訪問。GlusterFS的容量負載均衡是經過在當前執行節點上掛載卷，而後進行文件複製、刪除和更名操做實現的，沒有在全部集羣節點上併發進行，負載均衡性能差。

 

五、數據分佈問題

Glusterfs主要有三種基本的集羣模式，即分佈式集羣(Distributed cluster)、條帶集羣(Stripe cluster)、複製集羣(Replica cluster)。這三種基本集羣還能夠採用相似堆積木的方式，構成更加複雜的複合集羣。三種基本集羣各由一個translator來實現，分別由本身獨立的命名空間。對於分佈式集羣，文件經過HASH算法分散到集羣節點上，訪問時使用HASH算法進行查找定位。複製集羣相似RAID1，全部節點數據徹底相同，訪問時能夠選擇任意個節點。條帶集羣與RAID0類似，文件被分紅數據塊以Round Robin方式分佈到全部節點上，訪問時根據位置信息肯定節點。

 

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

 

六、數據可用性問題

副本（Replication）就是對原始數據的徹底拷貝。經過爲系統中的文件增長各類不一樣形式的副本，保存冗餘的文件數據，能夠十分有效地提升文件的可用性，避免在地理上普遍分佈的系統節點由網絡斷開或機器故障等動態不可測因素而引發的數據丟失或不可獲取。GlusterFS主要使用複製來提供數據的高可用性，經過的集羣模式有複製卷和哈希複製卷兩種模式。複製卷是文件級RAID1，具備容錯能力，數據同步寫到多個brick上，每一個副本均可以響應讀請求。當有副本節點發生故障，其餘副本節點仍然正常提供讀寫服務，故障節點恢復後經過自修復服務或同步訪問時自動進行數據同步。

 

通常而言，副本數量越多，文件的可靠性就越高，可是若是爲全部文件都保存較多的副本數量，存儲利用率低（爲副本數量分之一），並增長文件管理的複雜度。目前GlusterFS社區正在研發糾刪碼功能，經過冗餘編碼提升存儲可用性，而且具有較低的空間複雜度和數據冗餘度，存儲利用率高。

 

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

 

七、數據安全問題

GlusterFS以原始數據格式（如EXT四、XFS、ZFS）存儲數據，並實現多種數據自動修復機制。所以，系統極具彈性，即便離線情形下文件也能夠經過其餘標準工具進行訪問。若是用戶須要從GlusterFS中遷移數據，不須要做任何修改仍然能夠徹底使用這些數據。

 

然而，數據安全成了問題，由於數據是以平凡的方式保存的，接觸數據的人能夠直接複製和查看。這對不少應用顯然是不能接受的，好比雲存儲系統，用戶特別關心數據安全。私有存儲格式能夠保證數據的安全性，即便泄露也是不可知的。GlusterFS要實現本身的私有格式，在設計實現和數據管理上相對複雜一些，也會對性能產生必定影響。

 

GlusterFS在訪問文件目錄時根據擴展屬性判斷副本是否一致，這個進行數據自動修復的前提條件。節點發生正常的故障，以及從掛載點進行正常的操做，這些狀況下發生的數據不一致，都是能夠判斷和自動修復的。可是，若是直接從節點系統底層對原始數據進行修改或者破壞，GlusterFS大多狀況下是沒法判斷的，由於數據自己也沒有校驗，數據一致性沒法保證。

 

八、Cache一致性

爲了簡化Cache一致性，GlusterFS沒有引入客戶端寫Cache，而採用了客戶端只讀Cache。GlusterFS採用簡單的弱一致性，數據緩存的更新規則是根據設置的失效時間進行重置的。對於緩存的數據，客戶端週期性詢問服務器，查詢文件最後被修改的時間，若是本地緩存的數據早於該時間，則讓緩存數據失效，下次讀取數據時就去服務器獲取最新的數據。

 

GlusterFS客戶端讀Cache刷新的時間缺省是1秒，能夠經過從新設置卷參數Performance.cache-refresh-timeout進行調整。這意味着，若是同時有多個用戶在讀寫一個文件，一個用戶更新了數據，另外一個用戶在Cache刷新週期到來前可能讀到非最新的數據，即沒法保證數據的強一致性。所以實際應用時須要在性能和數據一致性之間進行折中，若是須要更高的數據一致性，就得調小緩存刷新週期，甚至禁用讀緩存；反之，是能夠把緩存週期調大一點，以提高讀性能。

參考文章：https://blog.csdn.net/liuaigui/article/details/20941159