Ceph浅析系列之二——Ceph的设计思想

Ceph针对的目标应用场景

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

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

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

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

存储系统规模的变化：这样大规模的存储系统，往往不是在建设的第一天就能预料到其最终的规模，甚至是根本就不存在最终规模这个概念的。只能是随着业务的不断开展，业务规模的不断扩大，让系统承载越来越大的数据容量。这也就意味系统的规模自然随之变化，越来越大。

存储系统中设备的变化：对于一个由成千上万个节点构成的系统，其节点的故障与替换必然是时常出现的情况。而系统一方面要足够可靠，不能使业务受到这种频繁出现的硬件及底层软件问题的影响，同时还应该尽可能智能化，降低相关维护操作的代价。

存储系统中数据的变化：对于一个大规模的，通常被应用于互联网应用中的存储系统，其中存储的数据的变化也很可能是高度频繁的。新的数据不断写入，已有数据被更新、移动乃至删除。这种场景需求也是设计时必须予以考虑的。

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

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

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

高可靠性。所谓“高可靠”，首先是针对存储在系统中的数据而言，也即，尽可能保证数据不会丢失。其次，也包括数据写入过程中的可靠性，也即，在用户将数据写入Ceph存储系统的过程中，不会因为意外情况的出现造成数据丢失。

高度自动化。具体包括了数据的自动replication，自动re-balancing，自动failure detection和自动failure recovery。总体而言，这些自动化特性一方面保证了系统的高度可靠，一方面也保障了在系统规模扩大之后，其运维难度仍能保持在一个相对较低的水平。

高可扩展性。这里的“可扩展”概念比较广义，既包括了系统规模和存储容量的可扩展，也包括了随着系统节点数增加的聚合数据访问带宽的线性扩展，还包括了基于功能丰富强大的底层API提供多种功能、支持多种应用的功能性可扩展。

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

针对3.2节中介绍的预期技术特性，Sage对于Ceph的设计思路基本上可以概括为以下两点：

充分发挥存储设备自身的计算能力。事实上，采用具有计算能力的设备（最简单的例子就是普通的服务器）作为存储系统的存储节点，这种思路即便在当时来看也并不新鲜。但是，Sage认为这些已有系统基本上都只是将这些节点作为功能简单的存储节点。而如果充分发挥节点上的计算能力，则可以实现前面提出的预期特性。这一点成为了Ceph系统设计的核心思想。

去除所有的中心点。一旦系统中出现中心点，则一方面引入单点故障点，另一方面也必然面临当系统规模扩大时的规模和性能瓶颈。除此之外，如果中心点出现在数据访问的关键路径上，事实上也必然导致数据访问的延迟增大。而这些显然都是Sage所设想的系统中不应该出现的问题。虽然在大多数系统的工程实践中，单点故障点和性能瓶颈的问题可以通过为中心点增加备份加以缓解，但Ceph系统最终采用创新的方法更为彻底地解决了这个问题。

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

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

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

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

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

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

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

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