核心提示： Swift和Ceph都是开源的对象存储系统。不过，尽管他们有很多相似之处，当选择其中一个作为OpenStack存储时有一些差异之处需要考量。

Swift和Ceph都是开源的对象存储系统。不过，尽管他们有很多相似之处，当选择其中一个作为OpenStack存储时有一些差异之处需要考量。

两种最常见的OpenStack存储选项分别是作为OpenStack项目一部分的Swift，以及独立的开源系统Ceph。这两个选项都提供对象存储，并且可以免费下载。也因为这个原因，我们可能很难在这两者之间进行选择。以下所述是对OpenStack存储Swift和Ceph进行评估时通常需要考虑的方面。

支持对于Swift和Ceph来说都是一个挑战——这里有两种选择。企业可以增加员工来处理底层硬件和开源软件，或者购买一个有支持的发布版本，附带软件支持和配置的专业知识。

许多厂商都支持Swift，每家都提供自己的OpenStack版本。支持可以是纯软件或者也同时包括硬件，比如购买一家供应商预集成的OpenStack系统。直到几年前，Ceph都是由初创公司Inktank支持，但现在已经由红帽全面支持。有很多厂商销售预集成好的Ceph设备并负责硬件的支持。

采购和支持都是在某种公平竞争的市场环境中。确保售后的附加驱动器价格是否合理，因为某些主流供应商要求驱动器价格上的巨大涨幅。一般来说，Ceph的厂商使用商用现成的驱动器，并允许用户从分销商处购买标准的驱动器，而一些Swift厂商则更专有，要求你购买他们的驱动器。

Swift和Ceph的功能成熟度对比

Ceph是一个成熟的产品，已经获得了很多的使用。但它并不是完美的，因为Ceph的部分组件，如对象存储守护进程(OSD)的代码，仍然在大改中。Ceph还支持文件和块IO访问模式，并且CERN已经证明了Ceph可以扩展到很大的规模。

Swift也算成熟。然而，大规模的OpenStack部署仍然很罕见，因此Swift的可扩展性在某种程度上还没有被真正测试。Swift在Ceph之后几年也进入了该领域，并且之后一直在努力的追赶Ceph。其结果是，一些Swift的开发人员目前主要关注在那些有助于Swift进一步区别于Ceph的功能细节上。

而这目前导致了Swift专有API的发展，该API不但不同于Ceph的API，与亚马逊简单存储系统的API也不相同。然而对于另一套接口的抗拒正在产生，除非有非常有力的理由可以支持这种分歧，否则Ceph的市场份额可能会因此增长。

从路线图可以看出，Ceph Special Interest Group正在明确的构建更好的方案。红帽与SanDisk最近一起合作来改善Ceph的SSD和闪存性能，预期硬盘的使用情况在未来几年内会下降。然而一个已知的Ceph短板是后端流量的紧张可能造成性能的瓶颈。擦除编码，而不是复制，提高了流量水平，而红帽和Mellanox的合作伙伴关系使远程直接内存访问和快速局域网连接成为可能，从而可以提高吞吐量和响应时间。

据红帽表示，进一步改进正在进行中。例如，Ceph负责驱动存储设备的OSD代码，正在重写并进行了性能调优。Ceph代码在结构上已经为软件定义基础架构做好了准备，并且可以轻松地虚拟化和复制。这使得Ceph适用于超融合架构配置。

Swift和Ceph在数据一致性上的差异

Swift和Ceph在数据一致性管理上存在差异。Swift提供最终一致性，即一些数据对象从第一次拷贝之后的副本是以异步的方式写入。这有可能会造成因为未完成的更新而返回错误的数据，但当副本位于不同的地理区域时运作良好。

Ceph则使用同步的进程，需要额定数量的副本被写入才能确认写入完成。这保证了一致性，但增加了延迟，如果远程站点必须是定额写入的一部分。你可以通过选择合适的副本放置地点或者通过设置上的控制来解决这些问题。这对于Swift的不完整写入问题也同样适用，可以用write_affinity的设置强制在多本地写入的基础上加上定额。

虽然写定额的问题对于性能来说有巨大的影响，但这可以通过只使用本地存储来解决。

在这场Swift和Ceph竞争OpenStack存储的比赛中，Ceph的赢面很大，至少现在来看是这样。但是要给出一个完善的OpenStack存储方案，重要的是要解决块IO的问题。OpenStack Cinder项目就是为了这个目的，为各种各样的基于SAN和LAN的网络存储提供一个统一的前端。传统的块IO软件，如iSCSI，会在这些地方使用。目前没有可以同Cinder竞争的软件栈。