Ceph和Swift的比较-为什么他们没有撕逼

     

  Ceph andSwift: Whywe are not fighting

                 
   原文：Ceph andSwift: Why weare not fighting

作者 :ChmouelBoudjnah

  翻译：BBSee[[e-mail]]    

   我刚刚从在香港举行的openstack峰会上回来。和往常一样，这次峰会上我和很多人进行了激烈的交流、听了听展示会，或者和大家一起展望一下彼此都热衷的一些软件的未来。

 
   在和不同的人交流的过程中我发现这样一个常见的问题：人们想知道是不是“ceph比swift更加优秀”。

 
   我从2008年被安排到Swift项目组，之前OpenStack甚至只是一个设想，到现在作为核心开发人员，很明显我的回答是有倾向性的。

 
   我可以理解当有可以作为更优选项的产品出现时，人们转而选择这个产品(的行为)。这是我们科技技术很正常的一种演变。我还记得当时，(让我们)追忆一下，Linux刚刚兴起的时候，我顽固地坚持结合我的Lynx和我的一些工具使用LInux终端，放弃X11系统，因为我真的看不到它的优势何在，现在我很高兴地使用者Mac
OS X系统。

 
  但是ceph和swift事实上并没有相互竞争：它们是两种不同的技术，每一种都有不同的设计目的。虽然这两者之间有一些重叠的特性，但是他们二者有着不同的应用场景并且能在同一次部署中相处的很融洽。

特性比较：

 
   从一个高水平的角度来看，这两种对象存储技术之间最主要的区别在于：

Ceph：

• 起始于2006年
• 开发语言:C
• 强一致性
• 块存储    
• 对象存储

Swift：
   

• 起始于2008年
• 开发语言：Python
• 最终一致性
• 对象存储
• 真正的大型公用云服务产品中使用 

 
   Ceph做了大量的事情，不仅仅是对象存储。ceph能作为一种开源的块存储(一种提供远程虚拟磁盘的方式)来使用，这正是人们被它所吸引的地方。Ceph在(块存储)这方面做的非常杰出，因此他似乎成为了一项部署OpenStack时非常受欢迎的块存储系统选项，总之，这是OpenStack和开源社区的一次双赢。

 
  Ceph之所以能实现块存储源自它的强一致性，确保在给客户端返回"OK"的响应之前，你要写入的所有数据都被写到了磁盘上。采用C开发使得ceph的性能最优化，与此同时，由于他的设计模式，使得客户端(Clients)能直接和存储服务器(OSDs)交互。

 
  共享文件系统的构建是一项尚未完成的工作，到目前为止(2013年)还没有为生产环境做好准备。但是，一旦它成功了，它将解决过去几十年人们努力尝试解决的困难又复杂的问题。

 
    另一方面，Swift，只做一件事，并且做得非常好。它唯一的追求就是做好对象存储并提供一种REST风格的api来访问它。它是最终一致性的。这意味着，当硬件环境发生故障时（这是一个集群不可避免的)，swift会回退以提供高利用率的数据访问。Swift的最终一致性最有可能体现在当硬件出现故障时读取被覆盖写的对象时，以及查询一个在同时创建了很对象的container(swift容器)对象列表时。

 
   这种最终一致性也允许在跨度很广的地理空间上部署Swift集群。这不仅仅是“回放日志”式的复制，它更允许部署者针对不同region的同步或者异步复制进行集群配置。Swift的代理服务器们能够感知当前它们所处的是哪个region，这就允许当有新的数据被写入时部署者可以优化吞吐量或者数据的散布。

    使用python开发Swift对于部署者来说有巨大的优势，不仅仅是因为语言本身，而是因为它与能嵌入WSGI管道的灵活的中间插件更加契合。同时也可以非常轻松地将Swift插入一系列不同的认证系统，允许所有类型的中间件修改它的行为并且结合具体的功能。

 
   和Python相似的是，Swift拥有一个称之为"内置电池"的思想体系，你拥有所有类型的中间件做着不同的事情，使得Swift更可靠地替代S3。

 
   最后一个Swift的优势是它已被证实能在超大规模生产中、在大量不同的公共的云中运行并且运行非常得良好。

 
   另一方面，ceph实现对象存储的方式是通过它的radosgateway(对象网关)而与API无关，ceph拥有健壮的仿真S3的API，它没有全规模的PythonWSGI系统那样强大并且不支持模块化。将它作为网关的问题是必须始终模拟或者遵循Swift的API，但是它的核心API是定义良好的，稳定的并且向后兼容的，当然这不包括所有和Swift一起装配的中间件

使用场景

 
  如何你只能选择其中一种，并且你有块存储需求，你肯定会选择使用ceph。如果你只是对象存储这样的使用场景，那么我建议你使用使用Swift。

 
  话说回来，如果你是两者都想使用的那种应用场景，不过一些开发团队不太希望在不同的系统上管理两个不同的集群。如果你想在一些简单的应用场景使用S3
API或者Swift API，Rdosgw(Rados gateway
对象网关)能是一个非常不错的选择，但是这并不能为你提供一个功能完备的对象存储系统。另外一点值得考虑的是通过radosgw存储的对象无法从块存储系统获取，因为他们有着不同使用方式，他们将在不同的硬件上存放(通过ceph的智能模块化放置技术).

  到了最后，用户希望有选择的余地，同时，感谢RedHatGlusterteam（红帽主存储团队），Swift现在拥有了一个多后端系统，在那里你可以拥有一个不同的、高效支持ceph作为对象存储服务器的存储后端系统。

 
  目前我们还没有完全做到这一点(swift多后端系统嵌入ceph），Swift和Ceph的开发者们曾经一起讨论尝试找出如何嵌入，但是，最后，这将为终端用户提供最小管理的选择。

总结

   
  不要再认为Swift和Ceph是对手了。这两者都是优秀的、各有特定任务的开源项目。主要竞争是专有软件解决方案导致厂商锁定，Swift和Ceph强大的社区和大家热烈的讨论都是都是解决大多数挑战很好的解决方案。

 
   感谢Swiftstack、Rackspace和Inktank上的朋友们(还有我的同事们)查阅我的这次发帖。