紅帽的大數據：Gluster全方位解讀
譯文【51CTO快譯】紅帽公司宣布收購Gluster ，后者作為GlusterFS開源文件系統及Gluster存儲平臺軟件堆棧的開發者受到廣泛關注。通過這種方式，紅帽公司將自己打造成了一套針對尋求類似 Apache Hadoop 這樣大數據解決方案的客戶提供服務的一站式商店。不過它同時還買進了一套文件系統，該系統在基于云平臺的部署方面有著極大的潛力。如果大家還沒聽說過Gluster這個名頭，那么不妨詳細閱讀本文，并從中了解這家公司是如何在擴展式網絡附加存儲領域鶴立雞群的。
Gluster公司簡介
用這家公司自己的話說，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項目）相結合的硬件負載平衡器。
由于客戶只能在同一時間與一個節點建立聯系，因此讀、寫請求就不得不在接入節點與實際存儲對應內容的節點之間來回奔走——這種情況比起使用本地客戶端，性能表現自然會大幅下降?？偠灾?，使用這些協議的部署方案通常還需要一套單獨的后端網絡，專門用于處理響應客戶端請求所必要的節點流量。
管理
同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也許會成為云后端基礎設施領域的一顆耀眼新星——無論是在公共云中還是在私有云中。
原文：Red Hat Gluster, the cloud storage monster
【編輯推薦】
