分布式存储项目Ceph与Swift对比

这是一篇2013年发表的关于Ceph和Swift对比的文章,最近想围绕这两个项目之一做本科毕业设计,看这篇文章难度不大,想拿来翻译一下,顺便为之后一些技术文档的翻译打个基础。但碍于缺少翻译经验,实际翻译起来有些地方还挺难找到对应的词句,所以就按照自己的理解翻译了,请大家多多包涵:)

原文地址: Ceph and Swift: Why we are not fighting.

序言

我刚刚从香港的OpenStack峰会回来。与往常一样,在那里你可以对着一大群人发表激情澎湃的演讲或是观看他人的展示,还有为我们共同热爱的软件绘制蓝图。

在会上和别人讨论的时候,总会有人问我这个问题: 到底Ceph和Swift哪个更好?

早在2008年,当OpenStack还仅仅是一个想法的时候,我就参加了Swift项目,而现在已经成为了项目的核心开发者,因此我的回答显然会有偏向性。

当一个更好的产品出现时,人们理所当然地会淘汰旧的转而使用新的,这也正是我们科技发展中一次正常的演进。我记得当时Linux刚起步那时候,我仍旧坚持使用Linux终端上的Lynx(译者注:一个命令行的纯文字浏览器)和其他工具而避开X11,因为我当时没有看到它的价值所在。而现在我却非常愉快地用着Mac OS X:)

但是Ceph和Swift却不是彼此竞争的,它们是两种完全不同的技术,有着各自的目的。的确它们有些特性是相重合的,但其仍然有不同的使用场景,而且能够在同一个项目中很好地共存.

特点对比

概括性地看,这两种对象存储技术各有一些不同的特点:

Ceph:

  • 2006年起步
  • 使用C++编写
  • 强一致性
  • 块存储
  • 对象存储

Swift:

  • 2008年起步
  • 使用Python编写
  • 最终一致性
  • 对象存储
  • 已部署到大规模公有云的生产环境中使用

Ceph

Ceph做的远不只是对象存储。把Ceph作为开源的块存储(提供远程虚拟磁盘的一种方式)是最开始吸引开发者们使用的原因。后来Ceph在OpenStack社区逐渐成为一个非常流行的块存储方式,对OpenStack和开源社区来说都是好事,由此可见它在这方面做的十分出色.

Ceph能够作为块存储是因为它遵循强一致性,保证你每次写入磁盘时,客户端收到确认后,写入一定是成功的。同时用C++编写不仅使得Ceph在性能上得到了优化,并且这样的设计也允许客户端能够直接与Storage Server(OSDs)进行通信.

Ceph的文件存储目前还在开发中,目前还没准备好上生产环境,但到时候它应该能解决一个研究已久的、极其困难而复杂的问题。

Swift

与Ceph不同,Swift只做一件事并把它做到极致,那就是只把目光放在对象存储上,并提供一个REST API来访问。Swift是最终一致性的,意味着当硬件宕机的时候(在集群中往往是不可避免的),Swift会回滚并提供高可用的数据。Swift的最终一致性窗口只会在两种情况下可见:访问在硬件宕机时被写入的对象,以及许多对象被写入容器时访问该容器的对象列表.

最终一致性还允许Swift集群被部署在地理上相距较远的机房。这不仅仅是一个使用类似”日志重放”的备份,它允许使用者在集群中针对各个区域(region)配置同步或异步的备份策略,Swift的Proxy Server需要清楚它们在哪种区域。这一点就允许使用者优化吞吐量,并决定新写入数据的分布情况。

Swift使用Python来编写对使用者来说有许多好处,不仅仅是因为这个语言本身,还因为Python能更方便地配置各种中间件,能够直接合并到WSGI pipeline中。这也使得Swift能够配置各个不同的认证系统,集成各种中间件以修改原有功能或加入新特性。

和Python类似,Swift也遵循”batteries included”(大意是内置了各种可用的工具,不需要自己折腾)的设计思想,你可以选择配置不同的中间件,甚至可以让它成为S3的替代品.

Swift最后一个优点在于它已经在大规模的生产环境集群中被证明可用,包括许多不同的公有云已经在使用它(例如RackspaceHPCloudwattMercadoLibre等等…)并得到了不错的反馈。

另一方面,Ceph是通过Rados Gateway(译者注: radosgw,一个构建在librados之上,用libfcgi实现的一个FastCGI模块,提供REST访问接口)提供对象存储服务,虽然已经提供了与S3兼容的API,它仍然不如一个完整的Python WSGI系统,而且也不允许模块化。把它作为gateway使用的一个问题就是总要仿照Swift API定义。尽管目前它核心的API定义已经较为完善、稳定且向后兼容,它仍然无法包含Swift内所有的中间件。

应用场景

如果你必须要选择其中之一且对块存储有需求的话,你必然想选用Ceph。但如果只有对象存储的使用场景的话我会建议你选用Swift.

虽然前面提到有场景会同时使用两个系统,但有些团队不愿意管理两个运行着不同系统的集群。如果你想使用S3 API或Swift API,Radosgw对于一些简单的应用场景来说足够好用,但它不能提供一个功能完备的对象存储系统。另一个需要考虑的因素是Radosgw存储的对象不能通过块存储系统访问,这是因为不同的使用模式导致它们会被部署在不同的硬件设备上。

最后,感谢Red Hat Gluster团队,Swift现在拥有了multi-backend系统(现在叫Pluggable On-Disk Back-end),能够让开发者为Swift配置不同的存储后端,意味着你可以高效地将ceph配置在对象存储服务器上.

这个话题目前还没结束,Swift和Ceph的开发者已经进行了讨论并尝试看如何将他们接在一起。但是最终这个功能将会给用户提供一个管理成本最小化的选择。

总结

不要把Swift和Ceph当做竞争对手。它们都是很棒的开源项目,各自都有一些具体的目标。它们关键的竞争点在于专利软件解决方案导致的供应商锁定(vendor lock-in)。Swift和Ceph,包括它们活跃的社区生态,对绝大部分的应用场景来说都是非常好的解决方案.