红帽的大数据:Gluster全方位解读

红帽公司宣布收购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很可能会由于某个站点或是城域网的限制而受到影响。