Ceph vs Swift - 架构剖析

简介: 本文讲的是Ceph vs Swift - 架构剖析,【编者的话】Ceph和Swift,哪种更好?这个问题上大家争论不休,本文从两者的架构角度分析两种方式各自的优缺点,并且给出如何选择的建议。
本文讲的是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 – An Architect’s Perspective(翻译:崔婧雯 校对:魏小红)  
===========================
译者介绍
崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

原文发布时间为:2015-05-29
本文作者:崔婧雯
本文来自云栖社区合作伙伴DockerOne,了解相关信息可以关注DockerOne。
原文标题:Ceph vs Swift - 架构剖析
目录
相关文章
|
2月前
|
存储 算法 关系型数据库
Ceph介绍及原理架构分享
Ceph介绍及原理架构分享
154 0
|
7月前
|
存储 关系型数据库 数据库
【北亚企安数据恢复】Ceph分布式存储基本架构&Ceph数据恢复流程
Ceph存储可分为块存储,对象存储和文件存储。Ceph基于对象存储,对外提供三种存储接口,故称为统一存储。 Ceph的底层是RADOS(分布式对象存储系统),RADOS由两部分组成:OSD和MON。 MON负责监控整个集群,维护集群的健康状态,维护展示集群状态的各种图表,如OSDMap、MonitorMap、PGMap和CRUSHMap。 OSD负责存储数据、复制数据、平衡数据、恢复数据,与其它OSD间进行心跳检查等。通常情况下一块硬盘对应一个OSD。
|
8月前
|
存储 安全 块存储
ceph-架构扩展
ceph-架构扩展
287 1
|
4月前
|
存储 Kubernetes 对象存储
Kubernetes存储:Ceph架构,部署和使用
Kubernetes存储:Ceph架构,部署和使用
75 0
|
8月前
|
存储 安全 NoSQL
架构扩展-ceph(1)
架构扩展-ceph(1)
114 0
|
9月前
|
存储 运维 Kubernetes
分布式开源存储架构Ceph概述
k8s的后端存储中ceph应用较为广泛,当前的存储市场仍然是由一些行业巨头垄断,但在开源市场还是有一些不错的分布式存储,其中包括了Ceph、Swift、sheepdog、glusterfs等
741 0
|
11月前
|
存储 运维 网络协议
带你读《存储漫谈:Ceph原理与实践》——1.1.1 集中式存储系统
带你读《存储漫谈:Ceph原理与实践》——1.1.1 集中式存储系统
|
11月前
|
存储 缓存 大数据
带你读《存储漫谈:Ceph原理与实践》——1.1.2 分布式存储系统
带你读《存储漫谈:Ceph原理与实践》——1.1.2 分布式存储系统
|
11月前
|
存储 算法 大数据
带你读《存储漫谈:Ceph原理与实践》——1.2.1 有中心架构
带你读《存储漫谈:Ceph原理与实践》——1.2.1 有中心架构
|
11月前
|
存储 块存储 对象存储
带你读《存储漫谈:Ceph原理与实践》——1.2.2 无中心架构
带你读《存储漫谈:Ceph原理与实践》——1.2.2 无中心架构