ceph源码之一

  1. 云栖社区>
  2. 博客>
  3. 正文

ceph源码之一

天色渐晚 2015-05-14 16:42:00 浏览541
展开阅读全文

转自于:http://blog.csdn.net/changtao381/article/details/8698935

一、概述:

 其结构如下:在src 里,

  网络通信:  msg  里面 包括了网络传输的代码, message 目录里定义了 传输的消息格式。
  元数据服务器:
                    mds  目录 包括了metadata server 的代码
  数据服务器:
                   os     目录里包含了 object store 的代码
                   osd  目录包括了 object storage device 的代码
  客户端:
                   osdc  目录里包括跨网络访问 osd的 代码
                   librados 包括了对象存储的客户端操作的代码
                   librbd,rgw, client  客户端代码,其代码都是基于librados之上。
  监控:Ceph Monitor      
                   mon 目录里包括了 Ceph Monitor的代码                 
  CRUSH 算法:
            cursh  目录里包括了 cursh 算法的代码
  核心就是上述的代码,当然还有其它一些的辅助性的代码:
    common: 一些公用的类和函数
  cls: OSD的一个插件机制,可以在对象上原子的执行一些复杂的操作。 感觉有点像OpenC++的反射机制,总之是一种测试和调试机制。

二、架构设计 

  特点

    Ceph最大的特点是分布式的元数据服务器  通过CRUSH,一种拟算法来分配文件的locaiton,其核心是 RADOS(resilient automatic distributed object storage),一个对象集群存储,本身提供对象的高可用,错误检测和修复功能。

  其设计思想有一些创新点:

  第一,数据的定位是通过CRUSH算法来实现的。

    传统的,或者通常的并行文件系统,数据的定位的信息是保存在文件的metadata 中的, 也就是inode结构中,通过到metadata server上去获取数据分布的信息。而在Ceph中,是通过CRUSH 这个算法来提供数据定位的;

    这和GlusterFS的思想是相同的,GlusterFS 是通过Elastic Hash,类似于DHT的算法实现的。这就有点像P2P存储,所谓的完全对称的存储,这种设计架构最大的优点是,其理论上可以做到 线性扩展的能力(line scale)。

    在GlusterFS架构中,是完全去掉了metadata server,这就导致GlusterFS文件系统上的元数据操作,例如ls, stat操作非常慢,要去各个stripe的节点上收集相关的元数据信息后聚合后的结果。在Ceph中,为了消除完全的p2p设计,提供了metadata     server 服务,提供文件级别的元数据服务,而元数据服务中的文件数据定位由CRUSH算法代替。

  第二,元数据服务器可以提供集群metadata server 服务。

    只要当我们了解了其结构后,感觉并没有太大的特点。元数据服务器一般就用来存储文件和目录的信息,提供统一的命名服务。 在Ceph中,元数据 的存储inode 和 dentry的,以及日志都是在 对象存储集群RADOS中存储,这就使得 metadata的 持久化都 是在远程的RADOS中完成,metadata server 不保存状态,只是缓存最近的inode 和 dentry项,当metadata server 失效后,其所所有信息都可以从RADOS中获取,可以比较容易恢复。

    其实, 也上两点,并没有什么特别的地方。 我觉得,CEPH最核心的,就是RADOS就是RADOS(resilient automatic distributed object storage). 其resilient 指的是可以轻松扩展,automatic 指的是其对象存储集群可以处理failover, failure recovery。RADOS 对象集群其对外提供了一个高可用的,可扩展的,对象集群,从客户端的角度看,就是一个统一命名空间的对象存储。

  下面我们重点介绍一下RADOS这个Ceph的核心系统。 

RADOS对象存储集群

 Ceph 的Monitor

  用来监控集群中所有节点的状态信息,完成类似配置服务的功能。在Ceph里,配置主要就是cluster map ,其保存集群所有节点信息,并和所有的节点保持心跳,来监控所有的节点状态。

其通过Paxos算法实现实现自身的高可用,也就是说,这个Ceph Monitor是不会有单点问题的。目前流行的zookeeper 的功能,以及实现都类似。

