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 - 架构剖析
