评估两大OpenStack对象存储技术：Swift与Ceph

Swift和Ceph都是开源对象存储系统。但是尽管两者存在相似之处，在选择其中之一用作OpenStack存储系统时还有一些有差异需要考虑。

两种最常见的OpenStack存储方案是Swift和Ceph，前者是作为OpenStack项目的一部分而开发的，后者则是一种独立的开源系统。这两种方案都提供对象存储，可以免费下载。因而，可能很难在两者之间进行选择。下面是评估Swift或Ceph作为OpenStack存储系统时要考虑的一些因素。

支持对Swift和Ceph来说都是一个挑战――这里有两个选择。企业可以增加工作人员，以处理底层硬件和开源软件，或者购买厂商支持的代码发行版，附带软件支持和配置专长。

许多厂商支持Swift，每家厂商提供各自的OpenStack发行版。支持可能是纯软件的；如果你购买某家厂商的预先集成的OpenStack系统，支持可能还包括硬件。就在几年前，Ceph还是由Inktank这家初创公司来支持，现在由Red Hat提供全面支持。许多厂商在销售预先集成的Ceph设备，并提供硬件支持。

购置和支持处于有点公平的竞争环境。要确保售后驱动器附件价格合理，因为一些大厂商对驱动器收取高价。通常来说，Ceph厂商使用商用现成驱动器，让用户可以向分销商购买标准驱动器，而一些Swift厂商偏向专有技术，要求你购买其驱动器。

比较Swift与Ceph的功能和成熟度

Ceph是一款成熟的产品，已经拥有大量的用户。但它并非没有问题，因为Ceph的一些组件仍处于重大翻新的状态，比如对象存储守护进程（OSD）代码。Ceph还有文件管理器和块IO访问模式支持，已被欧洲核子研究组织（CERN）用来扩展到大规模系统。

Swift也很成熟。然而，大规模的OpenStack部署还是很少见，所以Swift的可扩展性仍然有待检验。Swift比Ceph晚几年进入市场，此后一直在奋力追赶。因而，一些Swift开发人员现在专注于也许帮助进一步让Swift有别于Ceph的路线图细节。

目前，这导致厂商开发专有的Swift API，这些API不仅不同于Ceph，还不同于亚马逊的简单存储系统。反对另一套接口的呼声日益高涨；除非有充足的理由需要使用不同的接口，否则Ceph的市场份额可能会增长。

看一看路线图，Ceph特别兴趣小组讲述的故事颇吸引人。Red Hat与闪迪最近合作，改善Ceph中的固态硬盘和闪存性能，预计硬盘使用在今后几年走下坡路。然而，Ceph的一个已知缺点就是，密集的后端流量会导致性能瓶颈。纠删码而不是复制可改善流量大小，Red Hat与Mellanox达成合作伙伴关系让远程直接内存访问和快速局域网链路得以改善吞吐量和响应时间。

据Red Hat声称，进一步的改进正在努力之中。比如说，Ceph驱动存储设备的OSD代码正在改写，针对更高性能进行了调优。还已经为软件定义的基础设施编写了Ceph代码，这些代码很容易虚拟化、很容易复制。这使得Ceph适用于超融合架构。

Swift与Ceph的数据一致性

Swift和Ceph在数据一致性管理方面有所不同。Swift提供最终一致性，数据对象的一些副本与第一个副本异步写入。这就有可能导致不完整的更新返回错误的数据，但是副本位于不同的地区时效果良好。

Ceph使用同步过程，需要在确认写入完成之前写入法定数量的副本。这保证了一致性，但如果远程站点必须是法定数量的一部分，就会增加延迟。你可以通过选择合适的副本布局或通过设定控制机制来克服这些问题。Swift暴露在不完整的写入面前也是如此，write_affinity设置可用于根据多个本地写入来强行使用法定数量。

虽然写入法定数量问题对性能有着巨大的影响，但是它只能在本地存储层面加以解决。

在Swift与Ceph争相成为OpenStack存储方案的较量中，获胜的似乎是Ceph，至少现在是这样。但是想全面地搞清楚OpenStack存储，处理好块IO很重要。OpenStack Cinder项目解决了这个问题，它为一系列广泛的基于SAN和局域网的网络存储提供了前端。像iSCSI这些传统的块IO软件就用在这些设备中。对Cinder而言没有与之竞争的软件架构。

云头条｜未经授权谢绝转载

相关阅读：