Swift vs Ceph for OpenStack object storage


Both Swift and Ceph are open source, object storage systems. But despite their similarities, there are differences to consider when choosing one for OpenStack storage.

Two of the most common OpenStack storage options are Swift, which is being developed as part of the OpenStack project, and Ceph, an independent open source system. Both options offer object storage, and can be downloaded for free. As a result, it can be difficult to choose between the two. Here are some considerations for evaluating Swift vs. Ceph for OpenStack storage.

Support can be a challenge for both Swift and Ceph — and there are two options. Organizations can add staff to handle both the underlying hardware and open source software, or buy a supported code distribution, which comes with software support and configuration expertise.

Many vendors support Swift, each offering their own OpenStack distribution. Support can be software-only or include hardware, as well, if you buy a vendor’s pre-integrated OpenStack system. Until a couple of years ago, Ceph was supported by a startup company, Inktank, but is now fully supported by Red Hat. There are plenty of vendors selling pre-integrated Ceph appliances and addressing hardware support.

Acquisition and support are on a somewhat level playing field. Ensure that after-sales drive add-ons are reasonably priced, as some major vendors ask for huge markups on drives. Generally, Ceph vendors use commercial off-the-shelf drives and allow users to purchase standard drives from distribution, while some Swift vendors are more proprietary and require you to buy their drives.

本文翻译自Evaluate Swift vs. Ceph for OpenStack object storage,本文不代表Ceph中国社区观点。


Swift和Ceph都是开源的对象存储系统。在选择为OpenStack存储提供支持的时候,还是要考虑他们之间的区别。

OpenStack默认的对象存储方案是Swift,Swift是OpenStack项目的一部分;Ceph是一个独立的开源系统。两者都能提供对象存储,并且全部免费。对于用户选择时候,经常产生疑惑。下面本文就将介绍在选择两种对象存储的时候需要考虑的因素。

在售后支持上,对于两种开源解决方案都是一个挑战,有两种解决方案。企业可以安排相关人员掌握底层硬件和开源软件,或者购买提供代码支持的发行版,包含软件和配置的专家支持。

许多厂商都提供Swift支持,作为他们OpenStack发行版的一部分。这种支持可以仅包含软件部分或者同时包含硬件部分,当然你需要购买厂商预安装的OpenStack系统。 直到几年前,Ceph一直被一家创业公司Inktank支持,当然现在得到红帽的完全支持。有很多厂商销售预先安装的Ceph设备,并且提供硬件支持。

获取方式和支持的程度是竞争的一项重要指标。要保证硬盘售后支持的合理性,一些主要厂商在硬盘往往会开出高价。通常来说,Ceph厂商一般使用通用的硬盘,允许用户自行选择标准硬盘,而某些Swift厂商会使用私有的硬盘设备,你不得不去购买。

Compare the functionality, maturity of Swift vs. Ceph

In the Swift vs. Ceph race for OpenStack storage, it would seem that Ceph is winning — at least right now.
Ceph is a mature product, with lots of usage already. But it isn’t wrinkle-free, as some parts of Ceph, such as the object storage daemon (OSD) code, are still under major renovation. Ceph also has filer and block-IO access mode support, and has been demonstrated by CERN to scale to large sizes.

Swift is also mature. However, large OpenStack deployments are still rare, so Swift scalability remains somewhat untested. Swift also entered the arena a couple of years after Ceph and has been playing catch-up since. As a result, some Swift developers are now focused on roadmap details that could help further differentiate Swift from Ceph.

This, currently, is leading to the development of proprietary Swift APIs that not only differ from Ceph, but also from Amazon Simple Storage System. Resistance to yet another set of interfaces is building and unless there are strong reasons for the divergence, Ceph’s market share might grow.

Looking at roadmaps, the Ceph Special Interest Group is articulating a good story. Red Hat and SanDisk recently partnered to improve SSD and flash performance in Ceph, in anticipation of hard drive usage declining in the next few years. One known deficit of Ceph, however, is the intense back-end traffic that can create performance bottlenecks. Erasure coding, as opposed to replication, improves traffic levels, and a Red Hat partnership with Mellanox allowed remote direct memory access and fast LAN links to improve throughput and response time.

