GlusterFS

1.      GlusterFS概述 

GlusterFS是Scale-Out存儲解決方案Gluster的核心，它是一個開源的分佈式文件系統，具備強大的橫向擴展能力，經過擴展可以支持數PB存儲容量和處理數千客戶端。GlusterFS藉助TCP/IP或InfiniBand RDMA網絡將物理分佈的存儲資源彙集在一塊兒，使用單一全局命名空間來管理數據。GlusterFS基於可堆疊的用戶空間設計，可爲各類不一樣的數據負載提供優異的性能。 



圖1 GlusterFS統一的掛載點 
GlusterFS支持運行在任何標準IP網絡上標準應用程序的標準客戶端，如圖2所示，用戶能夠在全局統一的命名空間中使用NFS/CIFS等標準協議來訪問應用數據。GlusterFS使得用戶可擺脫原有的獨立、高成本的封閉存儲系統，可以利用普通廉價的存儲設備來部署可集中管理、橫向擴展、虛擬化的存儲池，存儲容量可擴展至TB/PB級。GlusterFS主要特徵以下： 
l  擴展性和高性能 
GlusterFS利用雙重特性來提供幾TB至數PB的高擴展存儲解決方案。Scale-Out架構容許經過簡單地增長資源來提升存儲容量和性能，磁盤、計算和I/O資源均可以獨立增長，支持10GbE和InfiniBand等高速網絡互聯。Gluster彈性哈希（Elastic Hash）解除了GlusterFS對元數據服務器的需求，消除了單點故障和性能瓶頸，真正實現了並行化數據訪問。 
l  高可用性 
GlusterFS能夠對文件進行自動複製，如鏡像或屢次複製，從而確保數據老是能夠訪問，甚至是在硬件故障的狀況下也能正常訪問。自我修復功能可以把數據恢復到正確的狀態，並且修復是以增量的方式在後臺執行，幾乎不會產生性能負載。GlusterFS沒有設計本身的私有數據文件格式，而是採用操做系統中主流標準的磁盤文件系統（如EXT三、ZFS）來存儲文件，所以數據可使用各類標準工具進行復制和訪問。 
l  全局統一命名空間 
全局統一命名空間將磁盤和內存資源彙集成一個單一的虛擬存儲池，對上層用戶和應用屏蔽了底層的物理硬件。存儲資源能夠根據須要在虛擬存儲池中進行彈性擴展，好比擴容或收縮。當存儲虛擬機映像時，存儲的虛擬映像文件沒有數量限制，成千虛擬機均經過單一掛載點進行數據共享。虛擬機I/O可在命名空間內的全部服務器上自動進行負載均衡，消除了SAN環境中常常發生的訪問熱點和性能瓶頸問題。 
l  彈性哈希算法 
GlusterFS採用彈性哈希算法在存儲池中定位數據，而不是採用集中式或分佈式元數據服務器索引。在其餘的Scale-Out存儲系統中，元數據服務器一般會致使I/O性能瓶頸和單點故障問題。GlusterFS中，全部在Scale-Out存儲配置中的存儲系統均可以智能地定位任意數據分片，不須要查看索引或者向其餘服務器查詢。這種設計機制徹底並行化了數據訪問，實現了真正的線性性能擴展。 
l  彈性卷管理 
數據儲存在邏輯卷中，邏輯卷能夠從虛擬化的物理存儲池進行獨立邏輯劃分而獲得。存儲服務器能夠在線進行增長和移除，不會致使應用中斷。邏輯卷能夠在全部配置服務器中增加和縮減，能夠在不一樣服務器遷移進行容量均衡，或者增長和移除系統，這些操做均可在線進行。文件系統配置更改也能夠實時在線進行並應用，從而能夠適應工做負載條件變化或在線性能調優。 
l  基於標準協議 
Gluster存儲服務支持NFS, CIFS, HTTP, FTP以及Gluster原生協議，徹底與POSIX標準兼容。現有應用程序不須要做任何修改或使用專用API，就能夠對Gluster中的數據進行訪問。這在公有云環境中部署Gluster時很是有用，Gluster對雲服務提供商專用API進行抽象，而後提供標準POSIX接口。 
2.      設計目標 

