Gluster ABC

 

(可以直接轉載 註明出處 有ppt 和pdf 如有需要請留言)

 

 

前言

Glusterfs 是一個只需要軟件的高效 可擴展 集中化管理的分佈式存儲系統。可以用於公有云,私有云環境。
 這裏就說企業私有云,公有云是收費的。
 對於爲創建一個靈活,經濟,表現出色並且高效的分佈式存儲爲前提的私有云環境,Glusterfs 提供了相當優秀的解決方案。他的好處有:
 高效的本地和遠程數據備份
 對於存儲擴展只需要線性開銷
 快速部署
 雲共享
 POSIX的語義( 應用不需要修改直接可用)
 免費
 靈活易擴展
Gluster提供企業 將物理存儲變成虛擬化,標準化 按需調整的分佈式存儲 ,就像使用本地盤一樣方便。

 

 

 

Glusterfs的特性

擴展性和表現
 GlusterFS 通過改變一系列的組合特徵來推動TB 到PB數據量的擴展。規模擴展的結構設計允許根本按需增加資源。磁盤,節點,網絡都可以被獨立的添加並且支持更高的網絡(10GB以上如InfiniBand )。Gluster的彈性哈希算法移除了原數據服務器。

全局命名空間
 獨一無二的命令空間用來整合磁盤和資源成爲一個簡單的池。存儲資源可以在分佈式存儲中按需彈性的增加和減少。比如作爲存儲的虛擬機可以映射沒有數目限制的鏡像,並且一個掛載點可以被上千個虛擬機共享。 虛擬機的IO吞吐可以動態的做到負載均衡 檢測熱點和瓶頸在SAN環境中顯得尤爲重要。
 
 彈性哈希算法
 比起使用一個集中的分佈式元數據索引服務器。Glusterfs 使用了一個彈性的hash算法用來定位分佈式存儲中的具體數據。 通常元數據服務器是一個公共的IO資源瓶頸 並且在其超大的存儲系統中顯得很脆弱。Glusterfs 可以智能的定位數據塊而不用通過另外一臺服務器查找 . 而從實現全並行化的數據進入達到線性的擴展表現。
 
彈性行卷管理
 數據被存儲在來自硬件或者其他邏輯分區的抽象邏輯卷中。就算數據服務在線也不需要中斷上層的應用,存儲服務器就可以增加或者減少個數 。卷組也可以在運行過程中增加或者減少空間 或者 在分佈式存儲的配置中遷移達到負載平衡。文件系統的配置也可以在運行的時候立刻改變以適應負載條件變化,從而達到在線性能調整。
 
協議支持
 Glusterfs 服務器支持NFS和私有協議 ,也包括CIFS HTTP FTP. 同時Glusterfs 完全遵從Posix 標誌,實現數據操作 不需要任何私有的API 這樣現在有系統完全不需要修改就可以直接運行在雲計算的環境中。 這尤其有用當你部署glusterfs的時候,因爲他提供了標準Posix接口。而Hadoop 卻是私有API,需要用其提供的類庫來編寫應用代碼。


管理磁盤配額
 
 在Glusterfs 中目錄配額允許你設置磁盤空間限制根據目錄和卷組。分佈式存儲管理員 可以在目錄和卷組基本 控制磁盤的使用率
 注意 只有硬件限制被支持 ,這個限制不能被超過或者企圖使用更多的塊和inode節點。超過的設置將會失敗。當然系統管理員可以監控資源的使用限制。
 
卷的級別和目錄等級

 Glusterfs 是一個開源的分佈式文件系統,可以處理 PB級別的數據和爲上千的客戶端同時服務。 Glusterfs 可以在TCP/IP RDMA等網絡上搭建集羣,整合磁盤和內存資源 並且把所有的數據通過一個全局命令空間管理。Glusterfs基於棧結構化的用戶空間設計,從而在不同的負荷下都有優異的表現。

雲備份(Geo-replication)

Glusterfs 提供了 一種從一個網絡域到另一個網絡域 :連續的 異步的 和增量的複製服務。
可以使用Glusterfs 在自己的存儲環境中建立數據冗餘,應對災難恢復 。

