GlusterFS社區最近給出了4.0的開發計劃，其目標是對3.x版本在擴展性和易操作性方面作出重大改進，支持10K節點的集羣擴展能力。爲此，GlusterFS將在系統架構、控制平面和數據平面的內部機制、命令行工具和接口等方面作全新的重構，以實現更大的擴展性和易用性，期望使得GlusterFS成爲倍受用戶青睞的分佈式文件系統。
GlusterFS 4.0開發計劃主要涉及管理平面和數據平面兩大部分，管理平面改進包括資源池管理、簡化卷管理、靈活副本、卷內部機制、簡化卷操作、卷配置數據管理、REST管理API、統一管理、透明驅動器遷移等方面，數據平面改進包括彈性Hash算法2.0、廋原生客戶端和Stripe 2.0等。在這些重大改進中，我個人認爲產生積極影響的是資源池管理、靈活副本、卷配置數據管理、彈性Hash 2.0和Stripe 2.0等五個新特性。
資源池管理
Xlator是GlusterFS最爲核心的概念，按照特定拓撲結構組織的一組xlator可以構建出用戶可訪問的存儲空間，即GLusterFS的卷，也就是一個分佈式文件系統。GlusterFS使用卷配置文件來表示拓撲構造，早先版本需要人工編輯生成該文件，3.0之後引入Gluster工具來簡化卷管理工作。使用gluster工具創建卷，需要按照卷類型指定brick列表和順序，當捲包含的brick數量很大時，比如節點規模達到1000以上，操作非常不便且很容易產生失誤。因此，4.0計劃引入新的管理方式，採用函數編程式的聲明方法，聲明資源屬性並定義操作目標，以更加適合人類思維模式的方式管理資源，簡化管理和提高效率。
靈活副本
複製卷和條帶卷模式下，擴展卷必須以複製和條帶的倍數進行節點擴展，這個在處理卷擴展時極爲不方便。4.0計劃引入兩個特性，一個是複製數和條帶數可動態改變，二是同一個卷中不同子目錄可以設置不同的複製數和條帶數。如此，用戶可以根據實際需求動態調整複製卷和條帶卷設置，管理便利，而且可以提高存儲資源利用率。
卷配置數據管理
GlusterFS 3.x中，配置信息在所有節點之間是同步的，也就是說所有節點都是對等的，每個節點都保存有全部的節點和卷配置信息。這種機制下，要求兩兩節點之間都要建立長連接的通信鏈路，集羣規模擴展會大大受限於此。4.0引入超節點的概念和etcd服務，比如每個機架Rack爲一個超節點，選舉其中一個節點作爲代表節點，多個Rack就會選舉出多個代表節點並組建成一個quorum集羣，存儲所有的配置數據。代表節點之間按照之前的規則進行配置數據同步，Rack中的節點從本Rack代表節點處獲得配置信息。由於代表節點組成的quorum集羣規模遠遠小於整個集羣規模，因此係統擴展能力大大增強。同時，管理服務進程工作也得到一定解放，不用再負責配置信息同步，而轉爲重點負責存儲智能管理、系統監控和brick進程管理等工作。
彈性Hash 2.0
當前DHT Xlator在所有brick上維護相同的命名空間目錄結構，lookup時需要與所有brick交互通信，實際上這是GluserFS擴展到10K節點的最大限制因素。4.0引入一個種全新的方法來消除這種限制，它選擇一個brick子集(一個或多個)來存儲目錄結構，僅存儲分配有GFID的目錄，而不存儲任何文件，這樣的節點稱爲框架節點。目錄結構覆蓋整個命名空間，目錄下的文件通過hash算法分散到不同節點上。對於每一個目錄，每個節點會在偏平命名空間下創建一個對應的目錄描述文件，採用UUID方式的ASCII編碼GFID命名。ls列目錄時，首先從框架節點上獲得所有子目錄，然後從所有數據節點獲取文件列表，從而獲得完整的目錄文件列表。數據節點上也會保存文件對應子目錄的列表項文件，當框架節點不可用時，可以用數據節點上獲取子目錄列表。這種模式下，擴展目錄獨立於父目錄或子目錄，服務器的擴展數量遠高於目前集羣可達的規模。框架節點不會產生新的負載，實際上當前系統中已經隨處存在(比如複製卷和鎖節點)，這樣我們可以把負載從N個節點減少到一個節點。此外，這種方式還可帶來諸如以下的其他更多好處。
(1)由於每個目錄是完全獨立的，按目錄級別設置複製實現難度大大降低；
(2)數據節點上的偏平目錄可以按需進行創建，當首次文件名hash到節點時創建；
(3)框架目錄結構可以存儲在SSD固態硬盤上，或者使用大緩存，以加速目錄結構訪問；
(4)框架目錄結構能夠存儲所有節點的hash範圍，可以有效避免lookup扇出；
(5)框架節點上目錄訪問記帳(如訪問時間、文件大小、文件數量等)，相比在數據節點上處理，會避免大量的重複操作。
Stripe 2.0
GlusterFS處理超大文件的方法不夠明智，一個文件大小可能增長超過一個brick容量。GlusterFS可以使用stripe進行條帶化存儲，但不夠靈活，不可能混合存儲條帶化的文件和非條帶化的文件。在大數據或hadoop應用下，超大文件是正常現象，這就限制了GlusterFS適用範圍。4.0計劃提出使用Shard xlator替換原先的條帶，初始情況下所有文件都正常創建，當文件增長每超過預先設置的閾值(如64MB)，則按照特定 規則生成一個新文件，比如依據GFID和塊索引號命名。這種模式下，所有數據塊仍然按正常的Hash方式分佈，擴展節點不需要按照之前的條帶倍數進行，大文件的自修復拆分成多個較小文件在多個節點之間併發進行，數據塊文件名命名模式不受重命名和硬鏈接影響。
GlusterFS 4.0開發計劃主要涉及管理平面和數據平面兩大部分，管理平面改進包括資源池管理、簡化卷管理、靈活副本、卷內部機制、簡化卷操作、卷配置數據管理、REST管理API、統一管理、透明驅動器遷移等方面，數據平面改進包括彈性Hash算法2.0、廋原生客戶端和Stripe 2.0等。在這些重大改進中，我個人認爲產生積極影響的是資源池管理、靈活副本、卷配置數據管理、彈性Hash 2.0和Stripe 2.0等五個新特性。
資源池管理
Xlator是GlusterFS最爲核心的概念，按照特定拓撲結構組織的一組xlator可以構建出用戶可訪問的存儲空間，即GLusterFS的卷，也就是一個分佈式文件系統。GlusterFS使用卷配置文件來表示拓撲構造，早先版本需要人工編輯生成該文件，3.0之後引入Gluster工具來簡化卷管理工作。使用gluster工具創建卷，需要按照卷類型指定brick列表和順序，當捲包含的brick數量很大時，比如節點規模達到1000以上，操作非常不便且很容易產生失誤。因此，4.0計劃引入新的管理方式，採用函數編程式的聲明方法，聲明資源屬性並定義操作目標，以更加適合人類思維模式的方式管理資源，簡化管理和提高效率。
靈活副本
複製卷和條帶卷模式下，擴展卷必須以複製和條帶的倍數進行節點擴展，這個在處理卷擴展時極爲不方便。4.0計劃引入兩個特性，一個是複製數和條帶數可動態改變，二是同一個卷中不同子目錄可以設置不同的複製數和條帶數。如此，用戶可以根據實際需求動態調整複製卷和條帶卷設置，管理便利，而且可以提高存儲資源利用率。
卷配置數據管理
GlusterFS 3.x中，配置信息在所有節點之間是同步的，也就是說所有節點都是對等的，每個節點都保存有全部的節點和卷配置信息。這種機制下，要求兩兩節點之間都要建立長連接的通信鏈路，集羣規模擴展會大大受限於此。4.0引入超節點的概念和etcd服務，比如每個機架Rack爲一個超節點，選舉其中一個節點作爲代表節點，多個Rack就會選舉出多個代表節點並組建成一個quorum集羣，存儲所有的配置數據。代表節點之間按照之前的規則進行配置數據同步，Rack中的節點從本Rack代表節點處獲得配置信息。由於代表節點組成的quorum集羣規模遠遠小於整個集羣規模，因此係統擴展能力大大增強。同時，管理服務進程工作也得到一定解放，不用再負責配置信息同步，而轉爲重點負責存儲智能管理、系統監控和brick進程管理等工作。
彈性Hash 2.0
當前DHT Xlator在所有brick上維護相同的命名空間目錄結構，lookup時需要與所有brick交互通信，實際上這是GluserFS擴展到10K節點的最大限制因素。4.0引入一個種全新的方法來消除這種限制，它選擇一個brick子集(一個或多個)來存儲目錄結構，僅存儲分配有GFID的目錄，而不存儲任何文件，這樣的節點稱爲框架節點。目錄結構覆蓋整個命名空間，目錄下的文件通過hash算法分散到不同節點上。對於每一個目錄，每個節點會在偏平命名空間下創建一個對應的目錄描述文件，採用UUID方式的ASCII編碼GFID命名。ls列目錄時，首先從框架節點上獲得所有子目錄，然後從所有數據節點獲取文件列表，從而獲得完整的目錄文件列表。數據節點上也會保存文件對應子目錄的列表項文件，當框架節點不可用時，可以用數據節點上獲取子目錄列表。這種模式下，擴展目錄獨立於父目錄或子目錄，服務器的擴展數量遠高於目前集羣可達的規模。框架節點不會產生新的負載，實際上當前系統中已經隨處存在(比如複製卷和鎖節點)，這樣我們可以把負載從N個節點減少到一個節點。此外，這種方式還可帶來諸如以下的其他更多好處。
(1)由於每個目錄是完全獨立的，按目錄級別設置複製實現難度大大降低；
(2)數據節點上的偏平目錄可以按需進行創建，當首次文件名hash到節點時創建；
(3)框架目錄結構可以存儲在SSD固態硬盤上，或者使用大緩存，以加速目錄結構訪問；
(4)框架目錄結構能夠存儲所有節點的hash範圍，可以有效避免lookup扇出；
(5)框架節點上目錄訪問記帳(如訪問時間、文件大小、文件數量等)，相比在數據節點上處理，會避免大量的重複操作。
Stripe 2.0
GlusterFS處理超大文件的方法不夠明智，一個文件大小可能增長超過一個brick容量。GlusterFS可以使用stripe進行條帶化存儲，但不夠靈活，不可能混合存儲條帶化的文件和非條帶化的文件。在大數據或hadoop應用下，超大文件是正常現象，這就限制了GlusterFS適用範圍。4.0計劃提出使用Shard xlator替換原先的條帶，初始情況下所有文件都正常創建，當文件增長每超過預先設置的閾值(如64MB)，則按照特定 規則生成一個新文件，比如依據GFID和塊索引號命名。這種模式下，所有數據塊仍然按正常的Hash方式分佈，擴展節點不需要按照之前的條帶倍數進行，大文件的自修復拆分成多個較小文件在多個節點之間併發進行，數據塊文件名命名模式不受重命名和硬鏈接影響。
