学习自世民大神的博客：http://www.cnblogs.com/sammyliu/p/4804037.html
正在入门ceph，懵懂中，随手作下笔记。
Ceph 集群的逻辑结构由 Pool 和 PG （Placement Group）来定义。
1、Pool：
一个 Pool 是 Ceph 中的一些对象的逻辑分组，它并不表示一个连续的分区，而只是一个逻辑概念，类似于将二进制数据打了tag一样然后根据tag归类一样。它类似于 LVM 中的 Volume Group，类似于一个命名空间。RBD Image 类似于 LVM 中的 Logical Volume。RBD Image 必须且只能在一个 Pool 中。Pool 由若干个PG组成。其属性包括：
所有性和访问权限
对象副本数目
PG 数目
CRUSH 规则集合
Ceph Pool 有两种类型：
Replicated pool：拷贝型 pool，通过生成对象的多份拷贝来确保在部分 OSD 丢失的情况下数据不丢失。这种类型的 pool 需要更多的裸存储空间，但是它支持所有的 pool 操作。
Erasure-coded pool：纠错码型 pool（类似于 Software RAID）。在这种 pool 中，每个数据对象都被存放在 K+M 个数据块中：对象被分成 K 个数据块和 M 个编码块；pool 的大小被定义成 K+M 块，每个块存储在一个 OSD 中；块的顺序号作为 object 的属性保存在对象中。可见，这种 pool 用更少的空间实现存储，即节约空间；纠删码实现了高速的计算，但有2个缺点，一个是速度慢，一个是只支持对象的部分操作（比如：不支持局部写）。这篇文章 详细介绍了其原理和细节。
Pool 提供如下的能力：
Resilience（弹力）：即在确保数据不丢失的情况允许一定的 OSD 失败，这个数目取决于对象的拷贝（copy/replica）份数。对拷贝型 pool 来说，Ceph 中默认的拷贝份数是2，这意味着除了对象自身外，它还有一个另外的备份。你可以自己决定一个 Pool 中的对象的拷贝份数。
Placement Groups（放置组）：Ceph 使用 PG 来组织对象，这是因为对象可能成千上万，因此一个一个对象来组织的成本是非常高的。PG 的值会影响 Ceph 集群的行为和数据的持久性。你可以设置 pool 的 PG 数目。推荐的配置是，每个 OSD 大概 100 个 PG。
CRUSH Rules （CRUSH 规则）：数据映射的策略。系统默认提供 “replicated_ruleset"。用户可以自定义策略来灵活地设置 object 存放的区域。比如可以指定 pool1中所有objecst放置在机架1上，所有objects的第1个副本放置在机架1上的服务器A上，第2个副本分布在机架1上的服务器B上。 pool2中所有的object分布在机架2、3、4上，所有Object的第1个副本分布在机架2的服务器上，第2个副本分布在机架3的服 器上，第3个副本分布在机架4的服务器上。详细的信息可以参考这些文档 （1）（2）（3）（4）。
Snapshots（快照）：你可以对 pool 做快照。
Set Ownership：设置 pool 的 owner 的用户 ID。
Ceph 集群创建后，默认创建了 data，metadata 和 rbd 三个存储池。
2、PG
PG 概念非常复杂，主要有如下几点：
PG 也是对象的逻辑集合。同一个PG 中的所有对象在相同的 OSD 上被复制。
PG 聚合一部分对象成为一个组（group），这个组被放在某些OSD上（place），合起来就是 Placemeng Group （放置组）了。
Epoch：PG map 的版本号，它是一个单调递增的序列。
Peering：见下文的状态（8）描述。详细过程请参阅 Ceph：pg peering过程分析。
Acting set：支持一个 PG 的所有 OSD 的有序列表，其中第一个 OSD 是主OSD，其余为次。acting set 是 CRUSH 算法分配的，但是不一定已经生效了。
Up set：某一个 PG map 历史版本的 acting set。在大多数情况下，acting set 和 up set 是一致的，除非出现了 pg_temp。
Current Interval or Past Interval：若干个连续的版本号，这些版本中 acting 和 up set 保持不变。
PG temp：在Ceph 正在往主 OSD 回填数据时，这个主OSD是不能提供数据服务的，这时候，它会向 MON 申请一个临时的 acting set，这就是 PG temp。举个例子，现在 acting set 是[0,1,2]，出现了一点事情后，它变为 [3,1,2]，此时 osd.3 还是空的因此它无法提供数据服务因此它还需要等待backfilling过程结束，因此，它会向 MON 申请一个临时的 set 比如 [1,2,3]，此时将由 osd.1 提供数据服务。回填过程结束后，该临时 set 会被丢弃，重新由 osd.3 提供服务。
主 （primary） OSD：在 acting set 中的首个 OSD，负责接收客户端写入数据；默认情况下，提供数据读服务，但是该行为可以被修改。它还负责 peering 过程，以及在需要的时候申请 PG temp。
次 （replica）OSD：在 acting set 中的除了第一个以外的其余 OSD。
流浪 （stray） OSD：已经不是 acting set 中了，但是还没有被告知去删除数据 的 OSD。
PG 的 acting set 是由 CRUSH 算法根据 CRUSH Rules 动态地计算得出的。
其主要特点如下：
基本特点
PG 确定了 pool 中的对象和 OSD 之间的映射关系。一个 object 只会存在于一个 PG 中，但是多个 object 可以在同一个 PG 内。
Pool 的 PG 数目是创建 pool 时候指定的，Ceph 官方有推荐的计算方法。其值与 OSD 的总数的关系密切。当Ceph 集群扩展 OSD 增多时，根据需要，可以增加 pool 的 PG 数目。
对象的副本数目，也就是被拷贝的次数，是在创建 Pool 时指定的。该分数决定了每个 PG 会在几个 OSD 上保存对象。如果一个拷贝型 Pool 的size（拷贝份数）为 2，它会包含指定数目的 PG，每个 PG 使用两个 OSD，其中，第一个为主 OSD （primary），其它的为从 OSD （secondary）。不同的 PG 可能会共享一个 OSD。
Ceph 引入 PG 的目的主要是为了减少直接将对象映射到 OSD 的复杂度。
PG 也是Ceph 集群做清理（scrubbing）的基本单位，也就是说数据清理是一个一个PG来做的。
PG 和 OSD 之间的映射关系由 CRUSH 决定，而它做决定的依据是 CRUSH 规则（rules）。CRUSH 将所有的存储设备（OSD）组织成一个分层结构，该结构能区分故障域（failure domain），该结构中每个节点都是一个 CRUSH bucket。详细情况请阅读 CRUSH 相关的文档。
PG 和 OSD 的关系是动态的：
当新的 OSD 被加入集群后，已有OSD上部分PG将可能被挪到新OSD上；此时PG 和 OSD 的关系会发生改变。
当已有的某 OSD down 了并变为 out 后，其上的 PG 会被挪到其它已有的 OSD 上。
但是大部分的 PG 和 OSD 的关系将会保持不变，在状态变化时，Ceph 尽可能只挪动最少的数据。
up：守护进程运行中，能够提供IO服务；
down：守护进程不在运行，无法提供IO服务；
in：包含数据；
out：不包含数据
一开始在 PG 被创建的时候，MON 根据 CRUSH 算法计算出 PG 所在的 OSD。这是它们之间的初始关系。
Ceph 集群中 OSD 的状态是不断变化的，它会在如下状态之间做切换：
部分 PG 和 OSD 的关系会随着 OSD 状态的变化而发生变化。
客户端根据 Cluster map 以及 CRUSH Ruleset 使用 CRUSH 算法查找出某个 PG 所在的 OSD 列表（其实是 up set）。
PG-Object-OSD 的关系如下图所示：
PG 的创建过程（详细过程请参考 PG 的创建过程）：
MON 节点上有PGMonitotor，它发现有 pool 被创建后，判断该 pool 是否有 PG。如果有PG，则一一判断这些 PG 是否已经存在，如果不存在，则开始下面的创建 PG 的过程。
创建过程的开始，设置PG 状态为 Creating，并将它加入待创建PG队列 creating_pgs，等待被处理。
开始处理后，使用 CRUSH 算法根据当前的 OSD map 找出来 up/acting set，加入 PG map 中以这个 set 中 OSD 为索引的队列 creating_pgs_by_osd。（看起来只会加入到主OSD的队列中）。
队列处理函数将该 OSD 上需要创建的 PG 合并，生成消息MOSDPGCreate，通过消息通道发给 OSD。
OSD 收到消息字为 MSG_OSD_PG_CREATE 的消息，得到消息中待创建的 PG 信息，判断类型，并获取该PG的其它OSD，加入队列 creating_pgs （似乎是由主 OSD 负责发起创建次 OSD 上的PG），再创建具体的 PG。
PG 被创建出来以后，开始 Peering 过程。
PG 值的确定：创建 pool 时需要确定其 PG 的数目，在 pool 被创建后也可以调整该数字，该数目会影响到：
那如何确定一个 Pool 中有多少 PG？Ceph 不会自己计算，而是给出了一些参考原则，让 Ceph 用户自己计算：
少于 5 个 OSD， 建议设为 128
5 到 10 个 OSD，建议设为 512
10 到 50 个 OSD，建议设为 4096
50 个 OSD 以上，就需要有更多的权衡来确定 PG 数目
你可以使用 pgcalc 工具
数据的持久性：考虑pool 的 size 为 3，表明每个 PG 会将数据存放在 3 个 OSD 上。当一个 OSD down 了后，一定间隔后将开始 recovery 过程，recovery结束前，有部分 PG 的数据将只有两个副本。这时候和需要被恢复的数据的数量有关系，如果该 OSD 上的 PG 过多，则花的时间将越长，风险将越大。如果此时再有一个 OSD down 了，那么将有一部分 PG 的数据只有一个副本，recovery 过程继续。如果再出现第三个 OSD down 了，那么可能会出现部分数据丢失。可见，每个 OSD 上的PG数目不宜过大，否则，会降低数据的持久性。这也就要求在添加 OSD 后，PG 的数目在需要的时候也需要相应增加。
数据的均匀分布性：CRUSH 算法会伪随机地保证 PG 被选中来存放客户端的数据，它还会尽可能地保证所有的 PG 均匀分布在所有的 OSD 上。比方说，有10个OSD，但是只有一个 size 为 3 的 pool，它只有一个 PG，那么10个 OSD 中将只有三个 OSD 被用到。但是 CURSH 算法在计算的时候不会考虑到OSD上已有数据的大小。比方说，100万个4K对象共4G均匀地分布在10个OSD上的1000个PG内，那么每个 OSD 上大概有400M 数据。再加进来一个400M的对象（假设它不会被分割），那么有三块 OSD 上将有 400M + 400M = 800 M 的数据，而其它七块 OSD 上只有 400M 数据。
资源消耗：PG 作为一个逻辑实体，它需要消耗一定的资源，包括内存，CPU 和带宽。太多 PG 的话，则占用资源会过多。
清理时间：Ceph 的清理工作是以 PG 为单位进行的。如果一个 PG 内的数据太多，则其清理时间会很长。
PG 的状态也是不断变化的，其主要状态包括：
Creating 创建中：PG 正在被创建。
Peering 对等互联：表示一个过程，该过程中一个 PG 的所有 OSD 都需要互相通信来就PG 的对象及其元数据的状态达成一致。处于该状态的PG不能响应IO请求。Peering的过程其实就是pg状态从初始状态然后到active+clean的变化过程。一个 OSD 启动之后，上面的pg开始工作，状态为initial，这时进行比对所有osd上的pglog和pg_info，对pg的所有信息进行同步，选举primary osd和replica osd，peering过程结束，然后把peering的结果交给recovering，由recovering过程进行数据的恢复工作。
Active 活动的：Peering 过程完成后，PG 的状态就是 active 的。此状态下，在主次OSD 上的PG 数据都是可用的。
Clean 洁净的：此状态下，主次 OSD 都已经被 peered 了，每个副本都就绪了。
Down：PG 掉线了，因为存放其某些关键数据（比如 pglog 和 pginfo，它们也是保存在OSD上）的副本 down 了。
Degraded 降级的：某个 OSD 被发现停止服务 （down）了后，Ceph MON 将该 OSD 上的所有 PG 的状态设置为 degraded，此时该 OSD 的 peer OSD 会继续提供数据服务。这时会有两种结果：一是它会重新起来（比如重启机器时），需要再经过 peering 过程再到clean 状态，而且 Ceph 会发起 recovery （恢复）过程，使该 OSD 上过期的数据被恢复到最新状态；二是 OSD 的 down 状态持续 300 秒后其状态被设置为 out，Ceph 会选择其它的 OSD 加入 acting set，并启动回填（backfilling）数据到新 OSD 的过程，使 PG 副本数恢复到规定的数目。详情可以参考 PG 的数据恢复过程。
Recovering 恢复中：一个 OSD down 后，其上面的 PG 的内容的版本会比其它OSD上的 PG 副本的版本落后。在它重启之后（比如重启机器时），Ceph 会启动 recovery 过程来使其数据得到更新。
Backfilling 回填中：一个新 OSD 加入集群后，Ceph 会尝试级将部分其它 OSD 上的 PG 挪到该新 OSD 上，此过程被称为回填。与 recovery 相比，回填（backfill）是在零数据的情况下做全量拷贝，而恢复（recovery）是在已有数据的基础上做增量恢复。
Remapped 重映射：每当 PG 的 acting set 改变后，就会发生从旧 acting set 到新 acting set 的数据迁移。此过程结束前，旧 acting set 中的主 OSD 将继续提供服务。一旦该过程结束，Ceph 将使用新 acting set 中的主 OSD 来提供服务。
Stale 过期的：OSD 每隔 0.5 秒向 MON 报告其状态。如果因为任何原因，主 OSD 报告状态失败了，或者其它OSD已经报告其主 OSD down 了，Ceph MON 将会将它们的 PG 标记为 stale 状态。
PG 的所有的状态是一个类似树形的结构，每个状态可能存在子状态，子状态还可能存在子状态，如下图所示：
