https://www.oschina.net/news/49048/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 所把持的存储市场.
来源: http://www.bubuko.com/infodetail-2987848.html