GlusterFS的設計思想顯著區別有現有並行/集羣/分佈式文件系統。若是GlusterFS在設計上沒有本質性的突破，難以在與Lustre、PVFS二、Ceph等的競爭中佔據優點，更別提與GPFS、StorNext、ISILON、IBRIX等具備多年技術沉澱和市場積累的商用文件系統競爭。其核心設計目標包括以下三個： 
l  彈性存儲系統（Elasticity） 
存儲系統具備彈性能力，意味着企業能夠根據業務須要靈活地增長或縮減數據存儲以及增刪存儲池中的資源，而不須要中斷系統運行。GlusterFS設計目標之一就是彈性，容許動態增刪數據卷、擴展或縮減數據卷、增刪存儲服務器等，不影響系統正常運行和業務服務。GlusterFS早期版本中彈性不足，部分管理工做須要中斷服務，目前最新的3.1.X版本已經彈性十足，可以知足對存儲系統彈性要求高的應用需求，尤爲是對雲存儲服務系統而言意義更大。GlusterFS主要經過存儲虛擬化技術和邏輯卷管理來實現這一設計目標。 
l  線性橫向擴展（Linear Scale-Out） 
線性擴展對於存儲系統而言是很是難以實現的，一般系統規模擴展與性能提高之間是LOG對數曲線關係，由於同時會產生相應負載而消耗了部分性能的提高。如今的不少並行/集羣/分佈式文件系統都具很高的擴展能力，Luster存儲節點能夠達到1000個以上，客戶端數量可以達到25000以上，這個擴展能力是很是強大的，可是Lustre也不是線性擴展的。 
縱向擴展（Scale-Up）旨在提升單個節點的存儲容量或性能，每每存在理論上或物理上的各類限制，而沒法知足存儲需求。橫向擴展（Scale-Out）經過增長存儲節點來提高整個系統的容量或性能，這一擴展機制是目前的存儲技術熱點，能有效應對容量、性能等存儲需求。目前的並行/集羣/分佈式文件系統大多都具有橫向擴展能力。 
GlusterFS是線性橫向擴展架構，它經過橫向擴展存儲節點便可以得到線性的存儲容量和性能的提高。所以，結合縱向擴展GlusterFS能夠得到多維擴展能力，增長每一個節點的磁盤可增長存儲容量，增長存儲節點能夠提升性能，從而將更多磁盤、內存、I/O資源彙集成更大容量、更高性能的虛擬存儲池。GlusterFS利用三種基本技術來得到線性橫向擴展能力： 
1)        消除元數據服務 
2)        高效數據分佈，得到擴展性和可靠性 
3)        經過徹底分佈式架構的並行化得到性能的最大化 
l  高可靠性（Reliability） 
與GFS（Google File System）相似，GlusterFS能夠構建在普通的服務器和存儲設備之上，所以可靠性顯得尤其關鍵。GlusterFS從設計之初就將可靠性歸入核心設計，採用了多種技術來實現這一設計目標。首先，它假設故障是正常事件，包括硬件、磁盤、網絡故障以及管理員誤操做形成的數據損壞等。GlusterFS設計支持自動複製和自動修復功能來保證數據可靠性，不須要管理員的干預。其次，GlusterFS利用了底層EXT3/ZFS等磁盤文件系統的日誌功能來提供必定的數據可靠性，而沒有本身從新發明輪子。再次，GlusterFS是無元數據服務器設計，不須要元數據的同步或者一致性維護，很大程度上下降了系統複雜性，不只提升了性能，還大大提升了系統可靠性。 
3.      技術特色 