Glusterfs 使用了 “主-從” 模式, 在下面的角色之間完成數據複製 鏡像重建
主:Glusterfs 卷組
從:備份的Glusterfs 卷組或者一個簡單的掛載點(甚至可以不用安裝glusterfs)

 
 
Geo-replication的 缺點
 
同步未完成

 描述: Glusterfs 的GEO 未完成數據同步。
 解決: 你可以增強 一個數據完成的同步通過擦除下標並且重啓


虛擬的雲計算環境

 GlusterFS 被設計用來爲今天的高性能 虛擬化的雲計算環境服務。
 傳統數據中心隨着擴大和減小都要按需租賃。而Glusterfs 把雲計算的能力整合到了自己的結構核心中, 並且提供了本地的 NFS 協議支持。
 
 
 每一個GlusterFS 模塊 都被當作"卷組"對待。 GlusterFS 更進一步的增加了彈性的卷組管理能力(後臺服務進程) 和控制檯管理(gluster 命令行接口) 。 通過使用彈性的卷組管理, 管理員可以動態的增加 擴展 減少 和遷移下面的組卷。 命令行接口額外的提供了一個交互式的Shell界面 可以配合腳本實現合適的自動化工作。
 
GlusterFS 管理介紹
  GlusterFS 提供一個簡單的命令行工具 作爲Gluster的控制檯管理,這樣可以簡化配置和管理你的分佈式存儲環境。 Gluster 控制檯提供了類似於LVM 的那種命令行接口,但是它是跨存儲服務器的。你可以在線使用,不論卷組是否被掛載或者使用。
 通過使用Gluster 控制檯界面 ,管理員可以隨時創建新的卷組, 啓動卷組, 停止卷組。 管理員還是增加 存儲塊 到卷組裏面,或者移除已經有的存儲塊 。甚至包括解釋器 的設置。
 Gluster在多個Gluster服務器之間 動態的同步 卷組配置信息 ,管理員同樣可以使用提供的命令來創建腳本做到這些,同樣使用命令作爲API 來允許整合第三方的應用。


創建信任存儲池
 
 在配置GlusterFS卷組之前你需要創建一個性能分佈式存儲池 它由很多節點組成,然後再由他們構成卷組。一個分佈式存儲池可以看作一組信任的存儲節點。 當你啓動一個節點, 存儲池就只包含那個節點。 然後通過增加節點來擴充這個存儲池 ,你可以使用 'probe ' 命令來加入多個節點
注意:GlusterFS 服務只能運行在你要加入的那些節點服務器上。

配置GlusterFS卷組
 
配置分佈式卷組
 
 分佈式卷組 通過在集羣節點上分佈文件, 你可以使用分佈式卷組在歸檔環境中隨時調整存儲規模,短暫的失去響應是可以接受的。
 注意: 對於分佈式卷組磁盤失敗可能導致一系列的數據丟失,因爲目錄內容在整個集羣中是隨機分佈式的。
 
配置分佈式拷貝卷組
 
 分佈式拷貝卷組 複製數據在2個或者多個集羣節點之間, 你可以在需要高效和可靠的環境中,使用分佈式拷貝卷組。在大多數環境中,分佈式拷貝卷組同樣提供了增強的讀性能。
 
配置分佈式條帶化卷組
 
 分佈式條帶化卷組 可以把數據按條帶的保存在集羣中的多個節點上,爲了能有好的效果,你可以使用分佈式條帶化卷組 但僅僅在需要高併發且對象是大文件的情況下。

注意: Gluster 建議設置  rpc-auth-allow-insecure  = ON 如果卷組中有太多的 存儲塊 或者有很多系統服務已經佔有了特權端口(1024) 。只要你的部屬需要就請使用這個選項。


配置Gluster 解釋器
 
解釋器 默認選項 有效的值
服務器端  
鎖 trace off On / Off
讀寫線程 thread-count 16 1 to 64
 idle-time 1 
卷組標記 volume-uuid UUID of the volume 
 timestamp-file path 
 xtime off On / Off
 quota off On / Off
