1 ceph概述
ceph是一种具备卓越性能和高可靠性、高可扩展性的统一、分布式存储系统。它的两个核心概念便是统一和分布式。“统一”是指ceph可以凭借一套存储系统能同时向客户提供对象存储、块存储和文件系统存储三种存储功能，用户可以对三种功能同时启用，也可以“三选一”使用，以便在满足不同应用需求的前提下简化部署和运维。“分布式”在ceph系统中则意味着真正的无中心结构和没有理论上限的系统规模可扩展性，真正解决了传统scale-up类型存储在扩容过程中所面临的性能瓶颈问题。ceph存储系统以scale-out的形式可以扩容到PB级别。
2 ceph功能
分布式存储ceph能凭借一套存储系统能同时向客户提供如下三种存储功能：
a).对象存储：提供RESTful接口，也提供多种编程语言绑定。兼容S3、Swift
b).块存储：由RBD提供，可以直接作为磁盘挂载，内置了容灾机制
c).文件系统：提供POSIX兼容的网络文件系统CephFS，专注于高性能、大容量存储
3 ceph架构
ceph内部架构非常直观的显示内部组件信息。如下图所示：
3.1 ceph monitor
ceph monitor(监视器，检查MON)：ceph monitor通过保存一份集群状态映射来维护整个集群的健康状态。它分别为每个组件维护映射信息，包括OSD map、MON map、PG map和CRUSH map。所有集群节点都想MON节点汇报状态信息，并分享他们状态中的任何变化。ceph monitor不存储数据。
3.2 OSD
OSD（cep对象存储设备）：只要应用程序向ceph集群发出写操作，数据就会被以对象形式存储在OSD中。这是ceph集群中唯一能存储用户数据的组件，同时用户也可以发送读命令来读取数据。
在ceph集群中通常一个OSD守护进程会被捆绑到集群中的一块物理磁盘上。所有，在正常情况下，ceph集群中的物理磁盘的总数与在磁盘上运行的存储用户数据的OSD守护进程的数量是相同的。
3.3 MDS
MDS（ceph元数据服务器）：MDS只为CephFS文件系统跟踪文件的层次结构和存储元数据。ceph块设备和RADOS并不需要元数据，因此也不需要ceph MDS守护进程。
MDS不直接提供数据给客户端，从而消除了存储系统中的单点故障问题。
3.4 RADOS
RADOS是ceph存储集群的基础。在ceph中，所有数据都以对象形式存储，并且无论是哪种数据类型，RADOS对象存储都将负责保存这些对象。RADOS层可以确保数据始终保持一致。要做到这点，需要执行数据复制、故障检测和恢复，以及数据迁移和所在集群节点实现再平衡。
3.5 librados
librados库为PHP、Ruby、Java、Python、C和C++这些编程语言提供了方便访问RADOS接口的方式。同时它还为RBD、RGW和CephFS这些组件提供了原生的接口、librados还支持直接访问RADOS来节省HTTP开销。
3.6 RADOS 块设备
RADOS块设备（RBD）：RBD是ceph块设备，提供持久化块存储，它是自动精简配置并可调整大小的，而且将数据分散在多个OSD上。
RBD服务已经被封装成了预计librados的一个原生接口。
3.7 RADSO 网关接口
RADOS网关接口（RGW）：RGW提供对象存储服务。它使用librgw和librados，允许应用程序与ceph对象存储建立连接。
RGW提供了与Amazon S3和OpenStack Swift兼容的RESRful API。
3.8 CephFS
ceph文件系统提供了一个使用ceph存储集群存储用户数据的与POSIX兼容的文件系统。与RBD、RGW一样，CephFS服务也基于librados封装了原生接口。
4 ceph设计架构
ceph从设计概念上可以拆分为四部分，即客户端（clients）、元数据服务器（Metadata Server）、对象存储集群（Object Storage Cluster）和集群监控（Cluster Monitor）。设计架构图如下所示：
客户端是存储数据的使用者；元数据服务器负责缓存和同步分布式元数据；对象存储集群负责以对象的形式存储全部的用户数据和元数据以及实现其他的关键功能；集群监控负责实现对整个ceph集群的监控。
在使用过程中，clients使用metadata server执行元数据操作（识别和定位元数据存储位置），metadata server负责管理已存储数据的位置和即将存储数据的位置，需要注意的是集群元数据也存储在存储集群中（“metadata I/O”），而实际的Filo I/O操作发生在client与Object Storage Cluster之间，即ceph文件系统实现了元数据与数据之间的分离，clients端先与metadata server交互并进行元数据操作以获取数据存储位置信息，之后再与Storage cluster交互进行实际的数据存取操作。在这种元数据与数据分离的设计中，高层次的POSIX功能，如对文件的打开，关闭和重命名，由metadata server进行管理，而POSIX功能，如读和写则直接由object Storage cluster进行管理。
ceph与传统文件系统的主要差异就在于ceph并没有将全部的精力集中在文件系统本身，而是分布到ceph文件系统集群中。ceph文件系统集群内部简要架构图如下所示：
ceph客户端是ceph文件系统的使用者，ceph Metadata Daemon 提供了元数据服务，ceph object storage Deamon提供了实际的存储功能（包括数据和元数据存储），最后ceph monitor提供了对整个集群的管理。
在实际应该过程中，将会存在大量的ceph客户端，并且有许多的对此存储后端以及多个元数据服务器，同时至少存在一对冗余的监控。
4.1 ceph客户端
早期版本的ceph与ZFS、GLusterFS和Lustre文件系统类似，使用的是用户空间文件系统（Filesystem in Userspace，FUSE）。使用FUSE的好处在于，能够大幅提高开发调试效率，简化为操作系统提高新文件系统所需的工作量。但是在用户态实现文件系统必然会引入额外的内核态/用户态切换所带来的开销，文件系统的性能产生一定的影响。ceph文件系统已经集成到Linux内核中，因而可以得到更好的性能。
在ceph客户端中，Linux通过虚拟文件系统（virtual file system，VFS）将通用接口呈现给客户端文件系统，因此cpeh对于文件系统终端用户而言是透明的，而对于系统管理员缺失不同的，系统管理员通常看到的是组成文件系统的大量服务器。从用户角度而言，仅会看到一个可执行文件I/O的挂载点，该挂载点位于一个可读写访问的大型存储系统之上，用户并不会注意到底层的元数据服务器，集群监控基于组成海量存储池的众多独立存储设备。
与大多数的文件系统类似，Ceph客户端接口也由Linux内核实现，即所有文件系统的控制和智能管理操作都由位于内核中的ceph源文件系统自身来实现。但是ceph与常规文件系统的不同之处在于，ceph将文件系统的智能化管理分布到集群中各个节点上，这中分布式的实现不仅简化了ceph客户端，也同时为ceph提供了强大的海量存储扩展能力。
不同于传统文件系统子啊文件管理上的分配列表方式，ceph采用另外的方式来管理元数据与文件系统之间的映射关系。
从Linux角度而言，ceph文件系统中每个需要存储的文件都会从元数据服务器获得一个全家唯一的Inode号，并且多每个文件而言INO是其唯一的标志，在文件被INO标志后，ceph会根据每个文件的尺寸大小将其转换成不同数目的“对象”，并结合Inode号和对象号（object Number，ONO）为每个对象服用一个对象ID（object ID，OID）。ceph对每个对象的OID进行简单的hash计算后，将对象分配到不同的放置组（Placement Group，PG）。这里的PG其实是放置对象的概念性容器，每个PG都是通过PGID来标志，而每个PG到最终存储对象的底层物理存储设备的映射是一种采用CRUSH算法实现伪随机映射。通过这种方式，PG到存储设备的映射不依赖任何元数据，而是一种伪随机映射函数，这种数据映射
查找方式最小化了存储负载，并简化了数据的分布和查找，这也是ceph的核心思想之一，即数据查找时“不用查表，算算即可”。
ceph中PG的这种随机映射机制回到正轨集群上，就是集群映射表（cluster Map），cluster map是ceph集群中存储设备的最佳表示，通过PGID和cluster Map，用户可以定位任何对象存储位置。
ceph客户端包括几个接口服务，块设备接口、对象存储接口和文件系统接口。ceph客户端在ceph高层次架构如下图所示：
RADOS块设备（RBD）：RBD是ceph块设备，提供持久化块存储，它是自动精简配置并可调整大小的，而且将数据分散在多个OSD上。RBD服务已经被封装成了预计librados的一个原生接口。
RADOS网关接口（RGW）：RGW提供对象存储服务。它使用librgw和librados，允许应用程序与ceph对象存储建立连接。RGW提供了与Amazon S3和OpenStack Swift兼容的RESRful API。
ceph文件系统提供了一个使用ceph存储集群存储用户数据的与POSIX兼容的文件系统。与RBD、RGW一样，CephFS服务也基于librados封装了原生接口。cephFS的内部架构如下图所示：
4.2 ceph元数据服务器
ceph元数据服务器的主要工作是管理文件系统的命名空间，虽然ceph集群中的元数据和数据均存储在对象存储集群中，但是为了实现可扩展性，二者被分开独立管理。元数据在可以自适应复制和分发命令空间，以避免热点的元数据服务器集群被进一步的分割。元数据服务器对文件系统的命名空间的管理如下图所示：
每个MDS管理部分命名空间，为了实现冗余和提高性能，各个命名空间部分之间可以重叠。元数据服务器集群与命名空间之间的映射通过动态子树分区实现，这种方式允许ceph适应不断变化的工作负载（通过在元数据服务器之间迁移命名空间来实现）并保持局部性能。
使用过程中每个元数据服务器仅为客户端群体管理命名空间，因此元数据服务器的主要任务便是对缓存元数据的智能管理。在ceph文件系统中，要写入的元数据首先缓存到临时日志中，之后在最终写入物理存储元数据的缓存机制允许ceph将最近写入的元数据以很快的响应速度返回给客户端。
4.3 ceph监控
ceph实现了对集群映射（cluster Map）管理的监控，不过某些故障管理单元的监控由对象存储本身实现。当对象存储设备出现故障或添加新设备时，ceph监控器会检查并维护Cluster Map以使得存储设备出现变化后集群映射依然有效。ceph监控器的这一功能通过分布式的方式来实现。在这种分布式的方式中，cluster map的更新通过现有的通信网络传播到各个节点。ceph采用的是具有分布式一致性的Paxos算法。
4.4 ceph对象存储
ceph对象存储不仅包括存储功能，还包括对存储对象的智能管理。与传统的存储驱动作为一个简单的target，仅响应来自Initiators端发起的命令，对象存储设备是一种更为智能的设备，其可以同时充当target和Initiators角色，因此可以支持与其他对象存储设备的同学和合作。
ceph存储系统的逻辑结构如下图所示：
ceph存储系统可以分为四个层次，底层存储系统（RADOS，Reliable，Autonomic）、底层API库（LIBRADOS）、上层应用接口和外部应用接口。
5 ceph相关概念
5.1 RADOS
可靠的、自动化的分布式对象存储（Reliable, Autonomic Distributed Object Store）是Ceph的核心之一
librados是RADOS提供的库，上层的RBD、RGW和CephFS都是通过librados访问RADOS的
5.2 RGW
RGW即RADOS Gateway，指Ceph的对象存储API或者RGW守护进程
5.3 RBD
RBD即RADOS Block Device，指Ceph提供的基于复制性的分布式的块设备。类似于LVM中的逻辑卷，RBD只能属于一个Pool
5.4 MDS
MDS即Ceph元数据服务器，是CephFS服务依赖的元数据服务
5.5 CephFS
Ceph File System，是Ceph对外提供的文件系统服务
5.6 Pool
存储池是Ceph中一些对象的逻辑分组。它不是一个连续的分区，而是一个逻辑概念，类似LVM中的卷组（Volume Group）
存储池分为两个类型：
Replicated 复制型，对象具有多份拷贝，确保部分OSD丢失时数据不丢失，需要更多的磁盘空间。复制份数可以动态调整，可以置为1
Erasure-coded 纠错码型，节约空间，但是速度慢，不支持所有对象操作（例如局部写）
5.7 PG
归置组（Placement Group），PG是Pool组织对象的方式，便于更好的分配数据和定位数据，Pool由若干PG组成
PG 的数量会影响Ceph集群的行为和数据的持久性。集群扩容后可以增大PG数量：5个以下OSD设置为128即可
PG的特点：同一个PG中所有的对象，在相同一组OSDs上被复制。复制型Pool中PG可以有一个作为主（Primary）OSD，其它作为从OSD。一个对象仅仅属于一个PG，也就是说对象存储在固定的一组OSDs上
PG在OSD的/var/lib/ceph/osd/ceph-2/current目录下，表现为目录
5.8 CRUSH
CRUSH即基于可扩容哈希的受控复制（Controlled Replication Under Scalable Hashing），是一种数据分发算法，类似于哈希和一致性哈希。哈希的问题在于数据增长时不能动态添加Bucket，一致性哈希的问题在于添加Bucket时数据迁移量比较大，其他数据分发算法依赖中心的Metadata服务器来存储元数据因而效率较低，CRUSH则是通过计算、接受多维参数的来解决动态数据分发的场景
CRUSH算法接受的参数包括：
1. Cluster map，也就是硬盘分布的逻辑位置，例如这有多少个机房、多少个机柜、硬盘是如何分布的等等。Cluster map是类似树的结构，子节点是真正存储数据的device，每个device都有id和权重，中间节点是bucket，bucket有多种类型用于不同的查询算法，例如一个机柜一个机架一个机房就是bucket
2. Placement rules，它指定了一份数据有多少备份，数据的分布有什么限制条件（例如同一份数据不能放在同一个机柜里）。每个Rule对应一系列操作：
1. take，选取一个bucket
2. select，选择n个类型为t的项
3. emit，提交
CRUSH与一致性哈希最大的区别在于接受的参数多了Cluster map和Placement rules，这样就可以根据目前Cluster的状态动态调整数据位置，同时通过算法得到一致的结果
基于此算法，Ceph存储集群能够动态的扩容、再平衡、恢复
5.9 Object
Ceph最底层的存储单元是Object，每个Object包含元数据和原始数据
一个RBD会包含很多个Object
5.10 OSD
对象存储守护进程（Object Storage Daemon），负责响应客户端请求返回具体数据的进程。Ceph集群中有大量OSD
一个节点上通常只运行一个OSD守护进程，此守护进程在一个存储驱动器上只运行一个 filestore
5.11 EC
Erasure Code（EC），即纠删码，是一种前向错误纠正技术（Forward Error Correction，FEC），主要应用在网络传输中避免包的丢失， 存储系统利用它来提高可靠性。相比多副本复制而言， 纠删码能够以更小的数据冗余度获得更高数据可靠性， 但编码方式较复杂，需要大量计算 。纠删码只能容忍数据丢失，无法容忍数据篡改，纠删码正是得名与此
EC将n份原始数据，增加m份数据，并能通过n+m份中的任意n份数据，还原为原始数据。即如果有任意小于等于m份的数据失效，仍然能通过剩下的数据还原出来
纠删码技术在分布式存储系统中的应用主要有三类：
1.阵列纠删码（Array Code: RAID5、RAID6等）：RAID是EC的特例，RAID5只支持一个盘失效，RAID6支持两个盘失效，而EC支持多个盘失效
2.RS(Reed-Solomon)里德-所罗门类纠删码
3.LDPC(LowDensity Parity Check Code)低密度奇偶校验纠删码：目前主要用于通信、视频和音频编码等领域，与RS编码相比，LDPC编码效率要略低，但编码和解码性能要优于RS码以及其他的纠删码