GlusterFS在技術實現上與傳統存儲系統或現有其餘分佈式文件系統有顯著不一樣之處，主要體如今以下幾個方面。 
l  徹底軟件實現（Software Only） 
GlusterFS認爲存儲是軟件問題，不可以把用戶侷限於使用特定的供應商或硬件配置來解決。GlusterFS採用開放式設計，普遍支持工業標準的存儲、網絡和計算機設備，而非與定製化的專用硬件設備捆綁。對於商業客戶，GlusterFS能夠以虛擬裝置的形式交付，也能夠與虛擬機容器打包，或者是公有云中部署的映像。開源社區中，GlusterFS被大量部署在基於廉價閒置硬件的各類操做系統上，構成集中統一的虛擬存儲資源池。簡而言之，GlusterFS是開放的全軟件實現，徹底獨立於硬件和操做系統。 
l  完整的存儲操做系統棧（Complete Storage Operating System Stack） 
GlusterFS不只提供了一個分佈式文件系統，並且還提供了許多其餘重要的分佈式功能，好比分佈式內存管理、I/O調度、軟RAID和自我修復等。GlusterFS汲取了微內核架構的經驗教訓，借鑑了GNU/Hurd操做系統的設計思想，在用戶空間實現了完整的存儲操做系統棧。 
l  用戶空間實現（User Space） 
與傳統的文件系統不一樣，GlusterFS在用戶空間實現，這使得其安裝和升級特別簡便。另外，這也極大下降了普通用戶基於源碼修改GlusterFS的門檻，僅僅須要通用的C程序設計技能，而不須要特別的內核編程經驗。 
l  模塊化堆棧式架構（Modular Stackable Architecture） 
GlusterFS採用模塊化、堆棧式的架構，可經過靈活的配置支持高度定製化的應用環境，好比大文件存儲、海量小文件存儲、雲存儲、多傳輸協議應用等。每一個功能以模塊形式實現，而後以積木方式進行簡單的組合，便可實現複雜的功能。好比，Replicate模塊可實現RAID1，Stripe模塊可實現RAID0，經過二者的組合可實現RAID10和RAID01，同時得到高性能和高可靠性。 
l  原始數據格式存儲（Data Stored in Native Formats） 
GlusterFS以原始數據格式（如EXT三、EXT四、XFS、ZFS）儲存數據，並實現多種數據自動修復機制。所以，系統極具彈性，即便離線情形下文件也能夠經過其餘標準工具進行訪問。若是用戶須要從GlusterFS中遷移數據，不須要做任何修改仍然能夠徹底使用這些數據。 
l  無元數據服務設計（No Metadata with the Elastic Hash Algorithm） 
對Scale-Out存儲系統而言，最大的挑戰之一就是記錄數據邏輯與物理位置的映像關係，即數據元數據，可能還包括諸如屬性和訪問權限等信息。傳統分佈式存儲系統使用集中式或分佈式元數據服務來維護元數據，集中式元數據服務會致使單點故障和性能瓶頸問題，而分佈式元數據服務存在性能負載和元數據同步一致性問題。特別是對於海量小文件的應用，元數據問題是個很是大的挑戰。 
GlusterFS獨特意採用無元數據服務的設計，取而代之使用算法來定位文件，元數據和數據沒有分離而是一塊兒存儲。集羣中的全部存儲系統服務器均可以智能地對文件數據分片進行定位，僅僅根據文件名和路徑並運用算法便可，而不須要查詢索引或者其餘服務器。這使得數據訪問徹底並行化，從而實現真正的線性性能擴展。無元數據服務器極大提升了GlusterFS的性能、可靠性和穩定性。 
4.      整體架構與設計 




