Ceph浅析（下）

转载自华为章宇的文章：http://www.csdn.net/article/2014-04-10/2819247-how-to-learn-opensouce-project-%26-ceph/2

作为OpenStack的人气存储技术之一，Ceph与Swift和GlusterFS一样有着各自的优势：GlusterFS更适合Hadoop类型的服务；Swift适合更多人访问；Ceph的未来更被看好，并已得到许多知名机构的支持，比如CERN和天河2。

在之前，我们已经分享过章宇Ceph系列博文的前两部分“ Ceph浅析（上）：概况与设计思想”与“Ceph浅析（中）：结构、工作原理及流程”，这里我们将分享该系列博文的最后一部分：

Ceph与OpenStack

在前文概况中即已提到，关注Ceph的原因之一，就是OpenStack社区对于Ceph的重视。因此，本文将对Ceph在OpenStack中的价值进行简要介绍，并且对Ceph和Swift进行对比。

1. Ceph在OpenStack中的地位

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

在块存储服务部分，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作为一种统一存储后端，则确实可以有效缓解这一问题。当然，这只是笔者的一家直言。任何技术选择必然都有其复杂的背后原因，这里的信息仅供参考。

2. Ceph与Swift：不能不说的故事，不能不作的比较

首先对Swift项目的来龙去脉进行简单介绍，以便大家更好地了解这个项目的特性，及其背后隐藏的原因。此处关于Swift的信息主要引自。

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过程中产生的一些思考。因为其中的内容比较自由发散，且大多是笔者的个人见解，故此另启一文进行讨论。

1. 关于Ceph的性能

目前为止，本系列的文章中没有涉及到Ceph性能的详细讨论，也没有给出任何的Ceph性能数据。原因很简单：笔者本人没有机会进行详尽的Ceph性能分析研究，也没有见到比较全面的相关数据。因此，为了避免以片面的数据误导读者，便没有提供任何信息。

以笔者个人的经验而言，探讨一个系统领域的开源项目的性能，事实上并不容易。其原因在于，影响一个实际部署中系统的性能好坏的因素太多、太复杂。硬件配置、软件版本、参数调整、应用负载及场景设置，各个方面的因素变化都会导致性能测试结果的不同。因此，很难一言蔽之，认为某个项目的性能是好还是不好。

举一个不直接相关的例子。在hypervisor领域，大家很可能会倾向于认为ESXi的性能优于KVM，但事实上，在SPECvirt性能测试结果排行榜上，基于KVM的系统常有高居第一的时候。究其原因，除了硬件性能的因素之外，KVM有大量的配置参数可以调整，而调得好与不好会极其明显地影响系统性能。

又比如常用的开源大数据工具软件Hadoop。同一个Hadoop集群用同样的应用程序处理同样的数据集，在配置参数不同的情况下，其最终运行时间长度可能相差数倍。

正是因为参数配置、硬件规格、软件版本、应用场景等因素都可能对性能产生明显影响，因此，对于Ceph这样一个部署方案多变、配置参数不少的系统，如何评测其系统性能，是需要审慎思考的

反过来讲，这倒也是开源软件引出的一个生财之道。虽然软件本身是开源的，大家都可以免费下载免费安装，但能不能用好就要依靠精深的专业技能了。类似的公司国外屡见不鲜，而国内也已经开始出现。

2. Ceph的架构与硬件平台之间的适应性

Ceph自2006年正式发布以来，其基础架构（RADOS）部分并没有发生大的变化。本质上，这还是因为RADOS的设计确实优秀，有其前瞻性，因此没有必要大动筋骨。但这并不意味着没有必要对其进行适当反思。

