1.3 Ceph架构和设计思想
1. Ceph架构
Ceph底层核心是RADOS。Ceph架构图如图1-3所示。
图1-3 Ceph架构图
RADOS：RADOS具备自我修复等特性，提供了一个可靠、自动、智能的分布式存储。
LIBRADOS：LIBRADOS库允许应用程序直接访问，支持C/C++、Java和Python等语言。
RADOSGW：RADOSGW 是一套基于当前流行的RESTful协议的网关，并且兼容S3和Swift。
RBD：RBD通过Linux 内核（Kernel）客户端和QEMU/KVM驱动，来提供一个完全分布式的块设备。
Ceph FS：Ceph FS通过Linux内核（Kernel）客户端结合FUSE，来提供一个兼容POSIX的文件系统。
具体的RADOS细节以及RADOS的灵魂CRUSH（Controlled Replication Under Scalable Hashing，可扩展哈希算法的可控复制）算法，这两个知识点会在后面的第2、3章详细介绍和分析。
2. Ceph设计思想
Ceph是一个典型的起源于学术研究课题的开源项目。虽然学术研究生涯对于Sage而言只是其光辉事迹的短短一篇，但毕竟还是有几篇学术论文可供参考的。可以根据Sage的几篇论文分析Ceph的设计思想。
理解Ceph的设计思想，首先还是要了解Sage设计Ceph时所针对的应用场景，换句话说，Sage当初做Ceph的初衷的什么？
事实上，Ceph最初针对的应用场景，就是大规模的、分布式的存储系统。所谓“大规模”和“分布式”，至少是能够承载PB级别的数据和成千上万的存储节点组成的存储集群。
如今云计算、大数据在中国发展得如火如荼，PB容量单位早已经进入国内企业存储采购单，DT时代即将来临。Ceph项目起源于2004年，那是一个商用处理器以单核为主流，常见硬盘容量只有几十GB的年代。当时SSD也没有大规模商用，正因如此，Ceph之前版本对SSD的支持不是很好，发挥不了SSD的性能。如今Ceph高性能面临的最大挑战正是这些历史原因，目前社区和业界正在逐步解决这些性能上的限制。
在Sage的思想中，我们首先说一下Ceph的技术特性，总体表现在集群可靠性、集群扩展性、数据安全性、接口统一性4个方面。
集群可靠性：所谓“可靠性”，首先从用户角度来说数据是第一位的，要尽可能保证数据不会丢失。其次，就是数据写入过程中的可靠性，在用户将数据写入Ceph存储系统的过程中，不会因为意外情况出现而造成数据丢失。最后，就是降低不可控物理因素的可靠性，避免因为机器断电等不可控物理因素而产生的数据丢失。
集群可扩展性：这里的“可扩展”概念是广义的，既包括系统规模和存储容量的可扩展，也包括随着系统节点数增加的聚合数据访问带宽的线性扩展。
数据安全性：所谓“数据安全性”，首先要保证由于服务器死机或者是偶然停电等自然因素的产生，数据不会丢失，并且支持数据自动恢复，自动重平衡等。总体而言，这一特性既保证了系统的高度可靠和数据绝对安全，又保证了在系统规模扩大之后，其运维难度仍能保持在一个相对较低的水平。
接口统一性：所谓“接口统一”，本书开头就说到了Ceph可以同时支持3种存储，即块存储、对象存储和文件存储。Ceph支持市面上所有流行的存储类型。
根据上述技术特性以及Sage的论文，我们来分析一下Ceph的设计思路，概述为两点：充分发挥存储本身计算能力和去除所有的中心点。
充分发挥存储设备自身的计算能力：其实就是采用廉价的设备和具有计算能力的设备（最简单的例子就是普通的服务器）作为存储系统的存储节点。Sage认为当前阶段只是将这些服务器当做功能简单的存储节点，从而产生资源过度浪费（如同虚拟化的思想一样，都是为了避免资源浪费）。而如果充分发挥节点上的计算能力，则可以实现前面提出的技术特性。这一点成为了Ceph系统设计的核心思想。
去除所有的中心点：搞IT的最忌讳的就是单点故障，如果系统中出现中心点，一方面会引入单点故障，另一方面也必然面临着当系统规模扩大时的可扩展性和性能瓶颈。除此之外，如果中心点出现在数据访问的关键路径上，也必然导致数据访问的延迟增大。虽然在大多数存储软件实践中，单点故障点和性能瓶颈的问题可以通过为中心点增加HA或备份加以缓解，但Ceph系统最终采用Crush、Hash环等方法更彻底地解决了这个问题。很显然Sage的眼光和设想还是很超前的。