圖2 GlusterFS架構和組成 
GlusterFS整體架構與組成部分如圖2所示，它主要由存儲服務器（Brick Server）、客戶端以及NFS/Samba存儲網關組成。不難發現，GlusterFS架構中沒有元數據服務器組件，這是其最大的設計這點，對於提高整個系統的性能、可靠性和穩定性都有着決定性的意義。GlusterFS支持TCP/IP和InfiniBand RDMA高速網絡互聯，客戶端可經過原生Glusterfs協議訪問數據，其餘沒有運行GlusterFS客戶端的終端可經過NFS/CIFS標準協議經過存儲網關訪問數據。 
存儲服務器主要提供基本的數據存儲功能，最終的文件數據經過統一的調度策略分佈在不一樣的存儲服務器上。它們上面運行着Glusterfsd進行，負責處理來自其餘組件的數據服務請求。如前所述，數據以原始格式直接存儲在服務器的本地文件系統上，如EXT三、EXT四、XFS、ZFS等，運行服務時指定數據存儲路徑。多個存儲服務器能夠經過客戶端或存儲網關上的卷管理器組成集羣，如Stripe（RAID0）、Replicate（RAID1）和DHT（分佈式Hash）存儲集羣，也可利用嵌套組合構成更加複雜的集羣，如RAID10。 
因爲沒有了元數據服務器，客戶端承擔了更多的功能，包括數據卷管理、I/O調度、文件定位、數據緩存等功能。客戶端上運行Glusterfs進程，它實際是Glusterfsd的符號連接，利用FUSE（File system in User Space）模塊將GlusterFS掛載到本地文件系統之上，實現POSIX兼容的方式來訪問系統數據。在最新的3.1.X版本中，客戶端再也不須要獨立維護卷配置信息，改爲自動從運行在網關上的glusterd彈性卷管理服務進行獲取和更新，極大簡化了卷管理。GlusterFS客戶端負載相對傳統分佈式文件系統要高，包括CPU佔用率和內存佔用。 
GlusterFS存儲網關提供彈性卷管理和NFS/CIFS訪問代理功能，其上運行Glusterd和Glusterfs進程，二者都是Glusterfsd符號連接。卷管理器負責邏輯卷的建立、刪除、容量擴展與縮減、容量平滑等功能，並負責向客戶端提供邏輯卷信息及主動更新通知功能等。GlusterFS 3.1.X實現了邏輯卷的彈性和自動化管理，不須要中斷數據服務或上層應用業務。對於Windows客戶端或沒有安裝GlusterFS的客戶端，須要經過NFS/CIFS代理網關來訪問，這時網關被配置成NFS或Samba服務器。相對原生客戶端，網關在性能上要受到NFS/Samba的制約。 



圖3 GlusterFS模塊化堆棧式設計 
   GlusterFS是模塊化堆棧式的架構設計，如圖3所示。模塊稱爲Translator，是GlusterFS提供的一種強大機制，藉助這種良好定義的接口能夠高效簡便地擴展文件系統的功能。服務端與客戶端模塊接口是兼容的，同一個translator可同時在兩邊加載。每一個translator都是SO動態庫，運行時根據配置動態加載。每一個模塊實現特定基本功能，GlusterFS中全部的功能都是經過translator實現，好比Cluster, Storage, Performance, Protocol, Features等，基本簡單的模塊能夠經過堆棧式的組合來實現複雜的功能。這一設計思想借鑑了GNU/Hurd微內核的虛擬文件系統設計，能夠把對外部系統的訪問轉換成目標系統的適當調用。大部分模塊都運行在客戶端，好比合成器、I/O調度器和性能優化等，服務端相對簡單許多。客戶端和存儲服務器均有本身的存儲棧，構成了一棵Translator功能樹，應用了若干模塊。模塊化和堆棧式的架構設計，極大下降了系統設計複雜性，簡化了系統的實現、升級以及系統維護。 
5.      彈性哈希算法 

