前面两篇Ceph系列介绍了Ceph集群的搭建以及通过3种不同的接口（快存储、文件存储、对象存储）去调用Ceph的存储空间。


本篇介绍一下Ceph的原理，各部分的组件与架构，不能知其然不知其所以然。


1、Ceph简介

传统的集中式存储（磁盘阵列），每套存储，需要有一个大脑（控制柜），通常大脑的组件都是冗余配置的（双电源、双控制器、硬盘等），而大脑后面可以接入很多硬盘（硬盘扩展柜，没有控制器，整个机框都插满硬盘）。由于磁盘阵列会有一定的冗余保护机制（如会预留热备盘，磁盘做raid5、raid6、raid10，划逻辑卷等），并且可以通过扩容硬盘扩展柜，来做到容量的增加，并且由于存储数据集中存放，有效给多台服务器进行数据共享。

因此，很长一段时间以来，集中式存储都是存储最优的解决方案。

但是，随着互联网与移动互联网的爆发式增长，传统集中式存储的弊端开始展露。因为每套存储虽然可以扩容硬盘扩展柜，但是控制器无法扩容。而控制器则限制了整套存储能够使用的IO性能，因此可以说，从一开始选定了控制器的型号，基本上这套存储的性能上限就已经决定了。

当然，控制器理论上也是可以扩容的，但是需要再买一套，将2套打通，而打通的要求，则要求同品牌，甚至同型号甚至有的需要同版本号的才能够进行打通。因此使用人就会被一家厂商绑死，而如果买了不同品牌的存储，又面临无法打通的问题。所以可以说存储扩容上面（主要是扩性能，不是容量）是非常麻烦的。

而随着x86服务器越来越便宜，性能与稳定性越来越高，所有的东西都有趋向依靠大量x86服务器集群+软件去实现。分布式存储就是为了解决上述可扩展性的问题而推出的。

Ceph正是其中的一种可以是用x86服务器搭建分布式存储的开源软件。


2、Ceph架构

001.jpeg

Ceph本身有叫RADOS的对象存储系统，负责最终的数据存储。

而其上又提供块存储、文件存储与对象存储接口，供client进行调用，因此使用Ceph，最终可以提供分布式的块存储、文件存储、对象存储服务。


3、Ceph核心组件

Monitor

一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据。

OSD

OSD全称Object Storage Device，也就是负责响应客户端请求返回具体数据的进程。一个Ceph集群一般都有很多个OSD。

上述两者，是实际需要节点进行承载服务的。

Monitor类似大脑（也可以集群部署，才能高可用），用户访问，需要先向Monitor去询问数据在哪里，需要找哪个OSD去找数据。然后Monitor会根据元数据找到哪些OSD节点上面有用户需要的数据，并且根据OSD的负载情况，指导用户现在应该去找哪个OSD去读写数据。

基本上你会发现所有分布式系统，都会有以上两层的分法，只是叫法可能不一样。

例如超融合服务器，存储层面就会出现什么NameNode与DataNode，其实就是类似一个负责存储数据到底摆放在哪里的目录索引，一个负责实际摆放数据进磁盘。

Object

Ceph最底层的存储单元是Object对象，每个Object包含元数据和原始数据，其实是个逻辑概念，就是需要存的对象就叫object。data内容本身是数据，关于这个对象本身的描述叫做元数据。

MDS

MDS全称Ceph Metadata Server，是CephFS服务依赖的元数据服务，只有文件服务才用MDS。

CephFS

CephFS全称Ceph File System，是Ceph对外提供的文件系统服务。


RBD

RBD全称RADOS block device，是Ceph对外提供的块设备服务。

RGW

RGW全称RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容。


PG

PG全称Placement Grouops，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。

RADOS

RADOS全称Reliable Autonomic Distributed Object Store，是Ceph集群的精华，用户实现数据分配、Failover等集群操作。

Libradio

Librados是Rados提供库，因为RADOS是协议很难直接访问，因此上层的RBD、RGW和CephFS都是通过librados访问的，目前提供PHP、Ruby、Java、Python、C和C++支持。

CRUSH

CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。