分布式存储ceph：体系结构

Ceph最初针对的目标应用场景，就是大规模的、分布式的存储系统。Ceph需要很好地适应这样一个大规模存储系统的动态特性。

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

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

·　存储系统中数据的变化：对于一个大规模的通常被应用于互联网应用中的存储系统，存储其中的数据的变化也很可能是高度频繁的。新的数据不断被写入，已有数据被更新、移动或删除。

为了适应这种动态变化的应用场景，Ceph在设计时就预期要具有如下技术特性。

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

·　高度自动化。具体包括数据的自动复制、自动再平衡、自动故障检测（Failure Detection）和自动故障恢复（Failure Recovery）。总体而言，这些自动化特性一方面保证了系统的高度可靠，另一方面也保证了在系统规模扩大之后，其运维难度仍能保持在一个相对较低的水平。

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

针对上述技术特性， Ceph的设计思路基本上可以概括为以下两点。

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

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

一般而言，一个大规模分布式存储系统，必须要能够解决两个最基本的问题。

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

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

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

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

Ceph体系结构

首先作为一个存储系统，Ceph在物理上必然包含一个存储集群，以及访问这个存储集群的应用或客户端。Ceph客户端又需要一定的协议与Ceph存储集群进行交互，Ceph的逻辑层次演化如图所示。

1. Ceph存储集群

Ceph基于可靠的、自动化的、分布式的对象存储（Reliable，Autonomous，Distributed Object Storage，RADOS）提供了一个可无限扩展的存储集群。RADOS，顾名思义，这一层本身就是一个完整的对象存储系统，所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。而Ceph的高可靠、高可扩展、高性能、高自动化等特性本质上也是由这一层提供的。因此，理解RADOS是理解Ceph的基础与关键。

物理上，RADOS由大量的存储设备节点组成，每个节点拥有自己的硬件资源（CPU、内存、硬盘、网络），并运行着操作系统和文件系统。

2）基础库librados

Ceph客户端用一定的协议和存储集群进行交互，Ceph 把此功能封装进了librados库，这样基于librados库我们就能创建自己的定制客户端了。

librados库实际上是对RADOS进行抽象和封装，并向上层提供API的，以便可以基于RADOS（而不是整个Ceph）进行应用开发。特别要注意的是，RADOS是一个对象存储系统，因此，librados库实现的API也只是针对对象存储功能的。

RADOS采用C++语言进行开发，所提供的原生librados API包括C语言和C++语言两种。在物理上，librados和基于其上开发的应用位于同一台机器中，因而也被称为本地API。应用调用本机上的librados API，再由后者通过socket与RADOS集群中的节点通信并完成各种操作。

3）高层应用接口RADOS GW、RBD与Ceph FS

这一层的作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。

Ceph对象网关RADOS GW（RADOS Gateway）是一个构建在librados库之上的对象存储接口，为应用访问Ceph集群提供了一个与Amazon S3和Swift兼容的RESTful风格的网关。

RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建存储卷。Red Hat已经将RBD驱动集成在KVM/QEMU中，以提高虚拟机的访问性能。

Ceph FS是一个可移植操作系统接口兼容的分布式存储系统，使用Ceph存储集群来存储数据。

4）应用层

这一层包含的是在不同场景下对应Ceph各个应用接口的各种应用方式。例如，基于librados库直接开发的对象存储应用，基于RADOS GW开发的对象存储应用，基于RBD实现的云硬盘，等等。