對於分佈式系統而言，元數據處理是決定系統擴展性、性能以及穩定性的關鍵。GlusterFS另闢蹊徑，完全摒棄了元數據服務，使用彈性哈希算法代替傳統分佈式文件系統中的集中或分佈式元數據服務。這根本性解決了元數據這一難題，從而得到了接近線性的高擴展性，同時也提升了系統性能和可靠性。GlusterFS使用算法進行數據定位，集羣中的任何服務器和客戶端只需根據路徑和文件名就能夠對數據進行定位和讀寫訪問。換句話說，GlusterFS不須要將元數據與數據進行分離，由於文件定位可獨立並行化進行。GlusterFS中數據訪問流程以下： 
一、計算hash值，輸入參數爲文件路徑和文件名； 
二、根據hash值在集羣中選擇子卷（存儲服務器），進行文件定位； 
三、對所選擇的子捲進行數據訪問。 
GlusterFS目前使用Davies-Meyer算法計算文件名hash值，得到一個32位整數。Davies-Meyer算法具備很是好的hash分佈性，計算效率很高。假設邏輯卷中的存儲服務器有N個，則32位整數空間被平均劃分爲N個連續子空間，每一個空間分別映射到一個存儲服務器。這樣，計算獲得的32位hash值就會被投射到一個存儲服務器，即咱們要選擇的子卷。難道真是如此簡單？如今讓咱們來考慮一下存儲節點加入和刪除、文件更名等狀況，GlusterFS如何解決這些問題而具有彈性的呢？ 
邏輯卷中加入一個新存儲節點，若是不做其餘任何處理，hash值映射空間將會發生變化，現有的文件目錄可能會被從新定位到其餘的存儲服務器上，從而致使定位失敗。解決問題的方法是對文件目錄進行從新分佈，把文件移動到正確的存儲服務器上去，但這大大加劇了系統負載，尤爲是對於已經存儲大量的數據的海量存儲系統來講顯然是不可行的。另外一種方法是使用一致性哈希算法，修改新增節點及相鄰節點的hash映射空間，僅須要移動相鄰節點上的部分數據至新增節點，影響相對小了不少。然而，這又帶來另一個問題，即系統總體負載不均衡。GlusterFS沒有采用上述兩種方法，而是設計了更爲彈性的算法。GlusterFS的哈希分佈是以目錄爲基本單位的，文件的父目錄利用擴展屬性記錄了子卷映射信息，其下面子文件目錄在父目錄所屬存儲服務器中進行分佈。因爲文件目錄事先保存了分佈信息，所以新增節點不會影響現有文件存儲分佈，它將今後後的新建立目錄開始參與存儲分佈調度。這種設計，新增節點不須要移動任何文件，可是負載均衡沒有平滑處理，老節點負載較重。GlusterFS在設計中考慮了這一問題，在新建文件時會優先考慮容量負載最輕的節點，在目標存儲節點上建立文件連接直向真正存儲文件的節點。另外，GlusterFS彈性卷管理工具能夠在後臺以人工方式來執行負載平滑，將進行文件移動和從新分佈，此後全部存儲服務器都會均會被調度。 
GlusterFS目前對存儲節點刪除支持有限，還沒法作到徹底無人干預的程度。若是直接刪除節點，那麼所在存儲服務器上的文件將沒法瀏覽和訪問，建立文件目錄也會失敗。當前人工解決方法有兩個，一是將節點上的數據從新複製到GlusterFS中，二是使用新的節點來替換刪除節點並保持原有數據。 
若是一個文件被更名，顯然hash算法將產生不一樣的值，很是可能會發生文件被定位到不一樣的存儲服務器上，從而致使文件訪問失敗。採用數據移動的方法，對於大文件是很難在實時完成的。爲了避免影響性能和服務中斷，GlusterFS採用了文件連接來解決文件重命名問題，在目標存儲服務器上建立一個連接指向實際的存儲服務器，訪問時由系統解析並進行重定向。另外，後臺同時進行文件遷移，成功後文件連接將被自動刪除。對於文件移動也做相似處理，好處是前臺操做可實時處理，物理數據遷移置於後臺選擇適當時機執行。 



圖4 GlusterFS彈性卷管理 
   彈性哈希算法爲文件分配邏輯卷，那麼GlusterFS如何爲邏輯卷分配物理卷呢？GlusterFS3.1.X實現了真正的彈性卷管理，如圖4所示。存儲卷是對底層硬件的抽象，能夠根據須要進行擴容和縮減，以及在不一樣物理系統之間進行遷移。存儲服務器能夠在線增長和移除，並能在集羣之間自動進行數據負載平衡，數據老是在線可用，沒有應用中斷。文件系統配置更新也能夠在線執行，所做配置變更可以快速動態地在集羣中傳播，從而自動適應負載波動和性能調優。 
    彈性哈希算法自己並無提供數據容錯功能，GlusterFS使用鏡像或複製來保證數據可用性，推薦使用鏡像或3路複製。複製模式下，存儲服務器使用同步寫複製到其餘的存儲服務器，單個服務器故障徹底對客戶端透明。此外，GlusterFS沒有對複製數量進行限制，讀被分散到全部的鏡像存儲節點，能夠提升讀性能。彈性哈希算法分配文件到惟一的邏輯卷，而複製能夠保證數據至少保存在兩個不一樣存儲節點，二者結合使得GlusterFS具有更高的彈性。 
