分佈式文件系統GlusterFS

轉自於：http://www.cnblogs.com/zitjubiz/archive/2012/11/30/Distributed_File_System_glusterFS.html

GlusterFS是「一套可擴展的開源集羣文件系統，並可以輕鬆爲客戶提供全局命名空間、分佈式前端以及高達數百PB級別的擴展性。」這種說法口 氣可不小，但GlusterFS也確實把解決大問題——真正的「大」問題看成己任。事實上，Gluster的最大容量爲72 brontobyte(沒錯，這個詞已經成爲現實，至關於一千億億億字節)。

　　也許GlusterFS最值得當即瞭解的重要細節是，它徹底實現了網絡附加存儲的大規模擴展而沒有藉助其餘人在處理大數據領域所使用的要素：元 數據。元數據被用來描述一個給定的文件或是區塊在分佈式文件系統中的所處位置;它同時也是網絡附加存儲解決方案在規模化方面的致命弱點。

　　在某些狀況下，例如Hadoop的本地HDFS，元數據正是致使失敗的重要元兇。而在其它狀況下，它又做爲線性性能可擴展性的阻礙出現，由於所 有節點都必須不斷與服務器(或服務器羣組)保持聯繫以延持整個集羣的元數據——這種作法幾乎一定會帶來額外的延遲並使存儲硬件在等待響應元數據請求的過程 中處於效率低下的閒置狀態。

　　Gluster經過使用其自有的彈性Hash算法解決了這一問題。憑藉這種算法，Gluster集羣中的每一個節點都可以計算得出某個特定文件的 位置，而無需聯繫集羣內的其它節點——這基本上消除了元數據追蹤及變化的必要性。正是這套方案讓GlusterFS在競爭中獨佔鰲頭，並使其真正可以實現 自身在線性性能擴展性方面的承諾。

　　後端部署

　　GlusterFS是一套用戶空間文件系統驅動程序，能夠被部署於任何品牌的Liniux系統之中(主要是RHEL或者CentOS)。換句話 來講，GlusterFS的運行徹底獨立於硬件以外，所以很是便於攜帶。在預製型或者是私有云實例中，GlusterFS能夠被建立於諸如JBOD(即簡 單磁盤捆綁)、DAS(即數據採集系統)或者SAN存儲等商用服務器硬件之上——具體使用哪一種硬件徹底取決於終端用戶的選擇。而在公共雲環境 中，GlusterFS則能夠直接被安裝在現有產品上，進而提供更好的可擴展性及有效性(目前Amazon及Rightscale公司都在提供相似的產 品)。除此以外，當其被部署於數量與日俱增的虛擬裝置之中時，Gluster的節點將運做於管理程序之上——不管是預製型仍是在雲中。

　　根據數據在GlusterFS節點集羣中的存儲方式，Gluster可以以性能不一樣、可用性特性不一樣的數種方式加以部署。最簡單的一種當數只分 布型，這種類型從本質上模擬了文件級別的RAID0分佈情況。而這種類型中，文件只存儲在一個Gluster節點中，所以單個節點的故障即會致使數據的丟 失。其實這沒什麼好奇怪的，低安全性換來的是最高級別的性能表現以及最高效的存儲調用狀態，由於整個流程中不涉及文件備份。

　對於那些要求在節點故障狀況下仍能保證數據安全的應用程序來講，Gluster的分佈式副本模式可以知足此類要求，該模式基本上相似於RAID 10。在這種模式下，文件被分佈在始終處於同步狀態的一對鏡像節點當中。個別節點在發生故障時鏡像節點會及時補充，進而保證文件的可用性不受任何影響。

　　最後，Gluster還支持分段模式，這是一種在執行上很是接近標準化區塊層RAID0的模式。根據建議，該模式通常只適合用於處理超大型文件 (一般要超過50GB)的存儲及多節點性能要求較高的狀況。這也是唯一一個將會永遠將文件拆分並將其分佈於多個節點上的模式——其它全部模式都只在文件層 面運做。遺憾的是，鏡像與分段模式沒法結合，所以要實現極高的可用性，必須將這套方案與硬件部署統一塊兒來。

　　儘管咱們沒法在同一個Gluster集羣中同時使用多種存儲模式，但仍然能夠在同一套硬件裝置中運行數個邏輯集羣。所以，你們實際上可以在單獨的物理硬件中並行運行分佈式備份集羣及分段式集羣。

　　除了容許在Gluster集羣內部實施分佈式備份系統以外，不一樣集羣間的多線路地域備份也是可行的。這種方案可以被用於保護網站所面臨的總體故 障或者爲應用程序從一個站點向另外一個遷移的工做變得更加便捷。Gluster地域備份頗具靈活性，容許咱們複製包含任意數量中間副本的各類模式(例如從A 站到 B站、從B站到C站及D站等等)。

