Gluster vs Ceph 红帽的Ceph/Glusterfs测试报告的争论

测试报告发布

John Mark,红帽的gluster开发人员。以下是对他的文章的转译:

他在2013年openstack 香港峰会上发表了一项测试数据:红帽营销部门对glusterfs/ceph的性能评测结果(顺序io性能比ceph好,此测试并不完整,缺少随机读写的测试等)

mark认为ceph和glusterfs作为开源软件定义存储的代表,基本上友好,虽然也有竞争。他的目标听众是非ceph项目和inktank公司相关的人员,openstack社区中认为存储应该采用ceph,不再有啥争论的那些人。他反驳了Ceph is faster than Gluster这样的坊间流言。

openstack社区更倾向于采用单独一项存储技术,glusterfs不能没有参与竞争就败下阵来。(看来这是第一次glusterfs对ceph的反击)

glusterfs积极改进,不想屈居第二。竞争的赢家最后是用户。

对报告的有意义的评论文章及其文后的评论

评论文章

最新的评论文章,也许是基于上面redhat报告而写的,很有意思,特别是评论。

我大致罗列如下:

Table 1. ceph vs glusterfs
对比项 ceph特性 glusterfs特性

架构方法

ceph基于rados对象存储,基于一些api网关提供块/file/对象等数据接口。ceph集群基于原生的replication和信息分布来构建。(也用hash算法但有元数据服务器)

glusterfs也提供块/file/对象,但是是基于file级别。用hash算法定位数据,跟ceph差不多一样。hash算法作用于存储池内的所有存储服务器。无元数据服务器。

数据分布能力

都能stripe数据到不同的节点。

但是glusterfs默认没有。

默认块大小

64KB,较小,导致较多的随机io操作,大的io大小总体可以移动较多的数据。可以64至256KB/1MB。

glusterf默认128KB(这里应该是条带单元大小,但是看redhat测试报告,glusterfs并没有采用stripe的配置,存疑),因为此原因在redhat测试中超过ceph。

redhat测试

NA

基于glusterfs特定配置并进行了io优化。应该通过第三方测试。默认块大小保证了glusterfs胜出。

扩展性能

避免单节点元数据,应该能线性扩展

避免单节点元数据,应该能线性扩展

caching/分层存储能力

ceph的file journals可以写到ssd。

glusterfs也开始提供,正在开发中,参见http://pl.atyp.us/tag/glusterfs.html 。

坏盘下系统rebuild能力

ceph好。data分布到更多的节点,更多的盘可以从完整的replicas中接收数据,所以rebuild时间快,也不会加大某个盘的负载。

NA

安装和管理

ceph提供更综合的方法因为file/block/remotereplication是原生的功能。所以是ceph的优势。

NA

价格

NA

NA

ceph比glusterfs更快的看法

不置可否。认为随机io个数应该相近,受限于磁盘能力。

同左

文后的评论:

anon9497820322也是glusterfs的开发者指出,我认为应该是Jeff Darcy:
  • 不赞同在没有注意到以下两点的情况下就判读出redhat的报告在误导人们。

    • 指明具体的测试问题

    • ceph的商业开发公司inktank并没有因为ceph比glusterfs快的坊间看法而提供任何测试报告。

  • 坏盘下系统rebuild的看法不对

    • 用来修复那个坏盘的所有其他盘的个数受一个replicaticaton set限制。在任意时刻,修复都是并行的。ceph/glusterfs如是。但是ceph是默认,glusterfs默认没有使用stripe,但是也可以开启的。

    • 对于ceph,还应该考虑元数据服务器端的修复。证据有些不明显,建议用真实的场景来验证。

  • 安装和管理,glusterfs更好。glusterfs有cli集群管理,非破坏性升级。ceph才仅仅才开始做出了这方面的改进。

  • ceph对file/block/对象的原生集成的看法不对:文件系统元数据不在rados层,是在单独的一层实现的;radosgw对象存储组件也是单独的。nfs/samba也是单独的。而glusterfs中,nfs,samba,block via qemu or iSCSI,都使用gfapi调用公共的部分。glusterfs很好的利用了模块化工程思想。再次,此评论者建议找到具体的场景来说明问题。

  • 作者认为ceph生产安装数多。希望提供数据源。基于redhat名声和销售能力,认为glusterfs安装多。

总体认为ceph和glusterfs相似性大于差别,更多的联盟大于敌对。都要面对私有存储和并不完整但却误以为通用的解决方案如hdfs的竞争。乐于看到人们对ceph和glusterfs进行对比,但是希望提供真实的数据。

