Ceph浅析（上）：概况与设计思想
【编者按】Ceph，当下已成为OpenStack上最通用的存储之一，也是是目前人气最高的开源存储项目之一。近日，拥有海量存储领域工作经验的华为@一棹凌烟基于现有资料文档的学习思考，以及由此而来的心得体会，对Ceph进行介绍与分析。文章内容大致涵盖Ceph的产生背景、设计思想、技术实现、主要特点、与OpenStack的联系、与Swift的比较等等。
以下为原文：
Ceph的概况
本文将对Ceph的基本情况进行概要介绍，以期读者能够在不涉及技术细节的情况下对Ceph建立一个初步印象。
1. 什么是Ceph？Ceph的官方网站Ceph.com上用如下这句话简明扼要地定义了Ceph：
“Ceph is a unified, distributed storage system designed for excellent performance, reliability and scalability.”
也即，Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式的存储系统。应该说，这句话确实点出了Ceph的要义，可以作为理解Ceph系统设计思想和实现机制的基本出发点。在这个定义中，应当特别注意“存储系统”这个概念的两个修饰词，即“统一的”和“分布式的”。
具体而言，“统一的”意味着Ceph可以一套存储系统同时提供对象存储、块存储和文件系统存储三种功能，以便在满足不同应用需求的前提下简化部署和运维。而“分布式的”在Ceph系统中则意味着真正的无中心结构和没有理论上限的系统规模可扩展性。在实践当中，Ceph可以被部署于上千台服务器上。截至2013年3月初，Ceph在生产环境下部署的最大规模系统为Dreamhost公司的对象存储业务集群，其管理的物理存储容量为3PB。
2. 为什么要关注Ceph？
事实上，Ceph并不是一个刚刚出现的开源项目。与此相反，从最初发布到逐渐流行，Ceph走过了七年以上的漫长路程。笔者以为，之所以应当对Ceph加以了解，其原因大致有两个方面：
首先，Ceph本身确实具有较为突出的优势。
Ceph值得一提的优势颇多，包括统一存储能力、可扩展性、可靠性、性能、自动化的维护等等。本质上，Ceph的这些优势均来源于其先进的核心设计思想，笔者将其概括为八个字――“无需查表，算算就好”。基于这种设计思想，Ceph充分发挥存储设备自身的计算能力，同时消除了对系统单一中心节点的依赖，从而实现了真正的无中心结构。基于这一设计思想和结构，Ceph一方面实现了高度的可靠性和可扩展性，另一方面保证了客户端访问的相对低延迟和高聚合带宽。通过后续内容的介绍，读者可以看到，Ceph几乎所有优秀特性的实现，都与这个核心设计思想有关。
其次，Ceph目前在OpenStack社区中备受重视。
OpenStack是目前最为流行的开源云操作系统。而据笔者观察，Ceph之所以在近一两年间热度骤升，其最为有力的推动因素就是OpenStack社区的实际需求。目前而言，Ceph已经成为OpenStack社区中呼声最高的开源存储方案之一，其实际应用主要涉及块存储和对象存储，并且开始向文件系统领域扩展。这一部分的相关情况，在后续文章中也将进行介绍。
3. Ceph的产生与发展
通常而言，开源项目的来源有三：一是学校里的大牛作的课题，论文发够然后开源；二是企业里的大牛搞的产品，机缘巧合于是开源；三是某些大牛突然显灵，然后一票人跟着一起开源。每一类的例子都有不少，而不同起源的开源项目也有着自身的不同特点。具体而言，第一类项目的原理和技术上很可能颇有独到之处，而Ceph就正在此列。相比之下，第二类项目的设计实现很可能颇为成熟，并且在开源之前或者开源初期就获得生产环境下的实际部署应用机会。这种出身背景上的因素，对于一个开源项目的后续发展很有可能产生影响。
言归正传。Ceph项目起源于其创始人Sage Weil在加州大学Santa Cruz分校攻读博士期间的研究课题。项目的起始时间为2004年。在2006年的OSDI学术会议上，Sage发表了介绍Ceph的论文，并在该篇论文的末尾提供了Ceph项目的下载链接。由此，Ceph开始广为人知。
Ceph使用C++语言开发。对于一个典型的强调性能的系统项目，这一选择可以理解。
作为开源项目，Ceph遵循LGPL协议。
根据Inktank官方网站上的信息，Cpeh的生态系统参加下图：
不难看出，图中列出的厂商或组织带有明显的云计算气息。
随着Ceph的热度不断增加，Sage Weil于 2011年创立了Inktank公司以主导Ceph的开发和社区维护。目前，Ceph的发布周期为三个月。
4. Sage Weil其人其事
在展开后续的技术讨论之前，适度八卦Sage Weil的人生经历实在是很有必要，因为这位兄台委实是 IT男青年中凤毛麟角的在工程、研究、创业三个领域都有涉猎且都颇有建树的神人。
Sage在工程上的能力自然不必多言，而他发表Ceph论文的OSDI也是计算机操作系统领域首屈一指的最高水平学术会议。至于创业方面，Sage是 DreamHost的联合创始人，彼时是1997年，他刚上大学不久。。。有兴趣的同学可以去LinkedIn研究一下Sage的个人简历，基本上是想工作就工作，想上学就上学，想创业就创业，想读博就读博，随心所欲，天马行空，令人油然而生一种表示敬佩的冲动。
Ceph的设计思想
分析开源项目，时常遇到的一个问题就是资料不足。有时间写代码的大牛们通常是都是没有时间或者根本不屑于写文档的。而不多的文档通常又是使用手册之类的东西。即便偶尔有设计文档通常也是语焉不详。在这种情况下，想从代码里反向把设计思想提炼出来，毕竟不是人人都能做到的。
值得我们庆幸的是，Ceph是一个典型的起源于学术研究课题的开源项目。虽然学术研究生涯对于Sage而言只是其光辉事迹的短短一篇，但毕竟还是有几篇学术文献可供参考。这也为我们提供了难得的，从顶层视角入手分析一个系统领域的优秀开源项目的机会。本篇文章的内容也正是笔者阅读这些文献的心得体会。
1. Ceph针对的目标应用场景
理解Ceph的设计思想，首先还是要了解Sage设计Ceph时所针对的目标应用场景，换言之，“做这东西的目的是啥？”
事实上，Ceph最初针对的目标应用场景，就是大规模的、分布式的存储系统。所谓“大规模”和“分布式”，是指至少能够承载PB级别的数据，并且由成千上万的存储节点组成。
在大数据口号深入人心的今天，PB已经远远不是一个激动人心的系统设计目标了。但是，应该指出，Ceph项目起源于04年。那是一个商用处理器以单核为主流，常见硬盘容量只有几十GB的年代。这和现在动辄6核12线程还要双处理器、单块硬盘3TB已经司空见惯的情况是不可同日而语的。因此，理解这个设计目标，应该考虑当时的实际情况。当然，如前所述，Ceph的设计并没有理论上限，所以PB级别并不是实际应用的容量限制。
在Sage的思想中，对于这样一个大规模的存储系统，是不能以静态的眼光来看待的。对于其动态特性，笔者概括为如下三个“变化”：
- 存储系统规模的变化：这样大规模的存储系统，往往不是在建设的第一天就能预料到其最终的规模，甚至是根本就不存在最终规模这个概念的。只能是随着业务的不断开展，业务规模的不断扩大，让系统承载越来越大的数据容量。这也就意味系统的规模自然随之变化，越来越大。
- 存储系统中设备的变化：对于一个由成千上万个节点构成的系统，其节点的故障与替换必然是时常出现的情况。而系统一方面要足够可靠，不能使业务受到这种频繁出现的硬件及底层软件问题的影响，同时还应该尽可能智能化，降低相关维护操作的代价。
- 存储系统中数据的变化：对于一个大规模的，通常被应用于互联网应用中的存储系统，其中存储的数据的变化也很可能是高度频繁的。新的数据不断写入，已有数据被更新、移动乃至删除。这种场景需求也是设计时必须予以考虑的。
上述三个“变化”就是Ceph目标应用场景的关键特征。Ceph所具备的各种主要特性，也都是针对这些场景特征所提出的。
2. 针对目标应用场景所提出的预期技术特性
针对上述应用场景，Ceph在设计之初的几个技术特性是：
- 高可靠性。所谓“高可靠”，首先是针对存储在系统中的数据而言，也即，尽可能保证数据不会丢失。其次，也包括数据写入过程中的可靠性，也即，在用户将数据写入Ceph存储系统的过程中，不会因为意外情况的出现造成数据丢失。
- 高度自动化。具体包括了数据的自动replication，自动re-balancing，自动failure detection和自动failure recovery。总体而言，这些自动化特性一方面保证了系统的高度可靠，一方面也保障了在系统规模扩大之后，其运维难度仍能保持在一个相对较低的水平。
- 高可扩展性。这里的“可扩展”概念比较广义，既包括了系统规模和存储容量的可扩展，也包括了随着系统节点数增加的聚合数据访问带宽的线性扩展，还包括了基于功能丰富强大的底层API提供多种功能、支持多种应用的功能性可扩展。
3. 针对预期技术特性所提出的设计思路
针对3.2节中介绍的预期技术特性，Sage对于Ceph的设计思路基本上可以概括为以下两点：
- 充分发挥存储设备自身的计算能力。事实上，采用具有计算能力的设备（最简单的例子就是普通的服务器）作为存储系统的存储节点，这种思路即便在当时来看也并不新鲜。但是，Sage认为这些已有系统基本上都只是将这些节点作为功能简单的存储节点。而如果充分发挥节点上的计算能力，则可以实现前面提出的预期特性。这一点成为了Ceph系统设计的核心思想。
- 去除所有的中心点。一旦系统中出现中心点，则一方面引入单点故障点，另一方面也必然面临当系统规模扩大时的规模和性能瓶颈。除此之外，如果中心点出现在数据访问的关键路径上，事实上也比然导致数据访问的延迟增大。而这些显然都是Sage所设想的系统中不应该出现的问题。虽然在大多数系统的工程实践中，单点故障点和性能瓶颈的问题可以通过为中心点增加备份加以缓解，但Ceph系统最终采用创新的方法更为彻底地解决了这个问题。
4. 支撑设计思路实现的关键技术创新
无论多么新颖奇妙的设计思路，最终落地必定需要有技术实力的支撑。而这也正是Ceph最为闪亮的地方。
Ceph最为核心的技术创新就是前面所概括的八个字――“无需查表，算算就好”。一般而言，一个大规模分布式存储系统，必须要能够解决两个最基本的问题：
一是“我应该把数据写入到什么地方”。对于一个存储系统，当用户提交需要写入的数据时，系统必须迅速决策，为数据分配一个存储位置和空间。这个决策的速度影响到数据写入延迟，而更为重要的是，其决策的合理性也影响着数据分布的均匀性。这又会进一步影响存储单元寿命、数据存储可靠性、数据访问速度等后续问题。
二是“我之前把数据写到什么地方去了”。对于一个存储系统，高效准确的处理数据寻址问题也是基本能力之一。
针对上述两个问题，传统的分布式存储系统常用的解决方案是引入专用的服务器节点，在其中存储用于维护数据存储空间映射关系的数据结构。在用户写入/访问数据时，首先连接这一服务器进行查找操作，待决定/查到数据实际存储位置后，再连接对应节点进行后续操作。由此可见，传统的解决方案一方面容易导致单点故障和性能瓶颈，另一方面也容易导致更长的操作延迟。
针对这一问题，Ceph彻底放弃了基于查表的数据寻址方式，而改用基于计算的方式。简言之，任何一个Ceph存储系统的客户端程序，仅仅使用不定期更新的少量本地元数据，加以简单计算，就可以根据一个数据的ID决定其存储位置。对比之后可以看出，这种方式使得传统解决方案的问题一扫而空。Ceph的几乎所有优秀特性都是基于这种数据寻址方式实现的。
原文连接：
“Ceph浅析”系列之二――Ceph概况
“Ceph浅析”系列之三――Ceph的设计思想
以“
云计算大数据 推动智慧中国 ”为主题的
第六届中国云计算大会 将于5月20-23日在北京国家会议中心隆重举办。产业观察、技术培训、主题论坛、行业研讨，内容丰富，干货十足。票价优惠，马上
报名 ！