【Ceph浅析笔记】Ceph的工作原理

本章主要对Ceph的工作原理进行介绍。

寻址过程

如果Client来了一个请求,不管个请求是读还是写都需要先寻址,才能找到数据应该放哪里或者说需要从哪里去。

之前我们说过Ceph的寻址方式是基于计算的,这样就避免的查表,也避免了使用一个单独的元数据服务器。

概述

对于Client传来的一个File,为了方便处理,我们可以将其分割为若干大小相同的小块Object

然后可以将这些Object映射到OSD上,如果使用一种固定的映射算法,则一个Object每次都会固定的映射到一组OSD上,那么如果这个OSD坏了呢?则无法迁移到其他的OSD上。

同时一个Object可以给会映射到若干的OSD上,所以这个OSD会定期与其他的OSD进行信息的交互,而每个OSD上承载的Object可能达数百万个,那么如果OSD要进行的信息交互将暴涨至数千万次,维护成本较高。

那么为了实现Object与OSD之间的动态映射,以及降低OSD与Object之间的信息维护开销,则可以引入一个中间层PG(Placement Group)

PG首先会对Object进行组织。一个Object只能映射到一个PG里面。而一个PG可以组织多个Object。也就是说PG与Object是“一对多”的映射关系

另外PG还会与OSD进行映射。每个PG一般会复制成3副本放到3个OSD上。而每个OSD上也会承载多个PG。

映射过程

那么file——Object——PG——OSD之间的映射是如何完成的呢?

  • 首先是file —— Object的映射

    这个比较简单,就是按照一定的大小对file进行切割即可,相当于RAID中的条带化处理

    切割以后,我们可以对object进行编号,也即oid(Object ID)

    每个file都有一个唯一的元数据ino,然后再把file切分后产生的序号连缀在一起,即可构成oid

    比如元数据为fileName的文件成分为三个Object,oid即为fileName0,fileName1,fileName2。

    需要注意的是ino必须唯一

  • 然后是Object—— PG

    每个Object都要独立的映射到一个PG里面。

    我们之前提供,数据块最好能均匀在底层,这样即可以充分利用底层硬件,有可以平摊风险。那么怎么均匀分布呢?

    首先可以将oid进行哈希,这样会得到一个近似均匀分布的伪随机值,然后我们要考虑的是把Object放到PG里面去了。假设PG数为m,那么最简单的就是在m个PG中随机的选一个,那么可以设定一个长度为m-1的掩码,然后将HASH得到的伪随机值于mask按位相与,最终得到PG序号(pgid)

    现在我们保证了Object与PG之间近似均匀的映射,然后Object的size相同,这样就可以保证PG中存储的Object的总数据量近似均匀。

    不过需要注意的是Object与PG的数量较多的时候,这种伪随机关系才近似均匀性才能成立。

  • 最后是PG——OSD映射

    之前讲的Object与PG的映射其实是静态的,也就是一个Object通过这个运算一定会映射到某个PG里面。

    但是我们加上PG层的目的是可以实现动态迁移,也就是说"Object——PG"的结构不是绝对不变的,而是受到其他因素的影响,比如

    • 当前系统的状态,也就是Cluster Map。当系统中的OSD状态、数量发生变化的时候,ClusterMap可能发生变化。因此映射关系也会变化。

    • 预先配置的存储策略。
      最开始的时候管理员可以配置一些策略,比如说一个PG分到的3个OSD需要位于不同的服务器或者说机架上,这样就算一个服务器宕掉了,还有其他的副本可用。

    所以说这一层的映射公式需要满足动态特性,可以让PG根据需要动态迁移到不同的OSD组合上。

    此次映射中使用的算法就叫CRUSH算法

image.png
image.png

写数据的流程

Ceph的写与读的流程大体相同,本章主要介绍写过程。

image.png

当Client要向Ceph集群写入一个file时,首先要在Client本地将file映射为若干Object,然后使用HASH和CRUSH算法映射成3个OSD。序号最靠前的OSD就是Primary OSD,后两个为Secondary OSD和Tertiary OSD。

现在Client已经知道数据要写到哪些OSD里面了,首先向Primary OSD发起写请求,然后由Primary OSD同步复制两个副本到其余的OSD中。

当Secondary 和Tertiary完成写入了以后,返回ACK给 Primary,最后由Primary向Client确认Object的写入。

