客户端访问 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也许会成为云后端基础设施领域的一颗耀眼新星——无论是在公共云中还是在私有云中。 |
