Ceph vs Swift - 架构剖析

m45y 9年前

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 – An Architect’s Perspective(翻译:崔婧雯 校对:魏小红)
===========================
译者介绍
崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

来自:http://dockone.io/article/410