如前所述，2006年的时候，商用处理器的主流仍为单核，单条内存和单块硬盘的容量也都远小于现在的主流水平。但是，OSD的基本硬件资源要求并没有发生变化。这也就意味着，在目前的典型部署方案中，一台物理服务器上很可能有数十个处理器硬件线程、数十块硬盘，于是也就承载着数十个OSD同时运行。然而，RADOS结构的基本假定是，集群是由大量的、相互独立运行的OSD组成的，则目前的典型硬件方案有可能影响这种假定的有效性。例如，如果一台服务器出现故障，必须关机进行维修，则意味着数十个OSD一起突然下线。由此受到影响的PG则可能多达成千上万个。这种突发性的事件对系统的自动化维护机制可能会造成一定的压力。

由此，笔者想到，Sage设计Ceph时面对的硬件平台，事实上应该是处理能力不需要过强、硬件规格比较简单的系统。而这种系统可能与目前的ARM架构或者Intel Atom架构的micro-server更为相似。或许，基于micro-server部署Ceph集群，会是一种值得尝试的方向。

此外，华为和希捷合作推出了IP硬盘产品。虽然还缺乏更进一步的了解，但直观上推测，这种全新的、轻量级、智能化的存储设备，可能也是一种非常近似于Sage当年设想中的OSD的硬件平台。

3. Ceph与软件定义存储

“软件定义”这四个字可谓是目前最炙手可热、也最让人糊涂的概念之一。软件定义计算、软件定义网络、软件定义存储、软件定义数据中心，以上几个可能是目前最为常见的相关名词了。

到底什么是“软件定义”，现在还没有形成完全一致的见解。并且，参考技术发展史上的若干先例，以后也未必能形成所谓的一致见解。在这种情况下，以一个具体实例入手，可能更容易获得直观认识，并由此建立起更系统的观点。

笔者认为，对于任何一个系统而言，“软件定义”的概念，更多体现在这里：这个系统的哪些特性，比如功能或者性能，以前是固定的，或者只能进行有限的配置，而现在则可以进行方便灵活地定义和改变。

例如，对于一台物理服务器，一旦其硬件配置，如CPU、内存、硬盘等连接好，则这台服务器的规格和性能就确定了，能够通过BIOS配置等方式调整的性能和功能范围是很有限的。但是，对于一台虚拟机而言，即便在虚拟机已经创建并安装了操作系统之后，其CPU核数及处理能力、逻辑物理内存大小及真实物理内存大小、硬盘数量容量及读写性能、网卡型号数量及网络带宽等等特性都是可以方便灵活地通过软件方式进行控制和改变的（其中部分配置操作需要对虚拟机进行重启才能生效），且这种配置可以由应用层软件进行控制。两相对比，则虚拟机的这种可定义性就是软件定义计算的一个直观实例。

下面再具体到存储领域加以讨论。一般而言，一个存储系统的主要特性大致包括：存储类型（文件系统？块存储？对象存储？），存储容量，存储性能（访问带宽、访问延迟等等），存储策略（备份策略、访问安全性策略、对数据的高级处理功能等等）。参考上面所举出的软件定义计算的例子，可以想见，对于一个软件定义存储系统而言，这些特性（至少是其中的大多数）都应该是可以通过软件方式加以定义的。

具体到Ceph而言，其最为符合软件定义存储的特性无疑是，Ceph的存储类型是可以通过软件方式定义的。同样的一个RADOS集群，可以通过安装不同的上层软件和对应的客户端程序，实现块存储、对象存储和文件系统存储功能，这一特性对于传统的存储系统难以想象。除此之外，Ceph的存储策略，如备份策略、后台数据处理功能等，也都可以方便地通过软件方式加以定义或扩展。因此，从这个角度出发，Ceph也可以被认为是软件定义存储的真实案例之一。

4. Ceph与数据中心计算

传统意义上，计算系统的设计是以计算为中心的。数据从存储、网络或其他设备流入处理器，经过处理后再流向存储、网络或其他设备。然而，随着待处理的数据量以爆炸式的速度增大，也随着计算能力提高的速度超过存储和传输能力，这一处理方式可能变得不再经济，因为针对大量的数据进行频繁硬盘存取和网络传输的代价都是非常可观的。

