GlusterFS分佈式存儲學習筆記

 

分佈式文件系統

分佈式文件系統（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）以原始數據格式（如EXT三、EXT四、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沒有設計本身的私有數據文件格式，而是採用操做系統中主流標準的磁盤文件系統（如EXT三、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以原始數據格式（如EXT四、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 的寫性能