此评论文章作者指出
  1. stripe功能一方面利用并行,改进单文件性能,一方面,因为到每个磁盘的请求变小了同时分解和重组原始请求引起的负载,需要管理更多的连接,等等导致性能变得更差。因为改进性能的场景很少,所以glusterfs默认没有打开stripe功能。在单stream测试中性能应该低下。但是实际应用场景大多数都是多流的。所以认为ceph的默认设计有问题。

  2. 不考虑workload负载和不对较多的并行性和较小的请求的作用关系进行测量而进行文件系统的性能的对比结果是不可靠的。

  3. ceph的管理和配置很麻烦,文档也不好。而起码glusterfs给ceph作了个标杆。

  4. 观察事实,可以认为glusterfs在很多领域超前ceph。glusterfs有文件系统无关的快照,geo-replication,加密等功能,ceph的元数据部分是否可以适于生产使用。

Sage Weil,ceph的主要创作者的评论
  1. 同意需要在性能和设计的取舍方面需要讨论

  2. 认为redhat的测试报告不是一种有意义的交流方式,因为复杂的文件系统的性能不应该约化于单个测试

  3. 系统做io基于不同的原因并不只关注性能,还可能关注恢复行为,一致性问题,代码复杂性,用户体验等

  4. 更愿意与glusterfs开发者比如Jeff Darcy面对面,搞清glusterfs做什么为什么这么做,然后讨论ceph的对应的设计决策。

测试报告地址和测试细节说明

redhat的顺序io测试报告可以从下面site地址中找到。

注:测试环境:虚拟客户机挂载cinder block ,格式化为 ext4 ,iozone吞吐量测试。4个存储节点,4个openstack 计算节点,一个openstack控制节点。存储能力不变,观察vm/计算节点对存储的性能扩展性。

脚本执行:

/iozone_test.sh $STORAGE_TYPE 0 64k 32g $VM_COUNT $COMPUTE_COUNT

上面命令的参数介绍
  1. 为glusterfs还是ceph

  2. 0为顺序写,1为顺序读。均为系统调用级别。

  3. record大小

  4. s文件大小

  5. vm_count表示并发数

只进行了顺序读写,record大小64k,文件大小32g的情况。


展开阅读全文

Git 实用技巧

11-24
这几年越来越多的开发团队使用了Git,掌握Git的使用已经越来越重要,已经是一个开发者必备的一项技能;但很多人在刚开始学习Git的时候会遇到很多疑问,比如之前使用过SVN的开发者想不通Git提交代码为什么需要先commit然后再去push,而不是一条命令一次性搞定; 更多的开发者对Git已经入门,不过在遇到一些代码冲突、需要恢复Git代码时候就不知所措,这个时候哪些对 Git掌握得比较好的少数人,就像团队中的神一样,在队友遇到 Git 相关的问题的时候用各种流利的操作来帮助队友于水火。 我去年刚加入新团队,发现一些同事对Git的常规操作没太大问题,但对Git的理解还是比较生疏,比如说分支和分支之间的关联关系、合并代码时候的冲突解决、提交代码前未拉取新代码导致冲突问题的处理等,我在协助处理这些问题的时候也记录各种问题的解决办法,希望整理后通过教程帮助到更多对Git操作进阶的开发者。 本期教程学习方法分为“掌握基础——稳步进阶——熟悉协作”三个层次。从掌握基础的 Git的推送和拉取开始,以案例进行演示,分析每一个步骤的操作方式和原理,从理解Git 工具的操作到学会代码存储结构、演示不同场景下Git遇到问题的不同处理方案。循序渐进让同学们掌握Git工具在团队协作中的整体协作流程。 在教程中会通过大量案例进行分析,案例会模拟在工作中遇到的问题,从最基础的代码提交和拉取、代码冲突解决、代码仓库的数据维护、Git服务端搭建等。为了让同学们容易理解,对Git简单易懂,文章中详细记录了详细的操作步骤,提供大量演示截图和解析。在教程的最后部分,会从提升团队整体效率的角度对Git工具进行讲解,包括规范操作、Gitlab的搭建、钩子事件的应用等。 为了让同学们可以利用碎片化时间来灵活学习,在教程文章中大程度降低了上下文的依赖,让大家可以在工作之余进行学习与实战,并同时掌握里面涉及的Git不常见操作的相关知识,理解Git工具在工作遇到的问题解决思路和方法,相信一定会对大家的前端技能进阶大有帮助。
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值