数据中心计算这一概念，也就是在这种背景下被提出的。其核心思想，也就是让计算在数据所在的地方发生。数据在哪里，就把计算任务发送到哪里去执行，而不要再为了使用“强大”的计算能力把数据搬来搬去，传来传去。事实上，Hadoop的出现，就是这种数据中心计算思想的现实反映。

数据中心计算的另一实例，是目前OpenStack社区中出现的一种叫做ZeroVM的轻量级虚拟化技术。ZeroVM的思想就是让计算发生在数据所在的地方。基于其官方提供的信息，目前已经实现了ZeroVM和Swift的整合，可以让处理任务直接运行在Swift的服务器端。

事实上，Ceph也提供了同样的能力。Ceph的整个设计，都是基于Sage的一个基本思想：充分发挥存储器件自身的计算能力。这种思想不仅使得OSD可以相互配合完成数据访问操作和集群维护功能，更允许OSD将富余的计算能力提供出来，用于运行数据处理任务。

目前，RADOS提供的机制允许在OSD上直接运行可动态加载的数据处理程序插件，以便在服务器端进行数据处理工作，例如，对图片存储系统中的图片进行自动加水印、尺寸和格式自动转换等后台操作。事实上，基于这种能力，也完全可以实现类似于Hadoop的大数据处理系统。

对于大数据而言，存储和处理是其两个关键的技术领域。由于Ceph自身就是优秀的存储系统，又具备直接承载计算任务的能力，因此，面向大数据的数据中心计算很可能是Ceph的潜在应用方向之一。

5. Ceph在实际应用中可能存在的问题

到目前位置，本系列文章基本上都是在介绍Ceph的各种优势与特长。但是，任何系统都不可能是十全十美的，本着鸡蛋里挑骨头、吹毛求疵的精神，还是要在这里吐槽几句。

从非技术角度出发，Ceph的最大问题是火起来的时间不够长，因此可以参考的文档还不是很多，中文的尤其如此。但这个没有办法，只能众人拾柴火焰高，一点一滴作贡献。

此外，对Ceph诟病最多的可能还是不够成熟云云。但一个开源项目总是用得人多了才会成熟的，而Ceph目前正在这个过程中，所以需要的还是时间和参与。

另外，以笔者的感觉，Ceph的高度自动化可能也是个双刃剑。好处固然是很多的，但弊端就是系统的运行状态不完全在管理员控制之下，系统中会有若干自动触发而不是管理员触发的操作。这个特点可能会给系统状态的监测和控制带来一些复杂度，需要管理员去适应。

6. 基于Ceph的产业需求和可能的商业机会

特此声明：这一节的内容纯属crazy idea，不构成投资建议:-)

首先，Ceph的安装部署和性能优化必然成为突出的需求。因此，将Ceph和商用服务器整合成易于部署、性能出色的各类存储解决方案，应该是可以考虑的方向之一。

同时，由于Ceph自身对于OSD硬件平台的特殊假设，以及由此导致的优化空间，则在成本合理的前提下，开发更加适用于Ceph OSD的定制硬件平台（类似于micro-server或者IP硬盘等），并突出存储的高密度、低功耗、高可维护性等特点，也可能成为一种选择。

此外，针对Ceph集群的专用集群监控、性能分析等工具软件也可能会有一定的需求。

最后，基于Ceph的后台数据处理软件工具包也值得考虑。

总结

之 所以花这么多时间在这些文章上，归根结底还是因为Ceph是个有意思的东西，多看一看，多想一想，总能有些新收获，很有趣。即便Ceph最终不能大红大 紫，凭着其精彩的设计思想和巧妙的技术实现，应该还是会在存储技术领域留下一笔的。如果Ceph能够借着OpenStack的东风，逐渐走向成熟，并受到 更为广泛的接受和应用，则更是研究、工程、应用相互贯通的一个经典案例，值得认真研究。因此，无论从哪个角度出发，关注Ceph都是值得的。