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沒有設計自己的私有資料檔案格式，而是採用作業系統中主流標準的磁碟檔案系統（如EXT3、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、PVFS2、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以原始資料格式（如EXT3、EXT4、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進行，負責處理來自其他元件的資料服務請求。如前所述，資料以原始格式直接儲存在伺服器的本地檔案系統上，如EXT3、EXT4、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中資料訪問流程如下：

1、計算hash值，輸入引數為檔案路徑和檔名；

2、根據hash值在叢集中選擇子卷（儲存伺服器），進行檔案定位；

3、對所選擇的子捲進行資料訪問。

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是一個有著光明前景的叢集檔案系統，線性橫向擴充套件能力使它具有天生的優勢，尤其是對於雲端儲存系統。