6.      Translators 

如前所述，Translators是GlusterFS提供的一種強大文件系統功能擴展機制，這一設計思想借鑑於GNU/Hurd微內核操做系統。GlusterFS中全部的功能都經過Translator機制實現，運行時以動態庫方式進行加載，服務端和客戶端相互兼容。GlusterFS 3.1.X中，主要包括如下幾類Translator： 
（1）  Cluster：存儲集羣分佈，目前有AFR, DHT, Stripe三種方式 
（2）  Debug：跟蹤GlusterFS內部函數和系統調用 
（3）  Encryption：簡單的數據加密實現 
（4）  Features：訪問控制、鎖、Mac兼容、靜默、配額、只讀、回收站等 
（5）  Mgmt：彈性卷管理 
（6）  Mount：FUSE接口實現 
（7）  Nfs：內部NFS服務器 
（8）  Performance：io-cache, io-threads, quick-read, read-ahead, stat-prefetch, sysmlink-cache, write-behind等性能優化 
（9）  Protocol：服務器和客戶端協議實現 
（10）Storage：底層文件系統POSIX接口實現 
這裏咱們重點介紹一下Cluster Translators，它是實現GlusterFS集羣存儲的核心，它包括AFR（Automatic File Replication）、DHT（Distributed Hash Table）和Stripe三種類型。 
AFR至關於RAID1，同一文件在多個存儲節點上保留多份，主要用於實現高可用性以及數據自動修復。AFR全部子捲上具備相同的名字空間，查找文件時從第一個節點開始，直到搜索成功或最後節點搜索完畢。讀數據時，AFR會把全部請求調度到全部存儲節點，進行負載均衡以提升系統性能。寫數據時，首先須要在全部鎖服務器上對文件加鎖，默認第一個節點爲鎖服務器，能夠指定多個。而後，AFR以日誌事件方式對全部服務器進行寫數據操做，成功後刪除日誌並解鎖。AFR會自動檢測並修復同一文件的數據不一致性，它使用更改日誌來肯定好的數據副本。自動修復在文件目錄首次訪問時觸發，若是是目錄將在全部子捲上複製正確數據，若是文件不存則建立，文件信息不匹配則修復，日誌指示更新則進行更新。 
DHT即上面所介紹的彈性哈希算法，它採用hash方式進行數據分佈，名字空間分佈在全部節點上。查找文件時，經過彈性哈希算法進行，不依賴名字空間。但遍歷文件目錄時，則實現較爲複雜和低效，須要搜索全部的存儲節點。單一文件只會調度到惟一的存儲節點，一旦文件被定位後，讀寫模式相對簡單。DHT不具有容錯能力，須要藉助AFR實現高可用性, 如圖5所示應用案例。 
Stripe至關於RAID0，即分片存儲，文件被劃分紅固定長度的數據分片以Round-Robin輪轉方式存儲在全部存儲節點。Stripe全部存儲節點組成完整的名字空間，查找文件時須要詢問全部節點，這點很是低效。讀寫數據時，Stripe涉及所有分片存儲節點，操做能夠在多個節點之間併發執行，性能很是高。Stripe一般與AFR組合使用，構成RAID10/RAID01，同時得到高性能和高可用性，固然存儲利用率會低於50%。 




圖5　GlusterFS應用案例：AFR+DHT 
7.      設計討論 

