Ceph分布式存储实践应用之深入Ceph实现原理

1. Crush算法与作用

CRUSH算法，全称Controlled Replication Under Scalable Hashing （可扩展哈希下的受控复制），它是一个可控的、可扩展的、分布式的副本数据放置算法， 通过CRUSH算法来计算数据存储位置来确定如何存储和检索数据。

• 保障数据分布的均衡性

  让数据能够均匀的分不到各个节点上面，同时让数据访问的读写操作在各个节点和磁盘上保持负载均衡。

• 集群的灵活伸缩性

  可以方便快速的增加或删除节点，对失效的节点自动检测处理，能够自动实现数据的均衡，并且尽可能少的迁移改动数据。

• 支持更大规模的集群

  能够做到数据分布算法维护较小的元数据与计算量， 随着集群规模的不断增加，保持较小的数据分布式算法开销，不能呈线性增长。

2. Crush算法说明

PG到OSD的映射的过程算法称为CRUSH 算法，它是一个伪随机的过程，可以从所有的OSD中，随机性选择一个OSD集合，但是同一个PG每次随机选择的结果是不变的，实质上映射的OSD集合是固定的。

CRUSH使Ceph客户机能够直接与OSDs通信，而不是通过集中的服务器或代理。通过算法确定的数据存储和检索方法，从而避免了单点故障、性能瓶颈和对其可伸缩性的物理限制。

Crush Map将系统的所有硬件资源描述成一个树状结构，然后再基于这个结构按照一定的容错规则生成一个逻辑上的树形结构，树的末级叶子节点device也就是OSD，其他节点称为bucket节点，根据物理结构抽象的虚拟节点，包含数据中心抽象、机房抽象、机架抽象、主机抽象。

3. Crush算法原理

1. Ceph的存储结构

   Ceph为了保存对象，会先构建一个池（pool），把pool可以比喻成一个仓库，一个新对象的保存就类似于把一个包裹放到仓库里面。

   为了更好的提升效率，Pool可以划分为若干的PG（Placement Group）归置组，这类似于仓库里面有不同的储物架，所有的储物架组成了一个完整的仓库，所有的PG也就构建成了一个pool。

2. PG的分配存储

   对象是如何保存至哪个PG上？假设Pool名称为rbd，共有256个PG，每个PG编个号分别叫做0x0， 0x1， 0x2，．．． 0xFF。 具体该如何分配？这里可以采用Hash方式计算。

   假设有两个对象名， 分别为bar和foo的，根据对象名做Hash计算：

   HASH（‘bar’） ＝ 0x3E0A4162

   HASH（‘foo’） ＝ 0x7FE391A0

   通过Hash得到一串随机的十六进制的值， 对于同样的对象名，计算出的结果能够永远保持一致，但我们预分配的是256个PG，这就需要再进行取模处理， 所得的结果会落在【0x0，0xFF】区间：

   0x3E0A4162 ％ 0xFF ＝＝＝＞ 0x62

   0x7FE391A0 ％ 0xFF ＝＝＝＞ 0xA0

   实际在Ceph中， 存在很多个Pool，每个Pool里面存在若干个PG，如果两个Pool里面的PG编号相同，该如何标识区分？Ceph会对每个pool再进行编号，比如上面名称为rbd的Pool，给定ID编号为0， 再新增一个Pool，ID编号设定为1，那么一个PG的实际编号是由pool_id + . + pg_id组成。由此推论， 刚才的bar对象会保存在编号为0的pool，pg编号为62里面。

3. OSD的分配存储

   Ceph的物理层，对应的是服务器上的磁盘，Ceph将一个磁盘或分区作为OSD，在逻辑层面，对象是保存至PG内，现在需要打通PG与OSD之间的联系， Ceph当中会存在较多的PG数量，如何将PG平均分布各个OSD上面，这就是Crush算法主要做的事情： 计算PG -> OSD的映射关系。

   上述所知， 主要两个计算步骤：

   POOL_ID（对象池） ＋ HASH（‘对象名称’） ％ pg＿num（归置组）＝＝＞ PG＿ID （完整的归置组编号）

   CRUSH（PG＿ID）＝＝＞ OSD （对象存储设备位置）

4. 为什么需要采用Crush算法

   如果把CRUSH（PG＿ID）改成 HASH（PG_ID）% OSD_NUM 能否适用？ 是会存在一些问题。

   1）如果挂掉一个OSD，所有的OSD_NUM 余数就会发生变化，之前的数据就可能需要重新打乱整理， 一个优秀的存储架构应当在出现故障时， 能够将数据迁移成本降到最低， CRUSH则可以做到。

   2）如果增加一个OSD, OSD_NUM数量增大， 同样会导致数据重新打乱整理，但是通过CRUSH可以保障数据向新增机器均匀的扩散， 且不需要重新打乱整理。

   3）如果保存多个副本，就需要能够获取多个OSD结果的输出， 但是HASH方式只能获取一个， 但是通过CEPH的CRUSH算法可以做到获取多个结果。

