ceph学习笔记

随着云存储的大力发展，越来越多的开源分布式存储公布，MFS、gluster、ceph、lustre等等，百家争艳、各有千秋，

本文针对ceph的学习进行记录，并针对性的和glusterfs进行对比。

一。框架、结构

首先ceph和glusterfs本质上是完全不同的，ceph是基于rados的分布式存储

Ceph的底层是RADOS，它的意思是“A reliable, autonomous, distributed object storage”。 RADOS由两个组件组成：OSD： Object Storage Device，提供存储资源。Monitor：维护整个Ceph集群的全局状态。

（而glusterfs是基于文件系统的分布式存储。）

一般一个osd在实际业务中可以是一个盘、一个raid组等，对应在os中就是一个xfs的裸设备。

在Ceph中，Object先映射到PG(Placement Group)，再由PG映射到OSD set。每个Pool有多个PG，每个Object通过计算hash值并取模得到它所对应的PG。PG再映射到一组OSD（OSD的个数由Pool 的副本数决定），第一个OSD是Primary，剩下的都是Replicas

• CRUSH算法：一种伪随机算法。
• OSD MAP：包含当前所有Pool的状态和所有OSD的状态。
• CRUSH MAP：包含当前磁盘、服务器、机架的层级结构。
• CRUSH Rules：数据映射的策略。这些策略可以灵活的设置object存放的区域。比如可以指定 pool1中所有objecst放置在机架1上，所有objects的第1个副本放置在机架1上的服务器A上，第2个副本分布在机架1上的服务器B上。 pool2中所有的object分布在机架2、3、4上，所有Object的第1个副本分布在机架2的服务器上，第2个副本分布在机架3的服 器上，第3个副本分布在机架4的服务器上。

多个osd盘可以融合在一个pool中，而这些osd盘可以是同一台服务器，也可以跨服务器，这一点跟glustefs又有区别，glustefs中的bricks的概念只能在不同的server之间进行，形象化比喻，比如现有6台storage server，每台上面24块900G硬盘做3组raid5，每7块一个raid5加一个HS，这样每个raid组的大小约为5T（4.9T），若使用glusterfs来规划，可以创建3个volume，每个volume采用replica 2的方式，这样就是一共45T，但是这45T在glustefs的client端肯定是要挂在3个挂载点上，因为每个volume只能根据最大的物理节点上限15T受限。

而采用ceph的话，可以将3*6 =18个osd盘全部规划到一个pool中，虽然同样replica 2的方式冗余，但是挂载点只需要一个（当然根据我的经验，ceph远远比glusterfs部署起来麻烦）

二。算法

glusterfs和ceph都采用伪随机hash算法，但是ceph的crush算法更加灵活，更多样化，（可以根据crushmap 反编译现有pool中的算法，然后根据host、rack、pdu甚至更大的单元进行逻辑冗余，增加容错性，这一点有点类似于oracle rac中ASM的failure group）

三。速度

速度在我看来并不是ceph的优势，基于glusterfs的分布式方式，一个文件先在一份副本中存储，待完毕后在做备份，而ceph是在整个pool中的block同步存储，在加上ceph是基于block设备，虽然比较glusterfs和ceph的速度是不公平的事情（毕竟原理不一样，对应的情况不一样，不能直接类比），但是个人建议如果是存储图片、视频等文件还是用glusterfs明显更快，网上有很多针对ceph和glusterfs测速的案例。

四。网络

ceph和glusterfs都可以基于tcp和rdma上进行部署，但是本人在部署ceph的时候确确实实遇到个小麻烦，还以上面45T的一个pool为例，在存储端target后，客户端我通过iscsi 和multipath整合客户端路径，发现每次重启后，在client端的lvm会消失，仔细查看日志发现，若iscsi iser发现的裸设备大小较大的时候（如果朋友你仅仅挂载个10G、100G那是不会有问题的），会出现开机后iscsi iser还没有完全发现完这个大的裸设备，multipath这时候就已经开始干他多路径干的活了，这样下来最终在/dev/mapper/下的多路径裸设备是不完全的，我之后在rc.local中执行个shell命令，做了下两个服务的映射才能解决这个问题。

五。容错性

在分布式系统中，常见的故障有网络中断、掉电、服务器宕机、硬盘故障等，Ceph能够容忍这些故障，并进行自动修复，保证数据的可靠性和系统可用性。

• Monitors是Ceph管家，维护着Ceph的全局状态。Monitors的功能和zookeeper类似，它们使用Quorum和Paxos算法去建立全局状态的共识。
• OSDs可以进行自动修复，而且是并行修复。

故障检测：

OSD之间有心跳检测，当OSD A检测到OSD B没有回应时，会报告给Monitors说OSD B无法连接，则Monitors给OSD B标记为down状态，并更新OSD Map。当过了M秒之后还是无法连接到OSD B，则Monitors给OSD B标记为out状态(表明OSD B不能工作），并更新OSD Map。

备注：可以在Ceph中配置M的值。

故障恢复：

1. 当某个PG对应的OSD set中有一个OSD被标记为down时(假如是Primary被标记为down，则某个Replica会成为新的Primary，并处理所有读写 object请求)，则该PG处于active+degraded状态，也就是当前PG有效的副本数是N-1。
2. 过了M秒之后，假如还是无法连接该OSD，则它被标记为out，Ceph会重新计算PG到OSD set的映射(当有新的OSD加入到集群时，也会重新计算所有PG到OSD set的映射)，以此保证PG的有效副本数是N。
3. 新OSD set的Primary先从旧的OSD set中收集PG log，得到一份Authoritative History(完整的、全序的操作序列)，并让其他Replicas同意这份Authoritative History(也就是其他Replicas对PG的所有objects的状态达成一致)，这个过程叫做Peering。
4. 当Peering过程完成之后，PG进 入active+recoverying状态，Primary会迁移和同步那些降级的objects到所有的replicas上，保证这些objects 的副本数为N。

六。高可靠性和可拓展性

• Client和Server直接通信，不需要代理和转发
• 多个OSD带来的高并发度。objects是分布在所有OSD上。
• 负载均衡。每个OSD都有权重值(现在以容量为权重)。
• client不需要负责副本的复制(由primary负责),这降低了client的网络消耗。

• 高度并行。没有单个中心控制组件。所有负载都能动态的划分到各个服务器上。把更多的功能放到OSD上，让OSD更智能。
• 自管理。容易扩展、升级、替换。当组件发生故障时，自动进行数据的重新复制。当组件发生变化时(添加/删除)，自动进行数据的重分布。

总之，这个心得还是会不断完善更新，正如我总结的一样，目前感觉glusterfs和ceph各有千秋，具体采用哪种开源分布式还是要根据实际业务情况分析。