Further improvement is in the works, according to Red Hat. For example, Ceph’s OSD code, which drives storage devices, is being rewritten and tuned for higher performance. Ceph code is also already structured for software-defined infrastructure and can be easily virtualized and replicated easily. This makes Ceph suitable for hyper-converged configurations.

Swift和Ceph功能和成熟度对比

在Swift和Ceph的OpenStack存储竞赛中,至少现在看起来是Ceph领先。
Ceph是一个成熟的产品,有很多应用案例。但是并不是说Ceph已经很完美了,作为Ceph一部分的OSD(对象存储进程)的代码,仍然在不停的开发。Ceph也有文件接口和块接口的支持,而且已经得到CERN(欧洲核子研究组织)的大规模使用的验证。

Swift也是一个款成熟的产品。但是,OpenStack大规模部署的案例仍然很少,所以Swift的扩展性仍然未得到足够的证实。Swift紧随Ceph进入了人们的视线,而且在奋起直追。所以,现在一些Swift的开发者聚焦在未来的开发方向上,帮助Swift能在未来和Ceph有明显的区别。

目前正在开发的Swift私有API,不仅不同于Ceph,而且也不同于亚马逊的S3服务。用户并不愿意使用新的接口,除非有一个特别好的理由让用户接受,否则会导致Ceph的市场份额的进一步增长。

通过观察路线图,Ceph Special Interest小组表达出一个非常好的故事。Redhat和SanDisk最近发表声明合作,优化SSD和全闪架构在Ceph中的性能。Ceph的不足在于后端大量的流量,会产生性能瓶颈。纠删码(Erasure Codeing),不同于复制可以优化流量等级,红帽和Mellanox合作,使用远程内存直接访问(remote direct memory access)和告诉的局域网连接优化吞吐量和回复时间。

根据红帽的说法,Ceph未来的优化正在不断进行中。举个例子,Ceph OSD部分代码被重构,并且为高性能进行优化。Ceph本身的代码就是为了软件定义基础架构构建的,所以很容易实现虚拟化和复制。这使得Ceph特别适合超融合架构。

Data consistency in Swift vs. Ceph

Swift and Ceph differ in terms of data consistency management. Swift offers eventual consistency, where some of the replicas of a data object are written asynchronously from the first copy. This exposes the possibility of an incomplete update returning wrong data, but it works well when the replicas are in different geographical regions.

Ceph uses a synchronous process that requires a quorum of replicas to be written before acknowledging write complete. This guarantees consistency, but adds latency if the remote site has to be part of the quorum. You can overcome these issues by choosing the right replica placement or by setting controls. This is also true for the exposure of Swift to incomplete writes, where the write_affinity setting can be used to force a quorum based on multiple local writes.

While the write quorum issue has a huge impact on performance, it can be resolved to only local storage in either case.

In the Swift vs. Ceph race for OpenStack storage, it would seem that Ceph is winning — at least right now. But to complete the OpenStack storage story, it’s important to address block-IO. The OpenStack Cinder project addresses this, providing a front end for a wide variety of SAN- and LAN-based networked storage. Traditional block-IO software, such as iSCSI, is used in these boxes. There is no competitive software stack to Cinder.

Swift和Ceph数据一致性对比

Swift和Ceph在数据一致性的管理上并不相同。Swift使用最终一致性,一些副本实在第一份副本写入后异步写入完成的。这种方式可能会由于未完成的更新导致数据返回错误(an incomplete update returning wrong data),但是对于副本在不同地域的部署环境有比较好的支持。

Ceph使用同步方式写入,返回前需要写入指定的副本数量。这种方式保证了一致性,但是如果其中一份副本在远程,则会导致延时变长。你能通过副本的放置位置来克服这些问题。 Swift可以通过设置write_affinity强制设置在本地写入多副本的数量,解决不完全写入的问题。

写入副本数量会对性能产生较大的影响,只能通过仅使用本地存储的方式解决。

在为OpenStack提供存储的竞赛中,看起来Ceph是暂时领先的。OpenStack存储中,重要的还是提供块存储。OpenStack Cinder项目就是以此为目标,他兼容基于SAN和LAN的网络存储。传统块存储软件,像iSCSI,就是在这样的盒子里使用的。对于Cinder暂时没有竞争的软件堆栈。

Leave a Comment

电子邮件地址不会被公开。