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服务）作为文件服务器集群

　　由于客户只能在同一时间与一个节点建立联系，因此读、写请求就不得不在接入节点与实际存储对应内容的节点之间来回奔走——这种情况比起使用本地 客户端，性能表现自然会大幅下降。总而言之，使用这些协议的部署方案通常还需要一套单独的后端网络，专门用于处理响应客户端请求所必要的节点流量。