随着云存储的大力发展,越来越多的开源分布式存储公布,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
多个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命令,做了下两个服务的映射才能解决这个问题。
五。容错性
故障检测:
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的值。
故障恢复:
总之,这个心得还是会不断完善更新,正如我总结的一样,目前感觉glusterfs和ceph各有千秋,具体采用哪种开源分布式还是要根据实际业务情况分析。