Ceph vs Swift - 架构剖析

【编者的话】Ceph和Swift，哪种更好？这个问题上大家争论不休，本文从两者的架构角度分析两种方式各自的优缺点，并且给出如何选择的建议。

当工程师们讨论存储，谈到Ceph和Swift时，他们通常都一致认为其中一个非常棒，另外一个却很糟糕。但问题时，他们在哪个好哪个不好上却意见不一。

经常会有客户问我相同的问题，“我们听说Ceph可以代替其他所有类型的存储。为什么不能用它做所有事情呢？”

我会在Vancouver的OpenStack Summit大会上从架构角度探讨Ceph和Swift，分享在这两者之间到底该如何抉择，也会为两种平台的解决方案都给出建议。本文，我们一起看看他们的架构细节和不同之处。

深入浅出

Swift在OpenStack开始发展之初就出现了，大概在五年之前。它是OpenStack的核心项目，并且被无数次证明强大且稳定。

问题是，Swift的设计导致在传输速度和延迟时间上都不强。造成这个问题的主要原因是Swift集群进出的流量都要通过代理服务器。

另一个原因，也是很多人认为Ceph更好的原因，是Swift不支持块存储和文件存储。

最后，当对象副本不一定同时更新时延迟的问题便会浮现，这会导致请求者在第一次更新某个对象到新版本之后，读取到的却仍然是旧版本。这种行为被称为最终一致性。

另一方面，Ceph也有自己的问题，特别是在云环境上。它的多地域支持，虽然经常被当做优势来宣传，但实际上还是master-slave模型。因为只能从master到slave进行复制，所以在多于两个地域时，基础架构上的负载分布会很不均衡。

Ceph的两地域设计也不太实际，因为只支持master上的写入，而不阻隔slave上的写入。这样的配置最严重时可能导致整个集群的崩溃。

Ceph的另一个短板是安全性。云计算节点上的RADOS客户端直接与RADOS服务器交互所使用的网络与Ceph用于未加密复制流量的网络相同。如果某个Ceph客户端节点被入侵，攻击者便能得到存储网络的所有流量。

针对Ceph的弱点，你可能会问，为什么不直接构建一个Ceph集群，扩展到两个地域呢？一个原因是Ceph只能同步写入，并且要求写入节点达到quorum数才能成功返回。

了解这些问题之后，我们来假定有一个集群跨越两个地域，相隔数千英里，100ms延时，非常慢的网络连接。假定将两个副本写入到本地地域，另外两个写入到远程地域。这时四次副本的quorum数是三次，这就意味着这次写请求在至少完成一次远程拷贝前都不会返回。也就意味着即使是很小量的一次写入也会延迟0.2秒，而大批量写入则会因为吞吐量限制严重受阻。

另一方面，Swift，在与之相同的两地域架构中，会先在本地写入，然后基于一致性设计在一段时间里复制到远程地域。Swift也要求写入quorum，但是可以在集群上配置write_affinity设置强制限定写入quorum在本地地域，因此本地写入完成后就会成功返回。

那么我们在Ceph和Swift之间如何抉择呢？

如何选择？

如果部署只在单一地域，没有计划扩展到多个地域的话，Ceph会是很好的选择。Mirantis OpenStack底层可以选择Glance或者Cinder。但是，如果要考虑大规模部署的话，Swift比Glance更适合。它的多地域能力会胜过Ceph的速度和强大的一致性模型。

很多情况下，速度并不是决定因素，安全性则是更大的问题，这时，Swift更适合，它封闭的复制网络更为安全。另一方面，如果云基础架构本身已经很安全，存储安全性优先级便会降低，这时可能Ceph更适合。

与其比来比去，不如在同一个云基础架构里同时拥有这两种选择。比如，可以使用Ceph作为本地高性能存储，而Swift则作为多地域Glance后台，这时复制很重要而速度并不关键。但是，拥有这两种选择的解决方案花费必然更多，因此可能还是需要二选一。

对于很多客户，我的个人建议是，Mirantis提供了架构设计评估来帮助收集所有需求和参数，提供适合特定使用场景和业务驱动的解决方案，会帮助全面评估所有业务，技术和运营因素。然后你可以权衡这些因素，以及这两种选择的优缺点。谁知道呢？你的收获很可能超过预期。

原文链接：Ceph vs Swift �C An Architect’s Perspective（翻译：崔婧雯 校对：魏小红） 
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
译者介绍
崔婧雯，现就职于IBM，高级软件工程师，负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化，中间件技术，业务流程管理有浓厚的兴趣。

转自：http://dockone.io/article/410