【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
【编辑推荐】
