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)儲存空間不足,需要更大容量的儲存。
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 |
|
2)系統部署
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
3)基本系統管理
3.1)節點管理
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
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 |
|
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 |
|
4)GlusterFS系統擴充套件維護
4.1)系統配額
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
4.2)地域複製(geo-replication)
1 2 3 4 5 |
|
4.3)I/O 資訊檢視
1 2 3 4 5 6 7 8 9 10 |
|
4.4)Top 監控
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|