磁盤狀態 dump-fd-stats off On / Off
 latency-measurement off On / Off
 count-fop-hits off On / Off
 log-level NONE DEBUG, TRACE, NONE, WARNING, ERROR, CRITICAL
客戶端  
延遲寫 flush-behind on On / Off
 cache-size/window-size 1MB 512 KB to 1 GB
 disable-for-first-nbytes 0 0 to 1 MB
 enable-O_SYNC disable Enable / Disable
 enable-trickling-writes on On / Off
預讀 force-atime-update false True / False
 page-count 4 1 to 16
IO操作緩存 priority 1 
 cache-timeout/force-revalidate-timeout 1 sec 0 sec to 60 secs
 cache-size 32 MB 4 MB to 6 GB
 min-file-size 0 
 max-file-size 1 Limited by the underlying File System
讀取緩存 priority 1 cache-size 128 MB 0 KB to 6 GB
 cache-timeout 1 1 sec to 60 secs
 max-file-size 64 KB 0 KB to 1 MB

分析 GlusterFS負載
 使用GlusterFS卷組 的‘TOP’和 ‘Profile’命令可以監控不同的負載,據此你可以計劃和改變你的GlusterFS卷組達到更好的表現。還可以查看和找到卷組中每一個存儲塊出熱點和瓶頸。

內部的實現:

 

可以想象。 任何區分通過本地原數據來區分數據的設計都和表現和可靠性互相制約。
因此gluster設計了一個不需要原數據的系統 ,無論是集中式還是分佈式。

Gluster 通過算法定位數據, 僅僅通過路徑名和文件名。在Gluster存儲平臺中任何需要讀取數據的存儲系統節點和客戶端訪問文件時都表現爲通過一個算法操作來獲得文件屬主。換言之沒有原數據的必要,因爲文件路徑可以被獨立的確定。

這個算法稱之爲 彈性哈希算法。 它是Gluster獨一無二的優勢。對於這個算法的解太複雜了。就舉一個簡單的例子吧。

 

 


在真實的環境中, 槽糕的事情經常發生 :磁盤壞道, 資源耗盡 文件需要被重新分佈 等等。

Gluster 解決這些挑戰 通過:

 1 設置一個非常大數目的虛擬卷組
 2 使用哈希算法來指定文件對應的虛擬卷組
 3 使用一個獨立的進程指定虛擬卷組到多個物理磁盤

因此 當磁盤或者節點被增加或者減少,算法本身不需要改變。 同時,虛擬卷組可以隨時被遷移或者安排到一個新的物理位置

 

模塊化棧化架構
 
 Gluster 設計爲模塊化和棧化的架構。 對於大文件,多數目文件,小片文件等等不同的分佈式存儲場景, Gluster都可以簡單的做到特定配置包含需要的模塊。
 爲了穩定性的原因, 一些配置可以在系統使用中不會生效(比如,一個人希望移除一個複製功能,但是高可用的環境中需要這個功能)。

 


 
 
 彈性卷組管理
 
  因爲用一個彈性的哈希算法指定文件到對應的邏輯卷。可能有一個疑問“Gluster是如何安排邏輯捲到物理卷的”在Gluster中,卷管理是非常彈性化的, 存儲的卷組對於底層可增長減少遷移的硬件是抽象的。 存儲系統可以動態增加或者移除數據。運行中文件系統配置的改變是可行的。
 

 
重命名和移除文件
 
 如果一個文件被改名字了,那麼Gluster的哈希算法肯定會產生不同的值 這樣就導致文件被安排在不同的邏輯卷組上, 它自身就可以被存儲在了不同的物理設備上。
 因爲文件的擴大重寫或者移動 通常不是一個實時操作, Gluster解決以上問題,通過在文件被重名命的時候創建一個文件連接,這樣客戶端可以查找新名字 然後被重新定向到原始的磁盤位置, Gluster在背後會偷偷的把文件遷移過去,完成了再把重定向到的連接除去。
