分布式文件系統
分布式文件系統（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）管理說明
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
在解釋系統管理時會提供實例，首先提供一個環境說明。
系統節點：
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）系統部署
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
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）節點管理
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
# 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
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）
|
1
2
3
4
5
|
# 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 信息查看
|
1
2
3
4
5
6
7
8
9
10
|
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 監控
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
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 的寫性能
|