1、Ceph集群中的逻辑结构

1.1 Object

Object是Ceph的最小存储单元，大小可以自己定义通常为2M或4M，每个Object都包含了在集群范围内唯一的标识OID、二进制数据、以及由一组键值对组成的元数据。OID是由ino与ono生成，ino是文件的file id，用于全局标识每一个文件，ono则是分片的编号。无论上层应用的是RBD、CephFS还是RADOSGW，最终都会以Object的方式存储在OSD上。当RADOS接收到来向客户端的数据写请求时，它将接收到的数据转换为Object，然后OSD守护进程将数据写入OSD文件系统上的一个文件中。

1.2 Pool
Pool是Ceph中的一些object的逻辑分组，它只是一个逻辑概念，类似于LVM中的Volume Group，类似于一个命名空间。Pool由若干个PG组成，其属性包括：所有者和访问权限、Object副本数目、PG数目和CRUSH规则集合等。用户可以对不同的Pool设置相关的优化策略，比如PG副本数、数据清洗次数、数据块及Object的Size等。当把数据写人到一个 Pool 时，首先会在CRUSH Map找到与Pool对应的规则集，这个规则集描述了Pool的副本数信息。在部署Ceph集群时会默认创建data、metadata和rbd Pool。

1）Ceph中的Pool有两种类型

Replicated pool：通过生成Object的多份拷贝来确保在部分OSD丢失的情况下数据不丢失。这种类型的pool需要更多的裸存储空间，但是它支持所有的pool操作。
Erasure-coded pool：纠错码型pool，类似于software RAID。在这种pool中，每个数据对象都被存放在K+M个数据块中：对象被分成K个数据块和M个编码块；pool的大小被定义成K+M块，每个块存储在一个OSD 中；块的顺序号作为object的属性保存在对象中。可见，这种pool用更少的空间实现存储，即节约空间；纠删码实现了高速的计算，但有2个缺点，一个是速度慢，一个是只支持对象的部分操作。
2）Pool提供如下能力

Resilience（弹力）：即在确保数据不丢失的情况允许一定的OSD失败，这个数目取决于对象的副本数。对Replicated pool来说，Ceph中默认的副本数是2，这意味着除了对象自身外，它还有一个另外的备份，这个副本数由参数osd_pool_default_size指定。
Placement Groups（放置组）：Ceph使用PG来组织对象，这是因为对象可能成千上万，因此一个一个对象来组织的成本是非常高的。PG的值会影响Ceph集群的行为和数据的持久性。通过osd_pool_default_pg_num设置pool中的PG 数目，默认为32，推荐的配置是每个OSD大概100个PG。
CRUSH Rules（CRUSH 规则）：数据映射的策略，由参数osd_pool_default_crush_rule指定，用户可以自定义策略来灵活地设置object存放的区域。
Snapshots（快照）：你可以对pool做快照
Set Ownership：设置pool的owner的用户ID

1.3 PG（Placement GROUP）
1.3.1 PG的概念
在Ceph集群中有着成千上万的objects，对于一个TB规模以上的集群，每个objects的默认大小为4MB，以三副本为例，整个集群可以存储的objects就有1TB/4MB/3=87381个，这样直接以objects为粒度进行数据管理的代价过于昂贵且不灵活。

PG是一些Objects的集合，这些objects组成一个group，放在某些OSD上（place），组合起来就是Placement Group。将objects以PG为单位进行管理，有以下好处：

集群中的PG数目经过规划因为严格可控，使得基于PG可以精准控制单个OSD乃至整个节点的资源消耗，如CPU、内存、网络带宽等
因为集群中的PG数目远小于objects数目，并且PG数目和每个PG的身份相对固定，以PG为单位进行数据备份策略和数据同步、迁移等，相较于直接以对象为单位而言，难度更小且更加灵活

PG中涉及到的一些概念如下：

Epoch：PG map的版本号，由OSD monitor生成，它是一个单调递增的序列。Epoch变化意味着OSD map发生了变化，需要通过一定的策略扩散到所有客户端和位于服务端的OSD。
Peering：归属于同一个PG所有的PG实例就本PG所存储的全部对象及对象相关的元数据状态进行协商并最终达到一致的过程。
Acting set：支持一个PG的所有OSD的有序列表，其中第一个OSD是主OSD，其余为从OSD。Acting set是CRUSH算法分配的，指当前或者曾在某个interval负责承载对应PG的PG实例。
Up set：某一个PG map历史版本的acting set。在大多数情况下，acting set 和 up set 是一致的，除非出现了 pg_temp。
Current Interval or Past Interval：若干个连续的版本号，这些版本中acting set和up set保持不变。
PG temp：Peering过程中，如果当前interval通过CRUSH计算得到的Up Set不合理，那么可以通知OSD Monitor设置PG temp来显示的指定一些仍然具有相对完备PG信息的OSD加入Acting set，在Ceph 正在往主 OSD 回填数据时，这个主OSD是不能提供数据服务的，使得Acting set中的OSD在完成Peering之后能够临时处理客户端发起的读写请求，以尽可能的减少业务的中断时间。举个例子，现在acting set是[0,1,2]，出现了一点事情后，它变为[3,1,2]，此时osd.3还是空的因此它无法提供数据服务因此它还需要等待backfilling过程结束，因此它会向MON申请一个临时的set比如[1,2,3]，此时将由 osd.1提供数据服务。回填过程结束后，该临时set会被丢弃，重新由osd.3提供服务。
Backfilling：recovery一种特殊场景，指Peering完成后，如果基于当前权威日志无法对Up Set当中的某些PG实例实施增量同步，则通过完全拷贝当前Primary所有对象的方式进行全量同步
Authoriative History：权威日志是Peering过程中执行增量数据同步的依据，通过交换信息并基于一定的规则从所有PG实例中选举产生
Primary OSD：在acting set中的首个 OSD，负责接收客户端写入数据；默认情况下，提供数据读服务，但是该行为可以被修改。它还负责peering过程，以及在需要的时候申请PG temp。
Replica OSD：在acting set中的除了第一个以外的其余OSD。
Stray OSD：PG实例所在的OSD已经不是acting set 中了，但是还没有被告知去删除数据的OSD。如果对应的PG已经完成Peering,
并且处于Active+Clean状态，那么这个实例稍后将被删除；如果对应的PG尚未完成Peering，那么这个PG实例仍有可能转化为Replica。