高可用
 
 通常的說, Gluster建議使用 鏡像(2,3 或者更多)來確保高可用 。在這種情況下 每一個存儲節點 都被複制到另一個存儲節點,而這一切都是異步的。這個策略的好處就是可以做到錯誤允許。單點失敗是對Gluster的客戶端來說完全是透明的。 另外讀者可以快讀的切換在多個鏡像中。GlusterFS 可以支持沒有數量限制的鏡像。當彈性哈希算法安排文件到獨一無二的邏輯卷時 Gluster 確保每個文件都被保存到爲至少2個以上的節點中 。沒有分佈式的鏡像也是可以的 只要二個節點就能完成。



 
 .


疑問解答:

FUSE 模塊的表現如何?

Gluster反饋給linux社區的一種方式就是維護內核FUSE模塊 ,有專門的工程師在做着一塊工作,所以問題不大。我們裏面有人。

網絡級別的Raid 5 分佈式冗餘

在Gluster的不同版本之間升級有問題嗎? 在線呢?

更新不同的Gluster版本是非常容易的, 而且對於複製過的卷組來說沒有延遲,如果你沒有複製的卷組,那麼會有一點點的時延 。

Gluster有API支持嗎?
 現在還是用命令的,不過很快就有了 叫做 RESTfulAPI。


Gluster的限制是什麼?
  因爲沒有中心化的數據存儲,沒有原數據並且只在文件基本操作 理論上沒有什麼限制。
但是在真實的服務器和IP管理上 ,集羣對於大多數節點 只能有250個服務器能加入一個簡單的卷組。如果你有1000個節點 100PB的集羣可以給告訴 Gluster測試,請告訴他們,他們會給你一個Gluster的衣服和水杯。。。


有32位支持嗎? 有 GUI麼? 雲備份可以支持壓縮麼
 
  3.2之後就沒有可用的3.2版本了, 以後會有GUI, 以後會有,現在是增量複製,所以其實很快。
 
 
當雲備份(geo-replication)通過管道立刻傳遞數據的話,會發生什麼?

 

 .
 
 

 
 
總 結

 
 Gluster 可以用於需要通過數據冗餘來實現數據備份的分佈式文件系統。
通過不同機架 ,不同地域的主機配合形成 雲存儲備份(geo-replication)。
 
 
 由於既提供了卷組級別的備份,又提供了主機級別的備份。 這樣可以根據客戶的需要和提供的方案來決定數據備份的組合方式。
 

 
 
 同時可以在 lvm 之上搭建 gluster 然後將GFS提供的卷組,通過Samba NFS ISCSI 等主機文件傳輸協議提供給win os 做磁盤文件夾映射。
 
 
 

 
 Gluter 並不提供真正意義上的動態的主機切換 ,和負載均衡 一切都依賴於管理員通過命令實現。 而且只提供了磁盤狀態,並不能考慮網絡負載 CPU 內存負載 這一切很大程度是因爲自身的 彈性Hash算法 和必須遵守 Poxis 協議。 所以有得必有失。
 
 鑑於此 gluster 不太適合用於做web存儲服務器,比起Hadoop  因爲不能做到動態響應 動態切換等功能。單純的做存儲服務器還是比較適合的。

 

下面是我詢問gluste對LD的解釋 有興趣可以看看

 

faye.zixun

Can gulsterfs locate the file by loadbalance? I mean to find the nearest server to get the file.

I know glusterfs saving and finding file by its elastic hash algorithm . But if I replicate it on several replicated volumes ,can glusterfs fetch the file from the best performance Server which have been saved a  replicated volume?   
  • 0 Comments
  • 1 Answer
  • 2 votes
Yes this is the intended default behavior. Elastic hashing leads the lookup call to a particular replicated group. Within the group, lookup calls are sent to all the mirrored members. Based on which ever server responds first, consecutive I/O calls will follow that particular server. 

Load balancing happens at the file (inode) level. When you read multiple files concurrently, load gets distributed to all the active-active replicated pairs. This improves better utilization of cache, read-ahead and also eliminates disk contention. 

There is also a hidden static option in replicate to forcefully prioritize a particular set of servers. My recommendation is to leave it to GlusterFS defaults. 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章