ceph作为开源的云存储解决方案，为Iaas云平台提供了可靠的云硬盘服务，越来越受到关注；目前360基础架构组和addops一块也在维护着ceph，下面主要介绍下ceph的总体结构以及读写流程。
组件
从下图可以看到，ceph整体架构上最核心的是底层的分布式对象存储rados，上层提供了访问rados分布式服务的库librados，基于librados对外封装了块存储服务rbd、兼容S3和Swift协议的对象存储服务radosgw，并且提供了基于rados底层框架的分布式文件系统服务，这次我们主要关注最核心的rados架构。
rados
ceph整体采用有中心的分布式架构，mon作为metaserver管理整个集群的元信息，为避免单点问题mon做成了集群形式，数据强一致性采用paxos协议实现；osd以硬盘为单位，构建在文件系统之上来实现数据的真正存储。
数据分布
数据分布采用两层映射的方式，如下图所示每个obj经过一层普通的hash计算后映射到一层叫做place group(简称pg)的逻辑层，pg就是整个集群数据的分片单位，集群内部以pg为单位进行数据备份，对于用户层透明；pg层通过crush算法将分片具体分配到osd上，crush算法是一个伪随机算法，用户可以通过crush配置自己的网络拓扑结构，如按机房、机架、机器等故障域来配置副本数据位置。
副本一致性
目前ceph已经实现了replication和ec的副本机制，ec相比replication机制能够降低一定的冗余数据量，但同时会带来一定的性能损耗，目前我们线上主要使用relication的机制，这里也主要介绍replication机制。由于上层提供块存储以及分布式文件系统这样的服务，对数据一致性有较强的需求，所以ceph副本采用强一致的策略，一次更新操作必须等到所有副本全都完成后才能返回；具体实现上主要有下图所示三种方式：
primary-copy: 读写操作全都在主副本上，写操作通过主副本并行发给其他副本，待所有副本操作完成返回给主副本后，读操作才能看到数据。
chain: 写操作从主开始链式传播给其他副本，读操作发生在最后一个副本上。
splay: write操作和primary一样有主并行发给其他副本，读操作和chain一样，从主副本上分离了出来。
可以看到chain和splay模式将读写分离了，可以减少primary的负担，chain操作的链式模式会影响更新的速度。
故障检测
ceph目前实现了mon和osd之间的心跳检测，以及有关联的osd之前的心跳检测，一旦检测到故障都会上报给mon，有mon根据相应策略决定故障是否真实发生。
故障恢复
ceph从两个维度来标记osd的状态，分别是up/down和in/out，以用来区分处理临时性故障和持久性故障；正常状态下osd状态是in&&up的，当网络抖动等临时性故障发生时osd状态为in&&down，此种状态下相关pg会进行 降级处理，即pg状态变为degraded；一定时间后，如果临时故障无法恢复，osd状态转为out&&down，集群进入持久性故障。
数据更行时会以pg为级别纪录pglog，临时性故障恢复是，如果pglog同步点还在，只需要通过对比pglog即可进行增量数据同步；对于持久性故障，集群内部的cluster map发生改变，ceph会自动根据新的cluster map结合crush规则进行数据的迁移，重新补回副本状态。
读写流程
数据从client端发给rados集群后，数据会在内部进行复杂的流程，然后返回给客户端，这个过程涉及到网络模块、osd模块、pg模块以及底层的存储模块等等，下图主要描述了simplemessage和filestore模式下主要可能涉及的类，调用关系以及相关异步队列。
后续会有一系列文章来分析ceph具体实现以及我们使用过程中出现的问题和优化想法，敬请围观。