　　應該指出的是，Gluster集羣跨物理站點的延展也是可行的，但這就對分佈式集羣內部的同步工做在複製、大量廣域網帶寬及低延遲方面有着較高 要求，以保證得到使人滿意的性能表現。而在實際操做中，單獨的Gluster極可能會因爲某個站點或是城域網的限制而受到影響。

　　客戶端訪問

　　Gluster能夠經過多種不一樣協議實現客戶端訪問，包括本地Gluster客戶端、NFS、CIFS、WebDAV、HTTP等等。然而，只有本地Gluster客戶端才能正常支持高可用性、大規模的並行文件訪問。使用本地客戶端，全部客戶端系統都會在積極鏈接到全部集羣節點的同時，藉助客戶 端實施的彈性Hash算法瞭解到自身在拓撲結構中的位置，而且直接從所要求的託管節點處接收數據。所以，來自本地客戶端的訪問將永遠不會使Gluster 節點爲了知足客戶端請求而產生數據交換——並且一旦某個鏡像節點出了故障，應用程序能夠透過Gluster分卷對其獲得清楚的瞭解。

　　基於標準的NFS及CIFS都存在着嚴重的侷限性，使它們沒法處理這種高度並行的訪問。所以，NFS及CIFS在部署中須要引入額外的軟件來管 理負載平衡及保證高可用性，由於客戶在任何特定時段內只可以鏈接到單獨的一個存儲節點。負責處理這一問題的每每是循環域名服務或者是與UCARP(虛擬路 由冗餘協議的簡化版)或CTDB(用於集羣存儲的Samba項目)相結合的硬件負載平衡器。windows用戶可採用 LVS+Linux（開啓Samba服務）做爲文件服務器集羣

　　因爲客戶只能在同一時間與一個節點創建聯繫，所以讀、寫請求就不得不在接入節點與實際存儲對應內容的節點之間來回奔走——這種狀況比起使用本地 客戶端，性能表現天然會大幅降低。總而言之，使用這些協議的部署方案一般還須要一套單獨的後端網絡，專門用於處理響應客戶端請求所必要的節點流量。

 

管理

　　同Gluster 裸機存儲平臺共同運行的Web GUI，再加上一套與Gluster分佈式獨立體系協同合做的命令行工具，兩者的結合完成了Gluster的管理工做。所以，管理這套體系的最佳人選是那 些熟悉Linux系統管理工做的技術人員。對於某些具有必定Linux知識的人來講，整個使用過程將會很是簡單，只需幾個簡單的指令便可完成至關繁雜的工 做，好比添加一個新的節點或建立一個新的分卷。事實上，著名互聯網廣播公司Pandora所部署的、基於Gluster的250TB服務存儲後端也只有一 位專門的管理人員負責打理。只要你們對Linux技巧不太陌生，又願意拿出1、兩個小時來熟悉，Gluster簡直就是手到擒來。試問，還有哪一款集羣文 件系統可以作到這一點呢?

　　雲應用程序

　　除了其爲了支持雲環境可打造的存儲後端高可用性，Gluster還擁有很多可以服務於當下公共雲基礎設施的巧妙應用程序。在爲如Amazon EC 2這樣追求極端高可用性的雲基礎設施打造存儲系統時，最大的挑戰之一就是咱們真的須要 將本身的災難恢復規劃引入其中 。儘管Amazon爲其以對象爲基礎的S3存儲平臺提供了強大的可用性支持，它仍然沒法帶來與支持着EC2計算實例的在線EBS(即彈性區塊存儲)產品同 級別的服務。此外，EBS分卷的容量被限制在2TB，這就使得其很難與其它大型數據集相契合。

　　經過將Gluster引入EC2，你們能夠完全無視2TB的容量限制，盡情將本身的鏡像部署在EC2的可用區塊中;咱們甚至可以利用 Gluster 將本身的數據複製到不一樣的EC2可用區塊、別家雲服務供應商甚至是本身的預設基礎設施裏。固然，並非每一個人都須要這樣強度的穩定性及可擴展性，但對於那 些須要的人而言，這極可能意味着交上了一份堪稱偉大的答卷。

　　總結陳詞

　　不少關注紅帽公司收購Gluster事件的分析人士都注意到除了最明顯的大數據應用以外，對HDFS及Amazon S3 API的兼容性也即將被加入GlusterFS 3.3當中。屆時Gluster將極可能衝破一款優秀的大數據存儲文件系統的侷限，得到更使人矚目的成就。有了對一系列不一樣管理程序，包括即將到來的對 OpenStack的兼容，Gluster也許會成爲雲後端基礎設施領域的一顆耀眼新星——不管是在公共雲中仍是在私有云中。