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

darkpoon

测试报告发布
　　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