设为首页 收藏本站
查看: 1324|回复: 0

[经验分享] Gluster vs Ceph 红帽的Ceph/Glusterfs测试报告的争论

[复制链接]

尚未签到

发表于 2019-2-1 12:25:22 | 显示全部楼层 |阅读模式
测试报告发布
  http://redhatstorage.redhat.com/2013/11/07/red-hat-storage-outperforms-ceph-by-more-than-3x-for-openstack-cloud-environments/
  https://www.gluster.org/2013/11/on-the-gluster-vs-ceph-benchmarks/
  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积极改进,不想屈居第二。竞争的赢家最后是用户。
对报告的有意义的评论文章及其文后的评论
评论文章
  http://www.informationweek.com/infrastructure/storage/gluster-vs-ceph-open-source-storage-goes-head-to-head/d/d-id/1113581
  最新的评论文章,也许是基于上面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进行对比,但是希望提供真实的数据。
  此评论文章作者指出

  •   stripe功能一方面利用并行,改进单文件性能,一方面,因为到每个磁盘的请求变小了同时分解和重组原始请求引起的负载,需要管理更多的连接,等等导致性能变得更差。因为改进性能的场景很少,所以glusterfs默认没有打开stripe功能。在单stream测试中性能应该低下。但是实际应用场景大多数都是多流的。所以认为ceph的默认设计有问题。
  •   不考虑workload负载和不对较多的并行性和较小的请求的作用关系进行测量而进行文件系统的性能的对比结果是不可靠的。
  •   ceph的管理和配置很麻烦,文档也不好。而起码glusterfs给ceph作了个标杆。
  •   观察事实,可以认为glusterfs在很多领域超前ceph。glusterfs有文件系统无关的快照,geo-replication,加密等功能,ceph的元数据部分是否可以适于生产使用。
  Sage Weil,ceph的主要创作者的评论

  •   同意需要在性能和设计的取舍方面需要讨论
  •   认为redhat的测试报告不是一种有意义的交流方式,因为复杂的文件系统的性能不应该约化于单个测试
  •   系统做io基于不同的原因并不只关注性能,还可能关注恢复行为,一致性问题,代码复杂性,用户体验等
  •   更愿意与glusterfs开发者比如Jeff Darcy面对面,搞清glusterfs做什么为什么这么做,然后讨论ceph的对应的设计决策。
测试报告地址和测试细节说明
  redhat的顺序io测试报告可以从下面site地址中找到。
  http://redhatstorage.redhat.com/2013/11/07/red-hat-storage-outperforms-ceph-by-more-than-3x-for-openstack-cloud-environments/
  注:测试环境:虚拟客户机挂载cinder block ,格式化为 ext4 ,iozone吞吐量测试。4个存储节点,4个openstack 计算节点,一个openstack控制节点。存储能力不变,观察vm/计算节点对存储的性能扩展性。
  脚本执行:
  /iozone_test.sh $STORAGE_TYPE 0 64k 32g $VM_COUNT $COMPUTE_COUNT
  上面命令的参数介绍

  •   为glusterfs还是ceph
  •   0为顺序写,1为顺序读。均为系统调用级别。
  •   record大小
  •   s文件大小
  •   vm_count表示并发数
  只进行了顺序读写,record大小64k,文件大小32g的情况。
参考链接
  http://thevarguy.com/open-source-application-software-companies/glusterfs-or-ceph-who-will-win-open-source-cloud-storage-http://hekafs.org/index.php/2013/01/ceph-notes/
  http://www.informationweek.com/infrastructure/storage/gluster-vs-ceph-open-source-storage-goes-head-to-head/d/d-id/1113581
  https://shellycloud.com/blog/2013/09/why-glusterfs-should-not-be-implemented-with-openstack
  http://www.gossamer-threads.com/lists/openstack/dev/31659
  http://blog.techdozor.org/index.php/2013/06/11/ceph-vs-gluster-debate/
  http://www.spinics.net/lists/ceph-users/msg06883.html
  http://serverfault.com/questions/127927/glusterfs-vs-ceph-which-is-better-for-production-use-for-the-moment
  http://cloudfs.org/index.php/blog/
  http://www.reddit.com/r/linux/comments/1ggf4g/any_real_world_glusterfs_experience/
  https://plus.google.com/109199464497582075623/posts/3GVW5j7Vb
  Last updated 2014-04-30 10:48:19 CST
  转自:http://blog.csdn.net/inevity/article/details/19566299


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-670446-1-1.html 上篇帖子: 关于CentOS/RHEL中GlusterFS版本说明 下篇帖子: centos6.5两种方式安装glusterfs以及第三方测试工具
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表