作者：张华 发表于：2014-06-21
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明
(http://blog.csdn.net/quqi99 )
作者将重新研究ceph, 先温习一下之前作者大半年前发表在openstack中国社区的一篇理论文章(http://www.openstack.cn/p276.html)，复制如下：
Ceph是一个支持大量小文件和随机读写的分布式文件系统，在维护 POSIX 兼容性的同时加入了复制和容错功能。目前Ceph已经被加到了Linux内核之中，虽然可能还不适用于生产环境。它也想实现统一存储的目标，即：
- 对象系统，类似Swift, 这里是RADOS, Reliable Autonomic Distributed Object Store, 可靠的自主分布式对象存储。在每台host上都要运行OSD(Object Storage Daemon)进程，当然，如果已经用RAID, LVM或btrf，xfs（最好别用ext4)将每台host上的硬盘都做成一个池了的话，运行一个OSD就可以了。OSD会默认创建三个池：data, metada与RBD 。同时，在每台host上还要运行MON (Monitor)进程。
- 文件存储，类似Hadoop中的HDFS，但HDFS是流式存储，即一次写多次读。想使用Ceph文件存储的话，那还在每台host上还要运行MDS(Meta-Data Server)进程。MDS是在对象系统的基础之上为Ceph客户端又提供的一层POSIX文件系统抽象实现。
- 块存储, 类似Cinder
这样说来，至少有下列几种方式可以访问Ceph中的对象：
- RADOS方式，RADOS是Ceph的基础，即使对于Ceph文件存储，底层也是使用RADOS，RADOS本来提供一个librados库来访问对象，这个库支持php, java, python, c/c++。还通过RADOS Gateway来提供和Swift与Amazon-S3兼容的REST接口。
- RBD(rados block device)与QEMU-RBD，前面说了，Ceph已经加到内核了，所以可以使用内核的RBD驱动来访问对象，它也和QEMU-RBD兼容。
- CephFS, 上述MDS提供的POSIX兼容的文件系统。在生产系统中，建议用以上三种方式，不建议这种。
一个数据块具体存放在哪些host上需要有元数据来描述，HDFS是在一台机器上集中存储元数据的（HA可以通过配置主备实现），Swift则完全是分布式的，一个数据块具体存放在哪些host（在Ceph中称OSD, OSD是在host上维护数据块的一个进程)上由一致性哈希算法决定，元数据使用rsync命令同步分布在每一个host上，所以需要分级来减小元数据的大小，所以也就有了Accounts, Containers, Objects这三级RING。对应在RADOS中，有两级映射，先经过哈希把key映射到PG (Placement Group, 为了减小抖动，PG是通过公式：(Totol_num_of_OSD * 100 ) / max_replication_count) / Pool_Count))，再通过一致性哈希函数CRUSH从PGID映射到实际存储数据的host (OSD)。Swift使用的一致性哈希算法使用flat的host列表，但是CRUSH这种一致性哈希算法使用的host列表具有层次结构（CRUSH: disk, node, rack, row, switch, power circuit, room, DC, 再引入pool逻辑概念，rules告诉CRUSH如何复制数据到不同的pool），并且能允许用户通过指定policies把复制存放在不同的机架。剩下的事和Swift类似，CRUSH会生成在RING上产生副本信息，第一个副本是主，其它是从，主负责接收来自客户端的写，及协调多个客户端的写，主再将数据写给从，待主返回结果后，主才告诉用户写成功，所以副本是强一致性的，这点和AWS dynamo这些最终一致性的做法有些区别。当新增机器或发生宕机时，和swift也类似，CRUSH一致性哈希算法也会保证数据的抖动性最小（即转移的数据块最少）。
除了存储节点外，还有一些监控节点组成的小集群，负责监控存储节点的运行状态，它们通过Paxos协议达到一致和保持数据冗余，Paxos和ZooKeeper中用到的领导者选择算法Zap协议类似，只要保证这些host中的大多数host不出故障就行，并且我们一般选择奇数台host，举个例子，在５个host的监控集群中，任何两台机器故障的情况下服务都能继续运行。
在一致性保证方面，在ZooKeeper中，领导者与跟随者非常聪明，跟随者通过更新号（唯一的全局标识叫zxid, ZooKeeper Transaction ID)来滞后领导者，这样大部分host确认更新之后，写操作就能被提交了。Ceph换汤不换药，这个全局标识改了个名叫epoch序号(例如：OSD加入或删除会更新MDS节点上的OSD Map元数据，相关的OSD或随机的OSD会被push更新，所以会有osd.a是更新后的，osd.b是旧的，那么当osd.b与MDS通信时会带上epoch，发现这个值比它低，就会更新。这也是osd_find_best_info_ignore_history_les参数能让OSD重新加入元数据恢复PG状态的原理），所以Monitor节点记录的是epoch序号和一些全局状态（如存储节点是否在线，地址端口等），非常轻量，每个监测到存储节点发生变更时，如存储节点上线或下线，将epoch序号增加以区别先前的状态。总之，Monitor节点维护了这些集群状态映射对象ClusterMap，包括：monitor map, OSD map, placement group (PG) map, CRUSH map, mds map。例如当存储节点宕机时，监控节点发现后更新epoch和ClusterMap，然后通过gossip p2p方式推送给存储节点（这种p2p通知和存储节点自主复制和HDFS中的master-slave模型是有区别的），存储节点再重新计算CRUSH决定将宕机机器丢失副本补上，由于一致性哈希的特性，发生变更的PG不会很多，也就是说抖动性不会很大。
通过将Ceph与现有的Swift, Hadoop等现有技术一坐标映射，到了这一步，笔者也就清楚Ceph是做什么的了。有机会再看看OpenStack是怎样用它的，以及它是怎样具体安装部署的。
参考文献：
http://ceph.com/docs/next/architecture/
http://blog.csdn.net/quqi99/article/details/7438258
http://codingstory.com/2013/01/06/rados/
http://www.sebastien-han.fr/blog/2012/06/10/introducing-ceph-to-openstack/