5. Crush算法如何实现

   每个OSD有不同的容量，比如是4T还是800G的容量，可以根据每个OSD的容量定义它的权重，以T为单位， 比如4T权重设为4，800G则设为0.8。

   那么如何将PG映射到不同权重的OSD上面？这里可以直接采用CRUSH里面的Straw抽签算法，这里面的抽签是指挑取一个最长的签，而这个签值得就是OSD的权重。如果每次都存储在容量最大的OSD上，很容易将该节点塞满， 这就需要采取类似随机权重的算法来做实现。

   

   主要步骤：

   • 计算HASH: CRUSH＿HASH（ PG＿ID， OSD＿ID， r ） ＝＝＞ draw

     把r当做一个常数，将PG＿ID， OSD＿ID一起作为输入，得到一个HASH值。

   • 增加OSD权重： （ draw ＆0xffff ） ＊ osd＿weight ＝＝＞ osd＿straw

     将计算出的HASH值与OSD的权重放置一起，这样就能够得到每个OSD的签长， 权重越大的，数值越大。

   • 遍历选取最高的权重：high_draw

   Crush目的是随机跳出一个OSD，并且要满足权重越大的OSD，挑中的概率越大，为了保障随机性，将每个OSD的权重都乘以一个随机数也就是HASH值，再去结果最大的那个。如果样本容量足够大， 随机数对选中的结果影响逐渐变小， 起决定性的是OSD的权重，OSD的权重越大， 被挑选的概率也就越大，这样能够做到数据的有效分布。

   Crush所计算出的随机数，是通过HASH得出来，这样可以保障相同的输入， 会得出同样的输出结果。 所以Crush并不是真正的随机算法， 而是一个伪随机算法。

   这里只是计算得出了一个OSD，在Ceph集群中是会存在多个副本，如何解决一个PG映射到多个OSD的问题？

   将之前的常量r加1， 再去计算一遍，如果和之前的OSD编号不一样， 那么就选取它；如果一样的话，那么再把r+2，再重新计算，直到选出三个不一样的OSD编号。

   

   假设常数r=0，根据算法(CRUSH_HASH & 0xFFFF) * weight 计算最大的一个OSD，结果为osd.1的0x39A00，也就是选出的第一个OSD，然后再让r=1， 生成新的CRUSH_HASH随机值，取得第二个OSD，依次得到第三个OSD。

4. IO流程图

步骤：

1. client连接monitor获取集群map信息。
2. 同时新主osd1由于没有pg数据会主动上报monitor告知让osd2临时接替为主。
3. 临时主osd2会把数据全量同步给新主osd1。
4. client IO读写直接连接临时主osd2进行读写。
5. osd2收到读写io，同时写入另外两副本节点。
6. 等待osd2以及另外两副本写入成功。
7. osd2三份数据都写入成功返回给client, 此时client io读写完毕。
8. 如果osd1数据同步完毕，临时主osd2会交出主角色。
9. osd1成为主节点，osd2变成副本。

5. Ceph 通信机制

网络通信框架三种不同的实现方式：

• Simple线程模式
  • 特点：每一个网络链接，都会创建两个线程，一个用于接收，一个用于发送。
  • 缺点：大量的链接会产生大量的线程，会消耗CPU资源，影响性能。
• Async事件的I/O多路复用模式
  • 特点：这种是目前网络通信中广泛采用的方式。新版默认已经使用Asnyc异步方式了。
• XIO方式使用了开源的网络通信库accelio来实现
  • 特点：这种方式需要依赖第三方的库accelio稳定性，目前处于试验阶段。

消息的内容主要分为三部分：

• header //消息头类型消息的信封
• user data //需要发送的实际数据
  • payload //操作保存元数据
  • middle //预留字段
  • data //读写数据
• footer //消息的结束标记

步骤：

• Accepter监听peer的请求, 调用 SimpleMessenger::add_accept_pipe() 创建新的 Pipe, 给 SimpleMessenger::pipes 来处理该请求。

• Pipe用于消息的读取和发送。该类主要有两个组件，Pipe::Reader，Pipe::Writer用来处理消息读取和发送。

• Messenger作为消息的发布者, 各个 Dispatcher 子类作为消息的订阅者, Messenger 收到消息之后， 通过 Pipe 读取消息，然后转给 Dispatcher 处理。

• Dispatcher是订阅者的基类，具体的订阅后端继承该类,初始化的时候通过 Messenger::add_dispatcher_tail/head 注册到 Messenger::dispatchers. 收到消息后，通知该类处理。

• DispatchQueue该类用来缓存收到的消息, 然后唤醒 DispatchQueue::dispatch_thread 线程找到后端的 Dispatch 处理消息。

6. Ceph RBD 块存储 IO流程图

osd写入过程：

1. 采用的是librbd的形式，使用librbd创建一个块设备，向这个块设备中写入数据。
2. 在客户端本地通过调用librados接口，然后经过pool，rbd，object、pg进行层层映射,在PG这一层中，可以知道数据是保存在哪三个OSD上，这三个OSD分别为主从的关系。
3. 客户端与primary OSD建立SOCKET 通信，将要写入的数据传给primary OSD，由primary OSD再将数据发送给其他replica OSD数据节点。

7. Ceph 心跳和故障检测机制

问题：

故障检测时间和心跳报文带来的负载, 如何权衡降低压力?

1. 心跳频率太高则过多的心跳报文会影响系统性能。
2. 心跳频率过低则会延长发现故障节点的时间，从而影响系统的可用性。

故障检测策略应该能够做到：

及时性：节点发生异常如宕机或网络中断时，集群可以在可接受的时间范围内感知。

适当的压力：包括对节点的压力，和对网络的压力。

容忍网络抖动：网络偶尔延迟。

扩散机制：节点存活状态改变导致的元信息变化需要通过某种机制扩散到整个集群。

OSD节点会监听public、cluster、front和back四个端口

• public端口：监听来自Monitor和Client的连接。
• cluster端口：监听来自OSD Peer的连接。
• front端口：客户端连接集群使用的网卡, 这里临时给集群内部之间进行心跳。
• back端口：在集群内部使用的网卡。集群内部之间进行心跳。
• hbclient：发送ping心跳的messenger(送信者)。

Ceph OSD之间相互心跳检测

• 同一个PG内OSD互相心跳，他们互相发送PING/PONG信息。

• 每隔6s检测一次(实际会在这个基础上加一个随机时间来避免峰值)。

• 20s没有检测到心跳回复，加入failure队列。