分布式檔案系統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技巧不太陌生，又願意拿出一、兩個小時來熟悉，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也許會成為雲後端基礎設施領域的一顆耀眼新星——無論是在公共雲中還是在私有雲中。