“CEPH浅析”系列之六——CEPH与OPENSTACK

在 《“Ceph浅析”系列之二——Ceph概况》中即已提到，关注Ceph的缘由之一，就是OpenStack社区对于Ceph的重视。所以，本文将对Ceph在OpenStack中的价值进行简要介绍，而且对Ceph和Swift进行对比。

Ceph在OpenStack中的地位

对于一个IaaS系统，涉及到存储的部分主要是块存储服务模块、对象存储服务模块、镜像管理模块和计算服务模块。具体针对OpenStack而言，则分别对应为其中的Cinder、Swift、Glance和Nova四个项目[1]。

在块存储服务部分，Ceph目前是Cinder项目的默认存储后端。前已述及，Red Hat也已经利用本身在KVM/QEMU社区中的影响力，将RBD驱动直接集成在QEMU中。这样，虚拟机访问基于RBD实现的块设备的性能将获得优化。

在对象存储部分，Swift是OpenStack自带的对象存储实现方案。但Ceph也已经成为了Swift最强有力的竞争对手。目前Swift也在考虑采用Ceph做为本身的存储后端。关于Ceph和Swift的故事将在6.2节详细展开。

在镜像管理部分，目前Glance已经支持将Ceph做为本身的本地镜像文件缓存。

在计算服务部分，United Stack目前正在推进将Ceph FS做为Nova计算节点的本地文件系统。

总体而言，Ceph事实上是目前OpenStack生态系统中呼声最高的开源存储解决方案。这一点从笔者在OpenStack 2013 HongKong Summit上的亲身体验能够获得印证。目前，以HP、Dell、Intel等为表明的企业IT领导厂商，和以Mirantis、eNovance、United Stack为表明的若干OpenStack社区新兴厂商，都将Ceph做为重要的乃至于首选的开源存储解决方案。

笔者认为，Ceph之因此在诞生多年不温不火的状况下，迅速在OpenStack社区中受到关注，除了其余一些明显优势以外，应该仍是和其支持统一存储的能力有关。这一特性偏偏是OpenStack社区所须要的。

OpenStack项目设计的准则之一就是灵活可扩展。同时，其各个成员项目的背景也不尽相同。这也就致使各个项目在涉及存储系统时所采起的选择各有差别。可是，这一现状势必致使OpenStack的部署和运维面临必定的挑战。特别是对于一些规模不大的OpenStack部署实例，若是让块存储、对象存储、镜像缓存、计算节点本地存储等模块分别采用三四种不一样的后端解决方案，则一方面其部署十分麻烦，另外一方面运维人员的后续工做也很繁琐。在这种状况下，若是可以采用Ceph做为一种统一存储后端，则确实能够有效缓解这一问题。固然，这只是笔者的一家直言。任何技术选择必然都有其复杂的背后缘由，这里的信息仅供参考。

Ceph与Swift：不能不说的故事，不能不做的比较

首先对Swift项目的前因后果进行简单介绍，以便你们更好地了解这个项目的特性，及其背后隐藏的缘由。此处关于Swift的信息主要引自[2]。

Swift最先起源于2008年，原本是Rackspace公司内部开发的用于支撑其公有云对象存储业务的后端系统。当时，Amazon的S3服务已经颇受欢迎，所以，Rackspace决定开发Swift以提供对应业务做为回应。也正是由于这个缘由，Swift的设计目标十分纯粹，就是一个优秀的、能够和S3相媲美的对象存储系统。其余要求纯属多余，所以彻底不在Swift开发者的考虑之列。

Swift的开发大体历时一年，并在Rackspace成功上线运营。此后，OpenStack项目于2010年正式发布。Rackspace贡献了Swift，而NASA贡献了Nova，两者成为了OpenStack最先的两个项目。其后，若干Swift开发团队的核心成员独立创业，成立了SwiftStack公司，依然活跃在相关社区。

因而可知，Swift正是一个典型的起源于公司内部的、做为正式产品开发的开源项目。从这一点而言，Swift和“学院范儿”的Ceph可谓大相径庭。也正是由于这个缘由，Swift得到了一个得天独厚的优点：不缺启动用户，一开始就有生产环境下的大规模部署应用案例。事实上，相对成熟、web场景下应用案例多，是Swift社区目前依然反复强调的一个优点。

从技术上讲，Swift的特色主要体如今设计目标明确，就是要作一个纯粹的对象存储系统，所以不会考虑Ceph所强调的统一存储特性。同时，为了便于和其余项目、应用集成，Swift选择了Python语言进行开发。

与之相比，Ceph同时考虑了对象存储、块存储和文件系统存储能力，且目前在OpenStack中应用最多的场景事实上是块存储。同时，Ceph在选择开发语言时，极可能主要考虑的是性能因素，于是选择了C++语言。而可以被用于块存储场景这一点，也部分印证了其性能确实比较优秀。

因而可知，Ceph和Swift的区别，本质上是由其产生背景和应用目标所致使的。对这两者进行对比，并进行技术上的评判，并不很是公平。

事实上，做为开源分布式存储系统中的两个优秀表明，Ceph和Swift的设计和特性之中，也有着很多的相通之处：

首先，两者都强调良好的可扩展性，所以都采用了无中心点结构。只不过Swift的架构中有元数据服务器，只是经过多节点扩展的方式尽量解决了其可靠性和性能顾虑。

第二，两者都能提供可配置的高可靠性。在二者的集群中，数据的备份数均可以选择，在常见生产环境中，也都使用三备份的方式。

第三，两者都强调自动化的集群管理。Swift一样引入了自动化的集群维护能力。

因而可知，简单地强调这二者之中的某一个更为优秀，是不合理的，也是没有实际意义的。

固然，在实际使用中，毕竟仍是须要进行方案选择。结合[3]文中的观点，笔者认为，合适的选择或许以下：

*若是须要一个纯粹的对象存储系统，则选择Swift；

*若是须要一个纯粹的块存储系统，则只能选择Ceph；

*若是是一个小规模的、但愿控制系统复杂度的OpenStack部署方案，则选择Ceph；

*若是是一个规模较大的系统，块存储和对象存储分别有较大的业务需求，则能够考虑将两者分离，分别采用Ceph和Swift。

到本篇为止，这一系列文章对于Ceph技术内容的介绍已经基本完成。后面一篇文章，将主要是笔者学习Ceph过程当中的一些思考，供有兴趣的读者一同品评。