GlusterFS是一個具備高擴展性、高性能、高可用性、可橫向擴展的彈性分佈式文件系統，在架構設計上很是有特色，好比無元數據服務器設計、堆棧式架構等。然而，存儲應用問題是很複雜的，GlusterFS也不可能知足全部的存儲需求，設計實現上也必定有考慮不足之處，下面咱們做簡要分析。 
l  無元數據服務器 vs 元數據服務器 
無元數據服務器設計的好處是沒有單點故障和性能瓶頸問題，可提升系統擴展性、性能、可靠性和穩定性。對於海量小文件應用，這種設計可以有效解決元數據的難點問題。它的負面影響是，數據一致問題更加複雜，文件目錄遍歷操做效率低下，缺少全局監控管理功能。同時也致使客戶端承擔了更多的職能，好比文件定位、名字空間緩存、邏輯卷視圖維護等等，這些都增長了客戶端的負載，佔用至關的CPU和內存。 
l  用戶空間 vs 內核空間 
用戶空間實現起來相對要簡單許多，對開發者技能要求較低，運行相對安全。用戶空間效率低，數據須要屢次與內核空間交換，另外GlusterFS藉助FUSE來實現標準文件系統接口，性能上又有所損耗。內核空間實現能夠得到很高的數據吞吐量，缺點是實現和調試很是困難，程序出錯常常會致使系統崩潰，安全性低。縱向擴展上，內核空間要優於用戶空間，GlusterFS有橫向擴展能力來彌補。 
l  堆棧式 vs 非堆棧式 
這有點像操做系統的微內核設計與單一內核設計之爭。GlusterFS堆棧式設計思想源自GNU/Hurd微內核操做系統，具備很強的系統擴展能力，系統設計實現複雜性下降不少，基本功能模塊的堆棧式組合就能夠實現強大的功能。查看GlusterFS卷配置文件咱們能夠發現，translator功能樹一般深達10層以上，一層一層進行調用，效率可見一斑。非堆棧式設計可當作相似Linux的單一內核設計，系統調用經過中斷實現，很是高效。後者的問題是系統核心臃腫，實現和擴展複雜，出現問題調試困難。 
l  原始存儲格式 vs 私有存儲格式 
GlusterFS使用原始格式存儲文件或數據分片，能夠直接使用各類標準的工具進行訪問，數據互操做性好，遷移和數據管理很是方便。然而，數據安全成了問題，由於數據是以平凡的方式保存的，接觸數據的人能夠直接複製和查看。這對不少應用顯然是不能接受的，好比雲存儲系統，用戶特別關心數據安全，這也是影響公有云存儲發展的一個重要緣由。私有存儲格式能夠保證數據的安全性，即便泄露也是不可知的。GlusterFS要實現本身的私有格式，在設計實現和數據管理上相對複雜一些，也會對性能產生必定影響。 
l  大文件 vs 小文件 
GlusterFS適合大文件仍是小文件存儲？彈性哈希算法和Stripe數據分佈策略，移除了元數據依賴，優化了數據分佈，提升數據訪問並行性，可以大幅提升大文件存儲的性能。對於小文件，無元數據服務設計解決了元數據的問題。但GlusterFS並無在I/O方面做優化，在存儲服務器底層文件系統上仍然是大量小文件，本地文件系統元數據訪問是一個瓶頸，數據分佈和並行性也沒法充分發揮做用。所以，GlusterFS適合存儲大文件，小文件性能較差，還存在很大優化空間。 
l  可用性 vs 存儲利用率 
GlusterFS使用複製技術來提供數據高可用性，複製數量沒有限制，自動修復功能基於複製來實現。可用性與存儲利用率是一個矛盾體，可用性高存儲利用率就低，反之亦然。採用複製技術，存儲利用率爲1/複製數，鏡像是50%，三路複製則只有33%。其實，能夠有方法來同時提升可用性和存儲利用率，好比RAID5的利用率是(n-1)/n，RAID6是(n-2)/n，而糾刪碼技術能夠提供更高的存儲利用率。可是，魚和熊掌不可得兼，它們都會對性能產生較大影響。 
另外，GlusterFS目前的代碼實現不夠好，系統不夠穩定，BUGS數量相對還比較多。從其官方網站的部署狀況來看，測試用戶很是多，可是真正在生產環境中的應用較少，存儲部署容量幾TB－幾十TB的佔很大比率，數百TB－PB級案例很是少。這也能夠從另外一個方面說明，GlusterFS目前還不夠穩定，須要更長的時間來檢驗。然而不能否認，GlusterFS是一個有着光明前景的集羣文件系統，線性橫向擴展能力使它具備天生的優點，尤爲是對於雲存儲系統。