对象存储

  Ceph文件系统中的数据和元数据都保存在对象中。 对于对象存储,通常的定义是:一个Object,由三部分组成(id,metadata,data),id是对象的标识,这个不必多说。所谓的metadata,就是key/value的键值存储,至于用来保存什么信息,由文件系统的语义定义。data就是实际存储的数据。

  Ceph的对象,包括四个部分(id,metadata,attribute,data),在Ceph里,一个Object,实际就对应本地文件系统的一个文件,一个对象的attribute,也是key/value的键值对,其保存在本地文件系统的文件的扩展属性中。对象的metadata就是key/value的键值对,目前Ceph保存在google开源的一个key/value存储系统leveldb中,或者自己写的一个key/value 存储系统中。数据就保存在对象的文件中。对于一个对象的更新,都需要写日志中来保持一个Object数据的一致性(consistence),日志有一个单独的设备或者文件来保存。

副本存储

  一个PG(placement group)由一个OSD列表组成,OSD的个数,就是对象的副本数,一个三副本的PG就是一个主,两个副本的OSD列表组成。

  一个PG和OSD列表的映射关系,是通过CRUSH算法计算的,知道PG的id,和当前的cluster map,就可以通过CRUSH算法,计算出OSD列表。特别强调的是,一个PG是逻辑层概念,也就是说,一个OSD,可能同时是一个或者多个PG的主,同时是另一个PG的从。一个OSD处于多个PG组中。一个PG就是复制和修复的基本单位。每个OSD本地保存其所在的PG列表就可以了,其它OSD可以通过输入当前的该OSD保存的cluster map 和 PG 的id ,通过CRUSH计算得出。

Ceph的容错处理

  对于Ceph文件系统,错误分两类:一类是磁盘错误或者数据损坏( disk error or  corruptted data), 这类错误OSD会自己报告和处理。(self report ); 第二类是OSD失去网络连接导致该OSD不可达(unreachable on the network)这种情况下需要主动检测(active monitor),在同一个PG组中的其它OSD会发心跳信息互相检测。 这种检测的一个优化的方法就是,当replication复制操作时,就可以顺带检测,不用发单独的消息来检测,只有一段时间没有replication 操作时,才发ping消息里检测。

  OSD的失效状态有两种:一种是down状态,这种状态下,被认为是临时错误。 在这种情况下,如果是primay,其任务由下一个replicate接手。如果该OSD没有迅速恢复(quickly recovery),那么就被标记为out状态,在这种状态下,将有新的osd加入这个PG中。

  如何标记一个OSD 从down状态 标记为out状态?由于网络分区的问题,需要通过 Ceph Monitor 来裁定。

Ceph 的写流程

   客户端先写主副本,然后同步到两个从副本。主副本等待从副本的ack消息和apply消息。当主副本收到ack消息,说明写操作已经写在内存中完成,收到apply 消息,说明已经apply到磁盘上了。

  如果在写的过程中,主副本失效,按顺序下一个从副本接管主副本的工作,这个时候是否返回给客户端写正确?在这种情况下,客户端只是判断正常工作的(acting)的 OSD的返回结果,只要所有正常工作的OSD返回即认为成功,虽然这时候可能只有两副本成功。同时该临时primay必须保存所有操作的recovey队列里,如果原primay恢复,可以replay所有recovery队列里的操作,如果主副本从down到out状态,也即是永久失效,临时primay转正,由临时primay为正式primay,只是需要加入一个新的OSD到该PG中。

如果是从副本失效,就比较简单。临时失效,主replay所有写操作,如过永久失效,新加入一个OSD到PG中就可以了。

恢复

   当有OSD失效,恢复或者增加一个新的OSD时,导致OSD cluster map的变换。Ceph处理以上三种情况的策略是一致的。为了恢复,ceph保存了两类数据,一个是每个OSD的一个version,另一个是PG修改的log,这个log包括PG修改的object 的名称和version。

当一个OSD接收到cluster map的更新时:

1)检查该OSD的所属的PG,对每个PG,通过CRUSH算法,计算出主副本的三个OSD

2)如何该PG里的OSD发生了改变,这时候,所有的replicate向主副本发送log,也就是每个对象最后的version,当primay 决定了最后各个对象的正确的状态,并同步到所有副本上。

3)每个OSD独立的决定,是从其它副本中恢复丢失或者过时的(missing or outdated)对象。 (如何恢复? 好像是整个对象全部拷贝,或者基于整个对象拷贝,但是用了一些类似于rsync的算法?目前还不清楚)

4)当OSD在恢复过程中,delay所有的请求,直到恢复成功。

 

网友评论

登录后评论
0/500
评论
天色渐晚
+ 关注