分布式文件系统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也许会成为云后端基础设施领域的一颗耀眼新星——不管是在公共云中仍是在私有云中。