Gluster vs Ceph：开源存储领域的正面较量

引言：开源存储软件Ceph和Gluster能够提供相似的特性并且能够为用户节省不小的开支。那么谁更快？谁又更易用呢？

开源的Ceph及Red Hat旗下的Gluster都是成熟的技术，但兴许不久之后就将经历某种重生了。随着存储产业开始向扩展性存储及云的方向发展，将不断会有基于这些低价的软件技术的产品推向市场，而对这些自集成解决方案的补充在近一年来不断涌现。

Ceph与Gluster在原理上有着本质上的不同。Ceph基于一个名为RADOS的对象存储系统，使用一系列API将数据以块(block)、 文件(file)和对象(object)的形式展现。Ceph存储系统的拓扑结构围绕着副本与信息分布，这使得该系统能够有效保障数据的完整性。

而Red Hat将Gluster描述为可扩展的网络存储设备(Scale-out NAS)和对象存储系统。它使用一个哈希算法来计算数据在存储池中的存放位置，这点跟Ceph很类似。并且这是保证扩展性的关键。在Gluster中，所 有的存储服务器使用哈希算法完成对特定数据实体的定位。于是数据可以很容易的复制，并且没有中心元数据单点这样一个容易造成访问瓶颈的部分，这种单点在早 期Hadoop上出现，对性能和可靠性造成较大影响。

Ceph与Gluster有着相似的数据分布能力。Ceph像大多数对象存储软件那样，通过更大的节点集进行数据条带化处理。这样的好处是能够防止数据访问的瓶颈效应。

因为默认的Ceph块比较小(仅为64KB)，所以数据流被切分为许多随机的IO操作。而磁盘在随机IO的时候一般能够达到最大值(对HDD而言最 多达到150次每秒)，并且这个数值不会随传输的数据大小改变多少。所以对于Ceph而言，设置更大的IO块意味着能够一次聚合传输更多的数据。

Gluster默认的块大小是128KB。这是Red Hat声称在一项基准测试中Gluster的性能是Ceph的三倍的主要原因。当然，测试者用了一些小技巧，所以测试结果是参数设置及实验调优的结果。Ceph能够将块大小从64KB设置为256KB甚至1MB，这么做也能使Ceph的性能得到不小的提升。

基准测试的门道相当复杂。块大小的设置能够左右Ceph与Gluster的性能对比。想要得到公平的比较结果，就必须依赖第三方不带任何偏见的进行测试。显然，Red Hat的报告有着显著的误导性。

回头再来看两者的扩展性能。两个系统都避免了单节点的存在，因此可以近乎线性的进行扩展。重复数据删除不会对性能造成太大的差异。两者的服务器端的压缩技术减轻了磁盘利用及网络负载双方面的压力，并且降低了每个文件的磁盘IO次数。

Ceph file journals技术能够向SSD设备中写从而使得性能大幅度提升。并且支持缓存(Caching)或分层(Tiering)，配置方式可简可繁。

Ceph在恢复损坏的磁盘时有优势。因为，Ceph相比Gluster将数据放置在一个更大的节点集中，有更多的设备(磁盘驱动器)能够同时输入副本数据。这将大大缩短数据重建的时间，且不会显著增加某个磁盘设备的负载。在大规模的集群中，这是一个显著的优势。

两个系统的安装和运维都相当简单，但如果规划要做长期的部署则必须花费一些时间认真准备。存储管理员会发现Inktank为Ceph提供了一些更为 精细的操作，因为Ceph对文件系统、块访问以及远程复制等操作都是采用内建函数的方式，而不像Gluster那样采用插件的方式。这给了Ceph很大的 优势，也是为什么Ceph能够在安装上领先Gluster的原因。这能够很轻松的解决块迁移的问题并且提供单个存储池的管理。

诚然，两者在合理的代价下为用户提供了较强的可选性。两者的源代码都是开源且免费的，Inktank和Red Hat公司则提供支持服务及管理工具包。相比传统的存储，随着通用型硬件及存储设备(磁盘)价格的不断下降，Ceph和Gluster都体现出越来越大的价值。

因为很好的功能、不错的性能以及在价格方面的优势，Ceph以及Gluster在昂贵的专用存储之外提供了一种可行的解决方案，可以预见它们将会得到市场的青睐，并且有可能撼动由EMC或NetApp所把持的存储市场。

原文链接： information week 翻译： 伯乐在线 - 熊崽Kevin
译文链接： http://blog.jobbole.com/59454/