标签:style blog http color io os 使用 java ar
作者将又一次研究ceph, 先温习一下之前作者大半年前发表在openstack中国社区的一篇理论文章(http://www.openstack.cn/p276.html),复制例如以下:
Ceph是一个支持大量小文件和随机读写的分布式文件系统,在维护 POSIX 兼容性的同一时候添加了复制和容错功能。眼下Ceph已经被加到了Linux内核之中,尽管可能还不适用于生产环境。它也想实现统一存储的目标,即:
这样说来,至少有下列几种方式能够訪问Ceph中的对象:
一个数据块详细存放在哪些host上须要有元数据来描写叙述,HDFS是在一台机器上集中存储元数据的(HA能够通过配置主备实现),Swift则全然是分布式的,一个数据块详细存放在哪些host(在Ceph中称OSD, OSD是在host上维护数据块的一个进程)上由一致性哈希算法决定,元数据使用rsync命令同步分布在每个host上,所以须要分级来减小元数据的大小,所以也就有了Accounts, Containers, Objects这三级RING。相应在RADOS中,有两级映射,先经过哈希把key映射到PG (Placement Group),再通过一致性哈希函数CRUSH从PGID映射到实际存储数据的host (OSD)。Swift使用的一致性哈希算法使用flat的host列表,可是CRUSH这样的一致性哈希算法使用的host列表具有层次结构(shelves, racks, rows),而且能同意用户通过指定policies把复制存放在不同的机架。剩下的事和Swift相似,CRUSH会生成在RING上产生副本信息,第一个副本是主,其他是从,主负责接收来自client的写,及协调多个client的写,主再将数据写给从,待主返回结果后,主才告诉用户写成功,所以副本是强一致性的,这点和AWS dynamo这些终于一致性的做法有些差别。当新增机器或发生宕机时,和swift也相似,CRUSH一致性哈希算法也会保证数据的抖动性最小(即转移的数据块最少)。
除了存储节点外,另一些监控节点组成的小集群,负责监控存储节点的执行状态,它们通过Paxos协议达到一致和保持数据冗余,Paxos和ZooKeeper中用到的领导者选择算法Zap协议相似,仅仅要保证这些host中的大多数host不出故障即可,而且我们一般选择奇数台host,举个样例,在5个host的监控集群中,不论什么两台机器故障的情况下服务都能继续执行。
在一致性保证方面,在ZooKeeper中,领导者与尾随者非常聪明,尾随者通过更新号(唯一的全局标识叫zxid, ZooKeeper Transaction ID)来滞后领导者,这样大部分host确认更新之后,写操作就能被提交了。Ceph换汤不换药,这个全局标识改了个名叫epoch序号,所以Monitor节点记录的是epoch序号和一些全局状态(如存储节点是否在线,地址port等),非常轻量,每个监測到存储节点发生变更时,如存储节点上线或下线,将epoch序号添加以差别先前的状态。总之,Monitor节点维护了这些集群状态映射对象ClusterMap,包含:monitor map, OSD map, placement group (PG) map, CRUSH map, epoch 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/
比較Swift与HDFS话Ceph本质(by quqi99)
标签:style blog http color io os 使用 java ar
原文地址:http://www.cnblogs.com/mengfanrong/p/3989081.html