很显然这种做法延迟比较长,必须等所有的OSD都落到磁盘上了以后才会真正返回ACK。可以进行一些优化。当各个OSD将数据写入内存缓冲区后,先向Client发送 一次确认,当各个OSD都将数据落到磁盘后,再向Client发送一个最终的ACK。

总之,不需要依赖其他的系统模块,只需要Client即可完成OSD的寻址。所以Client可以与OSD进行并行操作,这样工作压力可以尽可能均匀分担,从而避免单个OSD成为性能瓶颈。


image.png

如何同步信息

下面两章我们介绍了如何寻址,如何写入,他们都需要使用到cluster map这个元数据,那么如何在所有节点上同步cluster map呢?

由若干monitor共同监控所有OSD的状态,然后会形成cluster map的master版本。再将这个版本同步到其他的OSD和client中。

不过monitor不是主动询问所有OSD的状态的,而是由OSD主动上报自己的状态信息,比如说OSD加入或者异常的时候,都需要主动通知到monitor

那么Cluster Map需要包含哪几个方面的信息呢?

  • 首先是OSD的网络地址,这样才可以找到OSD在那里。

  • 然后当然是OSD的状态,也就是OSD是否正常工作,是否在至少一个PG里面。

另外还需要包含CRUSH算法的一些配置参数。

还有个问题,Cluster Map在所有的OSD之间进行同步,极有可能两个OSD持有的Cluster Map的版本不同,那么怎么进行区分了?可以使用 版本号,时间越靠后的版本号越大,所以monitor手上的版本号一定最大。当任意两方在通信的时候发现彼此的版本号不相同,则需要将高版本的同步到另外的节点上。

OSD上线

当一个新的OSD上线后,首先会根据配置信息主动向monitor进行报告。

然后Monitor会把它加入Cluster Map中,然后更新状态,最后把最新版的Cluster Map发给这个OSD。

接下来,这个OSD会计算出自己对应的PG,以及这个PG还会放到哪些其他的OSD。然后这个新的OSD会与这些OSD取得联系,如果

  • 此时发现这个PG只放了2个副本,而预先配置的副本数应该是3。说明之前肯定有OSD出现了故障,所以其他OSD把这个PG的内容复制给新的OSD,最后再更新一次状态,说明OSD已经可以承载PG了。

    这就是一个failure recovery的过程

  • 如果此时发现OSD一切正常,则用新的OSD替换到现在的一个OSD,并承担数据,重新更新cluster map的内容。这就是一个re-balancing的过程。

那么failture detection的过程又是什么呢?如果一个OSD发现自己与共同承载一个PG的另一个OSD无法通信,它会上报给monitor。或者说,OSD的守护进程发现自己的状态异常,同样会上报给monitor。如果在一段时间以后,OSD仍然无法恢复正常,则状态会设置为down and out,更新cluster map并扩散。

更新cluster map会不会有广播风暴

之前我们了解了cluster map数据结构并不大,也就是说即使这个集群中有上千个OSD,cluster map的扩散也不会占用太大的带宽。

而且cluster map也不会频繁的更新。

最关键的是cluster map是以增量的形式扩散,只会把两个版本的差异发送给另一方。

同时monitor不是map的版本一更新就广播给大家。它只会在有OSD上报信息的时候才会同步一次,所以这种方式是异步且lazy的。

所以因为map更新而导致广播防暴的几率并不高。

image.png

推荐阅读更多精彩内容

  • 1. 简介 在传统分布式存储架构中,存储节点往往仅作为被动查询对象来使用,随着存储规模的增加,数据一致性的管理会出...
    chnmagnus阅读 4,233评论 3 3
  • 系统环境: centos73.10.0-514.26.2.el7.x86_64 机器数量:五台 硬盘:四块一块为系...
    think_lonely阅读 2,826评论 0 5
  • ceph简介 Ceph是一个分布式存储系统,诞生于2004年,是最早致力于开发下一代高性能分布式文件系统的项目。随...
    爱吃土豆的程序猿阅读 3,816评论 0 20
  • 朱 荣泽| 2013.09.09 https://www.ustack.com/blog/ceph_infra/ ...
    守望者_1065阅读 1,729评论 0 1
  • 集群管理 每次用命令启动、重启、停止Ceph守护进程(或整个集群)时,必须指定至少一个选项和一个命令,还可能要指定...
    Arteezy_Xie阅读 8,959评论 0 16