最近计划将基于ceph实现mysql的快速扩容，故提前先了解下ceph相关的知识，信息主要来源于一些博客和官方文档，主要介绍了基本的原理，架构，策略，特性等。能找到的话，后面会找一些ceph + mysql的案例看看。
ceph的基本架构由 OSDs,Monitors,和MDS三部分组成。外加client，对外的交互的客户端
Ceph OSDs: Ceph OSD 守护进程（ Ceph OSD ）的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。当 Ceph 存储集群设定为有2个副本时，至少需要2个 OSD 守护进程，集群才能达到 active+clean 状态（ Ceph 默认有3个副本，但你可以调整副本数）。
Monitors: Ceph Monitor维护着展示集群状态的各种图表，包括监视器图、 OSD 图、归置组（ PG ）图、和 CRUSH 图。 Ceph 保存着发生在Monitors 、 OSD 和 PG上的每一次状态变更的历史信息（称为 epoch ）。
MDSs: Ceph 元数据服务器（ MDS ）为 Ceph 文件系统存储元数据（也就是说，Ceph 块设备和 Ceph 对象存储不使用MDS ）
ceph架构的核心是RADOS（Reliable,Autonomic Distributed Object Store），是特别为ceph设计，能够在动态变化和异质结构的存储设备机群之上提供一种稳定、可扩展、高性能的单一逻辑对象(Object)存储接口和能够实现节点的自适应和自管理的存储系统。
上图为RADOS的架构图
File —— 此处的file就是用户需要存储或者访问的文件。
Ojbect —— 此处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储
PG（Placement Group）—— PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。
OSD —— 即object storage device，对象存储集群，即最终具体存储数据的位置。
RADOS里的三次映射
第一次映射。file---obiects，本次映射的目的是将用户的file转化程RADOS能处理的objects,映射方式很简单，就是把file按固定size切分（通常为2MB或4MB），然后分配oid，oid=file_id + num。比如filename为aaaa,并被切分为三份objec，那么这三份oid为aaaa0,aaaa1,aaaa2
第二次映射。object---PG，将object独立的分到一个PG中，一个object只能放到一个PG里，一个PG有很多object。映射方法 是 hash(oid) & mask -->pgid。首先使用计算oid的哈希值，然后与mask按位相与，最终得到要放的PG id。在object，PG数量很多的情况下，这种映射类似于随机分配
第三次映射，PG---OSD，RADOS通过CRUSH算法，通过PGID计算出n个OSD(n其实就是副本数)，然后将PG映射到这n个OSD上，一对多。
CRUSH算法是什么
CRUSH会根据当前的系统状态（OSD的数量，状态啥的） 和 储存策略配置（比如副本数）得出结果，易知CRUSH算法在输入一样的情况下不一定得出一样的结果。其特点是具有稳定性，当集群中加入新的OSD时，大部分PG和OSD之间的映射关系不会改变。
系统状态谁维护
系统状态由cluster map维护。由若干个monitor共同负责整个Ceph集群中所有OSD状态的发现与记录，并且共同形成cluster map的master版本，然后扩散至全体OSD以及client。OSD使用cluster map进行数据的维护，而client使用cluster map进行数据的寻址。
cluster map的更新在大集群里会引发广播风暴么
主动的广播可能会引发广播风暴，但是cluster map采用的是lazy && 异步 模式。monitor并不会在每一次cluster map版本更新后都将新版本广播至全体OSD，而是在有OSD向自己上报信息时，将更新回复给对方，此外cluster map采用的是增量扩散，如果通信双方发现其epoch不一致，则更新的一方将差异的部分传递。
epoch是什么
epoch存在于cluster map中，即版本号。Cluster map的epoch是一个单调递增序列。Epoch越大，则cluster map版本越新
cluster map中还有哪些数据
除epoch外，还有各个OSD的网络地址，各个OSD的状态，CRUSH算法的配置参数。
OSD有哪些状态？
OSD有四种状态，其中up/down 表示OSD是否正常工作。in/out表示OSD是否至少在一个PG中
Up且in：说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态；
Up且out：说明该OSD正常运行，但并未承载任何PG，其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态；
Down且in：说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，也可能会彻底无法工作；
Down且out：说明该OSD已经彻底发生故障，且已经不再承载任何PG。
ceph的一些特性
新的OSD上线后，首先根据配置信息与monitor通信。Monitor将其加入cluster map，并设置为up且out状态，再将最新版本的cluster map发给这个新OSD。
收到monitor发来的cluster map之后，这个新OSD计算出自己所承载的PG（为简化讨论，此处我们假定这个新的OSD开始只承载一个PG），以及和自己承载同一个PG的其他OSD。然后，新OSD将与这些OSD取得联系。如果这个PG目前处于降级状态（即承载该PG的OSD个数少于正常值，如正常应该是3个，此时只有2个或1个。这种情况通常是OSD故障所致），则其他OSD将把这个PG内的所有对象和元数据复制给新OSD。数据复制完成后，新OSD被置为up且in状态。而cluster map内容也将据此更新。这事实上是一个自动化的failure recovery过程。当然，即便没有新的OSD加入，降级的PG也将计算出其他OSD实现failure recovery。
如果该PG目前一切正常，则这个新OSD将替换掉现有OSD中的一个（PG内将重新选出Primary OSD），并承担其数据。在数据复制完成后，新OSD被置为up且in状态，而被替换的OSD将退出该PG（但状态通常仍然为up且in，因为还要承载其他PG）。而cluster map内容也将据此更新。这事实上是一个自动化的数据re-balancing过程。
如果一个OSD发现和自己共同承载一个PG的另一个OSD无法联通，则会将这一情况上报monitor。此外，如果一个OSD deamon发现自身工作状态异常，也将把异常情况主动上报给monitor。在上述情况下，monitor将把出现问题的OSD的状态设为down且in。如果超过某一预订时间期限，该OSD仍然无法恢复正常，则其状态将被设置为down且out。反之，如果该OSD能够恢复正常，则其状态会恢复为up且in。在上述这些状态变化发生之后，monitor都将更新cluster map并进行扩散。这事实上是自动化的failure detection过程。
参考链接：