分散式檔案系統
分散式檔案系統（Distributed File System）是指檔案系統管理的物理儲存資源並不直接與本地節點相連，而是分佈於計算網路中的一個或者多個節點的計算機上。目前意義上的分散式檔案系統大多都是由多個節點計算機構成，結構上是典型的客戶機/伺服器模式。流行的模式是當客戶機需要儲存資料時，伺服器指引其將資料分散的儲存到多個儲存節點上，以提供更快的速度，更大的容量及更好的冗餘特性。
分散式檔案系統的產生
計算機通過檔案系統管理、儲存資料，而現在資料資訊爆炸的時代中人們可以獲取的資料成指數倍的增長，單純通過增加硬碟個數來擴充套件計算機檔案系統的儲存容量的方式，已經不能滿足目前的需求。
分散式檔案系統可以有效解決資料的儲存和管理難題，將固定於某個地點的某個檔案系統，擴充套件到任意多個地點/多個檔案系統，眾多的節點組成一個檔案系統網路。每個節點可以分佈在不同的地點，通過網路進行節點間的通訊和資料傳輸。人們在使用分散式檔案系統時，無需關心資料是儲存在哪個節點上、或者是從哪個節點從獲取的，只需要像使用本地檔案系統一樣管理和儲存檔案系統中的資料。
.典型代表NFS
NFS（Network File System）即網路檔案系統，它允許網路中的計算機之間通過TCP/IP網路共享資源。在NFS的應用中，本地NFS的客戶端應用可以透明地讀寫位於遠端NFS伺服器上的檔案，就像訪問本地檔案一樣。
.NFS的優點如下：
1）節約使用的磁碟空間
客戶端經常使用的資料可以集中存放在一臺機器上,並使用NFS釋出,那麼網路內部所有計算機可以通過網路訪問,不必單獨儲存。
2）節約硬體資源
NFS還可以共享軟碟機,CDROM和ZIP等的儲存裝置,減少整個網路上的可移動裝置的數量。
3）使用者主目錄設定
對於特殊使用者,如管理員等,為了管理的需要,可能會經常登入到網路中所有的計算機,若每個客戶端,均儲存這個使用者的主目錄很繁瑣,而且不能保證資料的一致性.實際上,經過NFS服務的設定,然後在客戶端指定這個使用者的主目錄位置,並自動掛載,就可以在任何計算機上使用使用者主目錄的檔案。
.NFS面臨的問題
1）儲存空間不足，需要更大容量的儲存。
2）直接用NFS掛載儲存，有一定風險，存在單點故障。
3）某些場景不能滿足要求，大量的訪問磁碟IO是瓶頸。
目前流行的分散式檔案系統有許多，如MooseFS、FastDFS、GlusterFS、Ceph、MogileFS等，常見的分散式儲存對比如下：
- FastDFS：一個開源的輕量級分散式檔案系統，是純C語言開發的。它對檔案進行管理，功能包括：檔案儲存、檔案同步、檔案訪問（檔案上傳、檔案下載）等，解決了大容量儲存和負載均衡的問題。特別適合以檔案為載體的線上服務，如相簿網站、視訊網站等等。FastDFS 針對大量小檔案儲存有優勢。
- GlusterFS：主要應用在叢集系統中，具有很好的可擴充套件性。軟體的結構設計良好，易於擴充套件和配置，通過各個模組的靈活搭配以得到針對性的解決方案。GlusterFS適合大檔案，小檔案效能相對較差。
- MooseFS：比較接近GoogleFS的c++實現，通過fuse支援了標準的posix，支援FUSE，相對比較輕量級，對master伺服器有單點依賴，用perl編寫，算是通用的檔案系統，可惜社群不是太活躍，效能相對其他幾個來說較差，國內用的人比較多。
- Ceph：C++編寫，效能很高，支援Fuse，並且沒有單點故障依賴；Ceph 是一種全新的儲存方法，對應於 Swift 物件儲存。在物件儲存中，應用程式不會寫入檔案系統，而是使用儲存中的直接 API 訪問寫入儲存。因此，應用程式能夠繞過作業系統的功能和限制。在openstack社群比較火，做虛機塊儲存用的很多！
- GoogleFS：效能十分好，可擴充套件性強，可靠性強。用於大型的、分散式的、對大資料進行訪問的應用。運用在廉價的硬體上。
GlusterFS儲存基礎梳理
GlusterFS系統是一個可擴充套件的網路檔案系統，相比其他分散式檔案系統，GlusterFS具有高擴充套件性、高可用性、高效能、可橫向擴充套件等特點，並且其沒有後設資料伺服器的設計，讓整個服務沒有單點故障的隱患。Glusterfs是一個橫向擴充套件的分散式檔案系統，就是把多臺異構的儲存伺服器的儲存空間整合起來給使用者提供統一的名稱空間。使用者訪問儲存資源的方式有很多，可以通過NFS，SMB，HTTP協議等訪問，還可以通過gluster本身提供的客戶端訪問。
GlusterFS是Scale-Out儲存解決方案Gluster的核心，它是一個開源的分散式檔案系統，具有強大的橫向擴充套件能力，通過擴充套件能夠支援數PB儲存容量和處理數千客戶端。GlusterFS藉助TCP/IP或InfiniBand RDMA網路將物理分佈的儲存資源聚集在一起，使用單一全域性名稱空間來管理資料。GlusterFS基於可堆疊的使用者空間設計，可為各種不同的資料負載提供優異的效能。
GlusterFS 適合大檔案還是小檔案儲存？彈性雜湊演算法和Stripe 資料分佈策略，移除了後設資料依賴，優化了資料分佈，提高資料訪問並行性，能夠大幅提高大檔案儲存的效能。對於小檔案，無後設資料服務設計解決了後設資料的問題。但GlusterFS 並沒有在I/O 方面作優化，在儲存伺服器底層檔案系統上仍然是大量小檔案，本地檔案系統後設資料訪問是一個瓶頸，資料分佈和並行性也無法充分發揮作用。因此，GlusterFS 適合儲存大檔案，小檔案效能較差，還存在很大優化空間。
GlusterFS 在企業中應用場景
理論和實踐上分析，GlusterFS目前主要適用大檔案儲存場景，對於小檔案尤其是海量小檔案，儲存效率和訪問效能都表現不佳。海量小檔案LOSF問題是工業界和學術界公認的難題，GlusterFS作為通用的分散式檔案系統，並沒有對小檔案作額外的優化措施，效能不好也是可以理解的。
Media − 文件、圖片、音訊、視訊
Shared storage − 雲端儲存、虛擬化儲存、HPC（高效能運算）
Big data − 日誌檔案、RFID（射頻識別）資料
1）GlusterFS儲存的幾個術語
Brick：GlusterFS中的儲存單元，通過是一個受信儲存池中的伺服器的一個匯出目錄。可以通過主機名和目錄名來標識，如'SERVER:EXPORT'。
Client：掛載了GlusterFS卷的裝置。
GFID：GlusterFS卷中的每個檔案或目錄都有一個唯一的128位的資料相關聯，其用於模擬inode
Namespace：每個Gluster卷都匯出單個ns作為POSIX的掛載點。
Node：一個擁有若干brick的裝置。
RDMA：遠端直接記憶體訪問，支援不通過雙方的OS進行直接記憶體訪問。
RRDNS：round robin DNS是一種通過DNS輪轉返回不同的裝置以進行負載均衡的方法
Self-heal：用於後臺執行檢測複本卷中檔案和目錄的不一致性並解決這些不一致。
Split-brain：腦裂
Volfile：Glusterfs程式的配置檔案，通常位於/var/lib/glusterd/vols/volname
Volume：一組bricks的邏輯集合
a）Trusted Storage Pool
• 一堆儲存節點的集合
• 通過一個節點“邀請”其他節點建立，這裡叫probe
• 成員可以動態加入，動態刪除
新增命令如下：
node1# gluster peer probe node2
刪除命令如下：
node1# gluster peer detach node3
2）Bricks
• Brick是一個節點和一個匯出目錄的集合，e.g. node1:/brick1
• Brick是底層的RAID或磁碟經XFS或ext4檔案系統格式化而來，所以繼承了檔案系統的限制
• 每個節點上的brick數是不限的
• 理想的狀況是，一個叢集的所有Brick大小都一樣。
3）Volumes
• Volume是brick的邏輯組合
• 建立時命名來識別
• Volume是一個可掛載的目錄
• 每個節點上的brick數是不變的,e.g.mount –t glusterfs www.std.com:test /mnt/gls
• 一個節點上的不同brick可以屬於不同的卷
• 支援如下種類：
a) 分散式卷
b) 條帶卷
c) 複製卷
d) 分散式複製卷
e) 條帶複製卷
f) 分散式條帶複製卷
3.1）分散式卷
• 檔案分佈存在不同的brick裡
• 目錄在每個brick裡都可見
• 單個brick失效會帶來資料丟失
• 無需額外後設資料伺服器
3.2）複製卷
• 同步複製所有的目錄和檔案
• 節點故障時保持資料高可用
• 事務性操作，保持一致性
• 有changelog
• 副本數任意定
3.3）分散式複製卷
• 最常見的一種模式
• 讀操作可以做到負載均衡
3.4）條帶卷
• 檔案切分成一個個的chunk，存放於不同的brick上
• 只建議在非常大的檔案時使用（比硬碟大小還大）
• Brick故障會導致資料丟失，建議和複製卷同時使用
• Chunks are files with holes – this helps in maintaining offset consistency.
2）GlusterFS無後設資料設計
後設資料是用來描述一個檔案或給定區塊在分散式檔案系統中所在的位置，簡而言之就是某個檔案或某個區塊儲存的位置。傳統分散式檔案系統大都會設定後設資料伺服器或者功能相近的管理伺服器，主要作用就是用來管理檔案與資料區塊之間的儲存位置關係。相較其他分散式檔案系統而言，GlusterFS並沒有集中或者分散式的後設資料的概念，取而代之的是彈性雜湊演算法。叢集中的任何伺服器和客戶端都可以利用雜湊演算法、路徑及檔名進行計算，就可以對資料進行定位，並執行讀寫訪問操作。
這種設計帶來的好處是極大的提高了擴充套件性，同時也提高了系統的效能和可靠性；另一顯著的特點是如果給定確定的檔名，查詢檔案位置會非常快。但是如果要列出檔案或者目錄，效能會大幅下降，因為列出檔案或者目錄時，需要查詢所在節點並對各節點中的資訊進行聚合。此時有後設資料服務的分散式檔案系統的查詢效率反而會提高許多。
3）GlusterFS伺服器間的部署
在之前的版本中伺服器間的關係是對等的，也就是說每個節點伺服器都掌握了叢集的配置資訊，這樣做的好處是每個節點度擁有節點的配置資訊，高度自治，所有資訊都可以在本地查詢。每個節點的資訊更新都會向其他節點通告，保證節點間資訊的一致性。但如果叢集規模較大，節點眾多時，資訊同步的效率就會下降，節點資訊的非一致性概率就會大大提高。因此GlusterFS未來的版本有向集中式管理變化的趨勢。
4）Gluster技術特點
GlusterFS在技術實現上與傳統儲存系統或現有其他分散式檔案系統有顯著不同之處，主要體現在如下幾個方面。
a）完全軟體實現（SoftwareOnly）
GlusterFS認為儲存是軟體問題，不能夠把使用者侷限於使用特定的供應商或硬體配置來解決。GlusterFS採用開放式設計，廣泛支援工業標準的儲存、網路和計算機裝置，而非與定製化的專用硬體裝置捆綁。對於商業客戶，GlusterFS可以以虛擬裝置的形式交付，也可以與虛擬機器容器打包，或者是公有云中部署的映像。開源社群中，GlusterFS被大量部署在基於廉價閒置硬體的各種作業系統上，構成集中統一的虛擬儲存資源池。簡言之，GlusterFS是開放的全軟體實現，完全獨立於硬體和作業系統。
b）完整的儲存作業系統棧（CompleteStorage Operating System Stack）
GlusterFS不僅提供了一個分散式檔案系統，而且還提供了許多其他重要的分散式功能，比如分散式記憶體管理、I/O排程、軟RAID和自我修復等。GlusterFS汲取了微核心架構的經驗教訓，借鑑了GNU/Hurd作業系統的設計思想，在使用者空間實現了完整的儲存作業系統棧。
c）使用者空間實現（User Space）
與傳統的檔案系統不同，GlusterFS在使用者空間實現，這使得其安裝和升級特別簡便。另外，這也極大降低了普通使用者基於原始碼修改GlusterFS的門檻，僅僅需要通用的C程式設計技能，而不需要特別的核心程式設計經驗。
d）模組化堆疊式架構（ModularStackable Architecture）
GlusterFS採用模組化、堆疊式的架構，可通過靈活的配置支援高度定製化的應用環境，比如大檔案儲存、海量小檔案儲存、雲端儲存、多傳輸協議應用等。每個功能以模組形式實現，然後以積木方式進行簡單的組合，即可實現複雜的功能。比如，Replicate模組可實現RAID1，Stripe模組可實現RAID0，通過兩者的組合可實現RAID10和RAID01，同時獲得高效能和高可性。
e）原始資料格式儲存（DataStored in Native Formats）
GlusterFS無後設資料服務設計（NoMetadata with the Elastic Hash Algorithm）以原始資料格式（如EXT3、EXT4、XFS、ZFS）儲存資料，並實現多種資料自動修復機制。因此，系統極具彈性，即使離線情形下檔案也可以通過其他標準工具進行訪問。如果使用者需要從GlusterFS中遷移資料，不需要作任何修改仍然可以完全使用這些資料。
對Scale-Out儲存系統而言，最大的挑戰之一就是記錄資料邏輯與物理位置的映像關係，即資料後設資料，可能還包括諸如屬性和訪問許可權等資訊。傳統分散式儲存系統使用集中式或分散式後設資料服務來維護後設資料，集中式後設資料服務會導致單點故障和效能瓶頸問題，而分散式後設資料服務存在效能負載和後設資料同步一致性問題。特別是對於海量小檔案的應用，後設資料問題是個非常大的挑戰。
GlusterFS獨特地採用無後設資料服務的設計，取而代之使用演算法來定位檔案，後設資料和資料沒有分離而是一起儲存。叢集中的所有儲存系統伺服器都可以智慧地對檔案資料分片進行定位，僅僅根據檔名和路徑並運用演算法即可，而不需要查詢索引或者其他伺服器。這使得資料訪問完全並行化，從而實現真正的線性效能擴充套件。無後設資料伺服器極大提高了GlusterFS的效能、可靠性和穩定性。
5）Glusterfs整體工作流程（即GlusterFS資料訪問流程）
a）首先是在客戶端， 使用者通過glusterfs的mount point 來讀寫資料， 對於使用者來說，叢集系統的存在對使用者是完全透明的，使用者感覺不到是操作本地系統還是遠端的叢集系統。
b）使用者的這個操作被遞交給 本地linux系統的VFS來處理。
c）VFS 將資料遞交給FUSE 核心檔案系統:在啟動 glusterfs 客戶端以前，需要想系統註冊一個實際的檔案系統FUSE,如上圖所示，該檔案系統與ext3在同一個層次上面， ext3 是對實際的磁碟進行處理， 而fuse 檔案系統則是將資料通過/dev/fuse 這個裝置檔案遞交給了glusterfs client端。所以， 我們可以將 fuse檔案系統理解為一個代理。
d）資料被fuse 遞交給Glusterfs client 後， client 對資料進行一些指定的處理（所謂的指定，是按照client 配置檔案據來進行的一系列處理， 我們在啟動glusterfs client 時需要指定這個檔案。
e）在glusterfs client的處理末端，通過網路將資料遞交給 Glusterfs Server，並且將資料寫入到伺服器所控制的儲存裝置上。
這樣， 整個資料流的處理就完成了。
GlusterFS客戶端訪問流程
當客戶端訪問GlusterFS儲存時，首先程式通過訪問掛載點的形式讀寫資料，對於使用者和程式而言，叢集檔案系統是透明的，使用者和程式根本感覺不到檔案系統是本地還是在遠端伺服器上。讀寫操作將會被交給VFS(Virtual File System)來處理，VFS會將請求交給FUSE核心模組，而FUSE又會通過裝置/dev/fuse將資料交給GlusterFS Client。最後經過GlusterFS Client的計算，並最終經過網路將請求或資料傳送到GlusterFS Server上。
6）GlusterFS叢集模式
GlusterFS分散式儲存叢集的模式只資料在叢集中的存放結構，類似於磁碟陣列中的級別。
a）分散式卷（Distributed Volume），預設模式，DHT
又稱雜湊卷，近似於RAID0，檔案沒有分片，檔案根據hash演算法寫入各個節點的硬碟上，優點是容量大，缺點是沒冗餘。
# gluster volume create test-volume server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp4
b）複製卷（Replicated Volume），複製模式，AFR
相當於raid1，複製的份數，決定叢集的大小，通常與分散式卷或者條帶卷組合使用，解決前兩種儲存卷的冗餘缺陷。缺點是磁碟利用率低。複本卷在建立時可指定複本的數量，通常為2或者3，複本在儲存時會在卷的不同brick上，因此有幾個複本就必須提供至少多個brick，當其中一臺伺服器失效後，可以從另一臺伺服器讀取資料，因此複製GlusterFS卷提高了資料可靠性的同事，還提供了資料冗餘的功能。
# gluster volume create test-volume replica 2 transport tcp server1:/exp1 server2:/exp2
避免腦裂，加入仲裁：
# gluster volume create replica 3 arbiter 1 host1:brick1 host2:brick2 host3:brick3
c）分散式複製卷（Distributed Replicated Volume），最少需要4臺伺服器。
# gluster volume create test-volume replica 2 transport tcp server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp4
d）條帶卷（Striped Volume）
相當於raid0，檔案是分片均勻寫在各個節點的硬碟上的，優點是分散式讀寫，效能整體較好。缺點是沒冗餘，分片隨機讀寫可能會導致硬碟IOPS飽和。
# gluster volume create test-volume stripe 2 transport tcp server1:/exp1 server2:/exp2
e）分散式條帶卷（Distributed Striped Volume），最少需要4臺伺服器。
當單個檔案的體型十分巨大，客戶端數量更多時，條帶卷已經無法滿足需求，此時將分散式與條帶化結合起來是一個比較好的選擇。其效能與伺服器數量有關。
# gluster volume create test-volume stripe 4 transport tcp server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp4 server5:/exp5 server6:/exp6 server7:/exp7 server8:/exp8
7）Glusterfs儲存特點
a）擴充套件性和高效能
GlusterFS利用雙重特性來提供幾TB至數PB的高擴充套件儲存解決方案。Scale-Out架構允許通過簡單地增加資源來提高儲存容量和效能，磁碟、計算和I/O資源都可以獨立增加，支援10GbE和InfiniBand等高速網路互聯。Gluster彈性雜湊（Elastic Hash）解除了GlusterFS對後設資料伺服器的需求，消除了單點故障和效能瓶頸，真正實現了並行化資料訪問。
b）高可用性
GlusterFS可以對檔案進行自動複製，如映象或多次複製，從而確保資料總是可以訪問，甚至是在硬體故障的情況下也能正常訪問。自我修復功能能夠把資料恢復到正確的狀態，而且修復是以增量的方式在後臺執行，幾乎不會產生效能負載。GlusterFS沒有設計自己的私有資料檔案格式，而是採用作業系統中主流標準的磁碟檔案系統（如EXT3、ZFS）來儲存檔案，因此資料可以使用各種標準工具進行復制和訪問。
c）全域性統一名稱空間
全域性統一名稱空間將磁碟和記憶體資源聚整合一個單一的虛擬儲存池，對上層使用者和應用遮蔽了底層的物理硬體。儲存資源可以根據需要在虛擬儲存池中進行彈性擴充套件，比如擴容或收縮。當儲存虛擬機器映像時，儲存的虛擬映像檔案沒有數量限制，成千虛擬機器均通過單一掛載點進行資料共享。虛擬機器I/O可在名稱空間內的所有伺服器上自動進行負載均衡，消除了SAN環境中經常發生的訪問熱點和效能瓶頸問題。
d）彈性雜湊演算法
GlusterFS採用彈性雜湊演算法在儲存池中定位資料，而不是採用集中式或分散式後設資料伺服器索引。在其他的Scale-Out儲存系統中，後設資料伺服器通常會導致I/O效能瓶頸和單點故障問題。GlusterFS中，所有在Scale-Out儲存配置中的儲存系統都可以智慧地定位任意資料分片，不需要檢視索引或者向其他伺服器查詢。這種設計機制完全並行化了資料訪問，實現了真正的線性效能擴充套件。
e）彈性卷管理
資料儲存在邏輯卷中，邏輯卷可以從虛擬化的物理儲存池進行獨立邏輯劃分而得到。儲存伺服器可以線上進行增加和移除，不會導致應用中斷。邏輯卷可以在所有配置伺服器中增長和縮減，可以在不同伺服器遷移進行容量均衡，或者增加和移除系統，這些操作都可線上進行。檔案系統配置更改也可以實時線上進行並應用，從而可以適應工作負載條件變化或線上效能調優。
f）基於標準協議
Gluster儲存服務支援NFS, CIFS, HTTP, FTP以及Gluster原生協議，完全與POSIX標準相容。現有應用程式不需要作任何修改或使用專用API，就可以對Gluster中的資料進行訪問。這在公有云環境中部署Gluster時非常有用，Gluster對雲服務提供商專用API進行抽象，然後提供標準POSIX介面。
8）GlusterFS功能簡介
8.1）基本管理功能
GlusterFS服務管理：啟動、停止、重啟服務；
TrustedStorage Pools管理：增加或刪除peer；
Volume管理：增加捲、啟動卷、停止卷；
上述這些基本的管理功能不再做介紹。
8.2）TuningVolume Options（調整卷配置）
GlustreFS提供了45項配置用來調整Volume屬性，包括埠、cache、安全、儲存空間、自愈、日誌、擴充套件性、通訊協議、效能等配置項。使用者可以通過gluster volume info命令來檢視自定義配置項。
8.3）ConfiguringTransport Types for Volume（配置傳輸型別）
建立卷的時候，可以選擇client與brick的通訊協議。
也可以通過"gluster volume set volnameconfig.transport tcp,rdma OR tcp OR rdma"命令更改通訊協議，需要注意的在更改通訊協議前，必須先停止volume。
預設情況是TCP，根據部署場景可選擇RDMA或RDMA+TCP組合，而選擇RDMA協議需要相應硬體的支援。
8.4）ExpandingVolumes（擴容）
GlusterFS叢集的擴容就是通過增加volume來實現，通過"glustervolume add-brick"命令增加捲。
注意，擴容複製卷的時候，必須同時增加捲的數量是replica的倍數。例如replica 2的叢集擴容，需要同時增加2個volume；replica3的叢集擴容，需要同時增加3個volume。
8.5）ShrinkingVolumes（縮容）
叢集縮減儲存空間通過刪除卷的“glustervolume remove-brick”命令實現，刪除卷的命令執行後，GlustreFS會啟動資料遷移，若遷移的資料較大，遷移過程將耗時較長，可能通過命令觀察遷移狀態。
8.6）Replacefaulty brick（更換壞塊）
用好的brick替換故障的brick。
使用方法如下："glustervolume replace-brick test-volume server3:/exp3 server5:/exp5 commit force"，將test-volume卷中的server3:/exp3故障brick替換掉。
8.7）RebalancingVolumes（負載調整）
擴容或縮容卷，叢集中可能會出現不同卷的儲存利用率較大的不均衡的現象。通過Rebalancing機制，在後臺以人工方式來執行負載平滑，將進行檔案移動和重新分佈，此後所有儲存伺服器都會均會被排程。為了便於控制管理，rebalance操作分為兩個階段進行實際執行，即FixLayout和MigrateData。
a）FixLayout：修復layout以使得新舊目錄下新建檔案可以在新增節點上分佈上。
b）MigrateData：新增或縮減節點後，在卷下所有節點上進行容量負載平滑。為了提高rebalance效率，通常在執行此操作前先執行FixLayout。
8.8）TriggeringSelf-Heal on Replicate（檔案自愈）
在複製卷中，若出現複本間檔案不同步的情況，系統每十分鐘會自動啟動Self-Heal。
也可以主動執行"glustervolume heal"命令觸發Self-Heal，通過"gluster volume heal info"可以檢視需要heal的檔案列表。
在healing過程中，可以通過"gluster volume heal info healed"檢視已修復檔案的列表；
通過"gluster volume heal info failed"檢視修復失敗的檔案列表。
8.9）Geo-replication（異地備份）
異地備份可以提供資料的災難恢復。以本地叢集作為主儲存，異地儲存為備份，通過區域網或網際網路持續、增量、非同步備份資料。
使用"gluster volume geo-replication"相關的命令實現異地備份建立管理。
8.10）Quota（限額管理）
GlusterFS提供目錄或卷的儲存使用空間的限制設定功能。通過目錄限額可以實現對使用者按儲存容量計費的功能。
使用方法為："gluster volume quota"
8.11）VolumeSnapshots（卷快照）
卷快照功能用於卷的備份和恢復，在非複製卷的應用場景，通過卷快照實現資料冗餘備份。
8.12）MonitoringWorkload（效能監控）
監控每一個brick檔案操作的IO效能，主要監控開啟fd的數量和最大fd數量、最大讀檔案呼叫數、最大寫檔案呼叫數、最大開啟目錄呼叫數、brick讀效能、brcik寫效能等。
使用方法："gluster volume profile"
分析GlusterFS分散式檔案系統的缺點
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重新整理週期到來前可能讀到非最新的資料，即無法保證資料的強一致性。因此實際應用時需要在效能和資料一致性之間進行折中，如果需要更高的資料一致性，就得調小快取重新整理週期，甚至禁用讀快取；反之，是可以把快取週期調大一點，以提升讀效能。
==============GlusterFS分散式系統維護管理手冊===================
1）管理說明
在解釋系統管理時會提供例項，首先提供一個環境說明。 系統節點： IP 別名 Brick 192.168.2.100 server0 /mnt/sdb1 /mnt/sdc1 /mnt/sdd1 192.168.2.101 server1 /mnt/sdb1 /mnt/sdc1 /mnt/sdd1 192.168.2.102 server2 /mnt/sdb1 /mnt/sdc1 /mnt/sdd1 建立了三個節點，並每臺虛擬機器 mount 三塊磁碟作為 Brick 使用，每個 brick 分配了 30G 的虛擬容量。 例項約定 AFR 卷名： afr_vol DHT 卷名： dht_vol Stripe 卷名： str_vol 客戶端掛載點： /mnt/gluster
2）系統部署
2.1) 在每個節點上啟動glusterd服務
[root@localhost ~]# service glusterd start
2.2) 新增節點到儲存池，在其中一個節點上操作 ，如 server0
[root@localhost ~]# gluster peer probe server1
[root@localhost ~]# gluster peer probe server2
//可以使用 gluster peer status 檢視當前有多少個節點，顯示不包括該節點
2.3) 建立系統卷, 部署最常見的分散式卷，在 server0上操作
[root@localhost ~]# gluster volume create dht_vol 192.168.2.{100,101,102}:/mnt/sdb1
//分別使用 server0/1/2 的磁碟掛載目錄/mnt/sdb1 作為 brick
2.4) 啟動系統卷，在 server0上操作
[root@localhost ~]# gluster volume start dht_vol
2.5) 掛載客戶端，例如在server2上
[root@localhost ~]# mount.glusterfs server0:/dht_vol /mnt/gluster
//將系統卷掛載到 server2 上的/mnt/gluster 目錄下就可以正常使用了。該目錄聚合了三個不同主機上的三塊磁碟。
//從啟動服務到提供全域性名字空間，整個部署流程如上。
3）基本系統管理
3.1）節點管理
# gluster peer command 1）節點狀態 [root@localhost ~]# gluster peer status //在serser0上操作，只能看到其他節點與 server0 的連線狀態 Number of Peers: 2 Hostname: server1 Uuid: 5e987bda-16dd-43c2-835b-08b7d55e94e5 State: Peer in Cluster (Connected) Hostname: server2 Uuid: 1e0ca3aa-9ef7-4f66-8f15-cbc348f29ff7 State: Peer in Cluster (Connected) 2）新增節點 [root@localhost ~]# gluster peer probe HOSTNAME #gluster peer probe server2 //將server2新增到儲存池中 3）刪除節點 [root@localhost ~]# gluster peer detach HOSTNAME [root@localhost ~]# gluster peer detach server2 //將server2從儲存池中移除 //移除節點時，需要確保該節點上沒有 brick ，需要提前將 brick 移除
3.2）卷管理
1）建立卷
[root@localhost ~]# gluster volume create NEW-VOLNAME [transport [tcp | rdma | tcp,rdma]]
NEW-BRICK...
-------------建立分散式卷(DHT)-------------
[root@localhost ~]# gluster volume create dht_vol 192.168.2.{100,101,102}:/mnt/sdb1
//DHT 卷將資料以雜湊計算方式分佈到各個 brick 上，資料是以檔案為單位存取，基本達到分佈均衡，提供的容量和為各個 brick 的總和。
-------------建立副本卷(AFR)-------------
[root@localhost ~]# gluster volume create afr_vol replica 3 192.168.2.{100,101,102}:/mnt/sdb1
//AFR 卷提供資料副本，副本數為 replica，即每個檔案儲存 replica 份數，檔案不分割，以檔案為單位儲存；副本數需要等於brick數；當brick數是副本的倍數時，則自動變化為
Replicated-Distributed卷。
[root@localhost ~]# gluster volume create afr_vol replica 2 192.168.2.{100,101,102}:/mnt/sdb1 192.168.2.{100,101,102}:/mnt/sdc1
//每兩個 brick 組成一組，每組兩個副本，檔案又以 DHT 分佈在三個組上，是副本卷與分散式卷的組合。
-------------建立條帶化卷(Stripe)-------------
[root@localhost ~]# gluster volume create str_vol stripe 3 192.168.2.{100,101,102}:/mnt/sdb1
//Stripe 卷類似 RAID0，將資料條帶化，分佈在不同的 brick，該方式將檔案分塊，將檔案分成stripe塊，分別進行儲存，在大檔案讀取時有優勢；stripe 需要等於 brick 數；當 brick 數等於 stripe 數的倍數時，則自動變化為 Stripe-Distributed 卷。
[root@localhost ~]# gluster volume create str_vol stripe 3 192.168.2.{100,101,102}:/mnt/sdb1 192.168.2.{100,101,102}:/mnt/sdc1
//沒三個 brick 組成一個組，每組三個 brick，檔案以 DHT 分佈在兩個組中，每個組中將檔案條帶化成 3 塊。
-------------建立Replicated-Stripe-Distributed卷-------------
[root@localhost ~]# gluster volume create str_afr_dht_vol stripe 2 replica 2 192.168.2.{100,101,102}:/mnt/sdb1 192.168.2.{100,101,102}:/mnt/sdc1 192.168.2.{100,101}:/mnt/sdd1
//使用8個 brick 建立一個組合卷，即 brick 數是 stripe*replica 的倍數，則建立三種基本卷的組合卷，若剛好等於 stripe*replica 則為 stripe-Distrbuted 卷。
2）卷 資訊
[root@localhost ~]# gluster volume info
//該命令能夠檢視儲存池中的當前卷的資訊，包括卷方式、包涵的 brick、卷的當前狀態、卷名及 UUID 等。
3）卷 狀態
[root@localhost ~]# gluster volume status
//該命令能夠檢視當前卷的狀態，包括其中各個 brick 的狀態，NFS 的服務狀態及當前 task執行情況，和一些系統設定狀態等。
4）啟動/ 停止 卷
[root@localhost ~]# gluster volume start/stop VOLNAME
//將建立的卷啟動，才能進行客戶端掛載；stop 能夠將系統卷停止，無法使用；此外 gluster未提供 restart 的重啟命令
5）刪除卷
[root@localhost ~]# gluster volume delete VOLNAME
//刪除卷操作能夠將整個卷刪除，操作前提是需要將卷先停止
3.3）Brick 管理
1）新增 Brick 若是副本卷，則一次新增的 Bricks 數是 replica 的整數倍；stripe 具有同樣的要求。 # gluster volume add-brick VOLNAME NEW-BRICK # gluster volume add-brick dht_vol server3:/mnt/sdc1 //新增 server3 上的/mnt/sdc1 到卷 dht_vol 上。 2）移除 Brick 若是副本卷，則移除的 Bricks 數是 replica 的整數倍；stripe 具有同樣的要求。 [root@localhost ~]# gluster volume remove-brick VOLNAME BRICK start/status/commit [root@localhost ~]# gluster volume remove-brick dht_vol server3:/mnt/sdc1 start //GlusterFS_3.4.1 版本在執行移除 Brick 的時候會將資料遷移到其他可用的 Brick 上，當資料遷移結束之後才將 Brick 移除。執行 start 命令，開始遷移資料，正常移除 Brick。 [root@localhost ~]# gluster volume remove-brick dht_vol server3:/mnt/sdc1 status //在執行開始移除 task 之後，可以使用 status 命令進行 task 狀態檢視。 [root@localhost ~]# gluster volume remove-brick dht_vol server3:/mnt/sdc1 commit //使用 commit 命令執行 Brick 移除，則不會進行資料遷移而直接刪除 Brick，符合不需要資料遷移的使用者需求。 PS ：系統的擴容及縮容可以通過如上節點管理、Brick 管理組合達到目的。 (1) 擴容時，可以先增加系統節點，然後 新增新增節點上的 Brick 即可。 (2) 縮容時，先移除 Brick ，然後再。 進行節點刪除則達到縮容的目的，且可以保證資料不丟失。 3）替換 Brick [root@localhost ~]# gluster volume replace-brick VOLNAME BRICKNEW-BRICK start/pause/abort/status/commit [root@localhost ~]# gluster volume replace-brick dht_vol server0:/mnt/sdb1 server0:/mnt/sdc1 start //如上，執行 replcace-brick 卷替換啟動命令，使用 start 啟動命令後，開始將原始 Brick 的資料遷移到即將需要替換的 Brick 上。 [root@localhost ~]# gluster volume replace-brick dht_vol server0:/mnt/sdb1 server0:/mnt/sdc1 status //在資料遷移的過程中，可以檢視替換任務是否完成。 [root@localhost ~]# gluster volume replace-brick dht_vol server0:/mnt/sdb1 server0:/mnt/sdc1 abort //在資料遷移的過程中，可以執行 abort 命令終止 Brick 替換。 [root@localhost ~]# gluster volume replace-brick dht_vol server0:/mnt/sdb1 server0:/mnt/sdc1 commit //在資料遷移結束之後，執行 commit 命令結束任務，則進行Brick替換。使用volume info命令可以檢視到 Brick 已經被替換。
4）GlusterFS系統擴充套件維護
4.1）系統配額
1）開啟/關閉系統配額 [root@localhost ~]# gluster volume quota VOLNAME enable/disable //在使用系統配額功能時，需要使用 enable 將其開啟；disable 為關閉配額功能命令。 2）設定( 重置) 目錄配額 [root@localhost ~]# gluster volume quota VOLNAME limit-usage /directory limit-value [root@localhost ~]# gluster volume quota dht_vol limit-usage /quota 10GB //如上，設定 dht_vol 卷下的 quota 子目錄的限額為 10GB。 PS：這個目錄是以系統掛載目錄為根目錄”/”,所以/quota 即客戶端掛載目錄下的子目錄 quota 3）配額檢視 [root@localhost ~]# gluster volume quota VOLNAME list [root@localhost ~]# gluster volume quota VOLNAME list /directory name //可以使用如上兩個命令進行系統卷的配額檢視，第一個命令檢視目的卷的所有配額設定，第二個命令則是執行目錄進行檢視。 //可以顯示配額大小及當前使用容量，若無使用容量(最小 0KB)則說明設定的目錄可能是錯誤的(不存在)。
4.2）地域複製（geo-replication）
# gluster volume geo-replication MASTER SLAVE start/status/stop 地域複製 是系統提供的災備功能，能夠將系統的全部資料進行非同步的增量備份到另外的磁碟中。 [root@localhost ~]# gluster volume geo-replication dht_vol 192.168.2.104:/mnt/sdb1 start //如上，開始執行將 dht_vol 卷的所有內容備份到 2.104 下的/mnt/sdb1 中的 task，需要注意的是，這個備份目標不能是系統中的 Brick。
4.3）I/O 資訊檢視
Profile Command 提供介面檢視一個卷中的每一個brick的IO資訊。 [root@localhost ~]# gluster volume profile VOLNAME start //啟動 profiling，之後則可以進行 IO 資訊檢視 [root@localhost ~]# gluster volume profile VOLNAME info //檢視 IO 資訊，可以檢視到每一個 Brick 的 IO 資訊 [root@localhost ~]# gluster volume profile VOLNAME stop //檢視結束之後關閉 profiling 功能
4.4）Top 監控
Top command 允許你檢視bricks的效能例如：read, write, file open calls, file read calls, file write calls, directory open calls, and directory real calls所有的檢視都可以設定 top數，預設100 [root@localhost ~]# gluster volume top VOLNAME open [brick BRICK-NAME] [list-cnt cnt] //檢視開啟的 fd [root@localhost ~]# gluster volume top VOLNAME read [brick BRICK-NAME] [list-cnt cnt] //檢視呼叫次數最多的讀呼叫 [root@localhost ~]# gluster volume top VOLNAME write [brick BRICK-NAME] [list-cnt cnt] //檢視呼叫次數最多的寫呼叫 [root@localhost ~]# gluster volume top VOLNAME opendir [brick BRICK-NAME] [list-cnt cnt] [root@localhost ~]# gluster volume top VOLNAME readdir [brick BRICK-NAME] [list-cnt cnt] //檢視次數最多的目錄呼叫 [root@localhost ~]# gluster volume top VOLNAME read-perf [bs blk-size count count] [brick BRICK-NAME] [list-cnt] //檢視每個 Brick 的讀效能 [root@localhost ~]# gluster volume top VOLNAME write-perf [bs blk-size count count] [brick BRICK-NAME] [list-cnt cnt] //檢視每個 Brick 的寫效能