“CEPH浅析”系列之三——CEPH的设计思想

分析开源项目，时常遇到的一个问题就是资料不足。有时间写代码的大牛们一般是都是没有时间或者根本不屑于写文档的。而很少的文档一般又是使用手册之类的东西。即使偶尔有设计文档一般也是语焉不详。在这种状况下，想从代码里反向把设计思想提炼出来，毕竟不是人人都能作到的。

值得咱们庆幸的是，Ceph是一个典型的起源于学术研究课题的开源项目。虽然学术研究生涯对于Sage而言只是其光辉事迹的短短一篇，但毕竟仍是有几篇学术文献可供参考[1]。这也为咱们提供了可贵的，从顶层视角入手分析一个系统领域的优秀开源项目的机会。本篇文章的内容也正是笔者阅读这些文献的心得体会。

3.1    Ceph针对的目标应用场景

        理解Ceph的设计思想，首先仍是要了解Sage设计Ceph时所针对的目标应用场景，换言之，“作这东西的目的是啥？”

        事实上，Ceph最初针对的目标应用场景，就是大规模的、分布式的存储系统。所谓“大规模”和“分布式”，是指至少可以承载PB级别的数据，而且由成千上万的存储节点组成。

        在大数据口号深刻人心的今天，PB已经远远不是一个激动人心的系统设计目标了。可是，应该指出，Ceph项目起源于04年。那是一个商用处理器以单核为主流，常见硬盘容量只有几十GB的年代。这和如今动辄6核12线程还要双处理器、单块硬盘3TB已经司空见惯的状况是不可同日而语的。所以，理解这个设计目标，应该考虑当时的实际状况。固然，如前所述，Ceph的设计并无理论上限，因此PB级别并非实际应用的容量限制。

        在Sage的思想中，对于这样一个大规模的存储系统，是不能以静态的眼光来看待的。对于其动态特性，笔者归纳为以下三个“变化”：

• 存储系统规模的变化：这样大规模的存储系统，每每不是在建设的第一天就能预料到其最终的规模，甚至是根本就不存在最终规模这个概念的。只能是随着业务的不断开展，业务规模的不断扩大，让系统承载愈来愈大的数据容量。这也就意味系统的规模天然随之变化，愈来愈大。
• 存储系统中设备的变化：对于一个由成千上万个节点构成的系统，其节点的故障与替换必然是时常出现的状况。而系统一方面要足够可靠，不能使业务受到这种频繁出现的硬件及底层软件问题的影响，同时还应该尽量智能化，下降相关维护操做的代价。
• 存储系统中数据的变化：对于一个大规模的，一般被应用于互联网应用中的存储系统，其中存储的数据的变化也极可能是高度频繁的。新的数据不断写入，已有数据被更新、移动乃至删除。这种场景需求也是设计时必须予以考虑的。

        上述三个“变化”就是Ceph目标应用场景的关键特征。Ceph所具有的各类主要特性，也都是针对这些场景特征所提出的。

3.2    针对目标应用场景所提出的预期技术特性

        针对上述应用场景，Ceph在设计之初的几个技术特性是：

• 高可靠性。所谓“高可靠”，首先是针对存储在系统中的数据而言，也即，尽量保证数据不会丢失。其次，也包括数据写入过程当中的可靠性，也即，在用户将数据写入Ceph存储系统的过程当中，不会由于意外状况的出现形成数据丢失。
• 高度自动化。具体包括了数据的自动replication，自动re-balancing，自动failure detection和自动failure recovery。整体而言，这些自动化特性一方面保证了系统的高度可靠，一方面也保障了在系统规模扩大以后，其运维难度仍能保持在一个相对较低的水平。
• 高可扩展性。这里的“可扩展”概念比较广义，既包括了系统规模和存储容量的可扩展，也包括了随着系统节点数增长的聚合数据访问带宽的线性扩展，还包括了基于功能丰富强大的底层API提供多种功能、支持多种应用的功能性可扩展。

3.3    针对预期技术特性所提出的设计思路

        针对3.2节中介绍的预期技术特性，Sage对于Ceph的设计思路基本上能够归纳为如下两点：

• 充分发挥存储设备自身的计算能力。事实上，采用具备计算能力的设备（最简单的例子就是普通的服务器）做为存储系统的存储节点，这种思路即使在当时来看也并不新鲜。可是，Sage认为这些已有系统基本上都只是将这些节点做为功能简单的存储节点。而若是充分发挥节点上的计算能力，则能够实现前面提出的预期特性。这一点成为了Ceph系统设计的核心思想。
• 去除全部的中心点。一旦系统中出现中心点，则一方面引入单点故障点，另外一方面也必然面临当系统规模扩大时的规模和性能瓶颈。除此以外，若是中心点出如今数据访问的关键路径上，事实上也比然致使数据访问的延迟增大。而这些显然都是Sage所设想的系统中不该该出现的问题。虽然在大多数系统的工程实践中，单点故障点和性能瓶颈的问题能够经过为中心点增长备份加以缓解，但Ceph系统最终采用创新的方法更为完全地解决了这个问题。

3.4    支撑设计思路实现的关键技术创新

        不管多么新颖奇妙的设计思路，最终落地一定须要有技术实力的支撑。而这也正是Ceph最为闪亮的地方。

        Ceph最为核心的技术创新就是前面所归纳的八个字——“无需查表，算算就好”。通常而言，一个大规模分布式存储系统，必需要可以解决两个最基本的问题：

       一是“我应该把数据写入到什么地方”。对于一个存储系统，当用户提交须要写入的数据时，系统必须迅速决策，为数据分配一个存储位置和空间。这个决策的速度影响到数据写入延迟，而更为重要的是，其决策的合理性也影响着数据分布的均匀性。这又会进一步影响存储单元寿命、数据存储可靠性、数据访问速度等后续问题。

        二是“我以前把数据写到什么地方去了”。对于一个存储系统，高效准确的处理数据寻址问题也是基本能力之一。

        针对上述两个问题，传统的分布式存储系统经常使用的解决方案是引入专用的服务器节点，在其中存储用于维护数据存储空间映射关系的数据结构。在用户写入/访问数据时，首先链接这一服务器进行查找操做，待决定/查到数据实际存储位置后，再链接对应节点进行后续操做。因而可知，传统的解决方案一方面容易致使单点故障和性能瓶颈，另外一方面也容易致使更长的操做延迟。

        针对这一问题，Ceph完全放弃了基于查表的数据寻址方式，而改用基于计算的方式。简言之，任何一个Ceph存储系统的客户端程序，仅仅使用不按期更新的少许本地元数据，加以简单计算，就能够根据一个数据的ID决定其存储位置。对比以后能够看出，这种方式使得传统解决方案的问题一扫而空。Ceph的几乎全部优秀特性都是基于这种数据寻址方式实现的。

        至此为止，Ceph的设计思想已经获得了较为全面深刻的介绍。此后几篇文章将依次介绍Ceph的系统架构、工做原理与流程、主要特性等内容，并联系OpenStack，将Ceph和Swift加以对比分析。

说明：转载请注明出处。谢谢。