原文：http://blog.sina.com.cn/s/blog_6b89db7a0101gbcy.html
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刷新周期到來前可能讀到非最新的數據，即無法保證數據的強一致性。因此實際應用時需要在性能和數據一致性之間進行折中，如果需要更高的數據一致性，就得調小緩存刷新周期，甚至禁用讀緩存；反之，是可以把緩存周期調大一點，以提升讀性能。