李航：分布式存储 Ceph 介绍及原理架构分享

1. File用户需要读写的文件。File->Object 映射：

a. ino (File 的元数据，File 的唯一id)。

b. ono(File 切分产生的某个 object 的序号，默认以 4M 切分一个块大小)。

c. oid(object id: ino + ono)。

2. Object 是 RADOS 需要的对象。Ceph 指定一个静态hash函数计算 oid 的值，将 oid 映射成一个近似均匀分布的伪随机值，然后和 mask 按位相与，得到 pgid。Object->PG 映射：

a) hash(oid) & mask-> pgid 。

b) mask = PG 总数 m(m 为2的整数幂)-1 。

3. PG(Placement Group),用途是对 object 的存储进行组织和位置映射, (类似于 redis cluster 里面的 slot 的概念) 一个 PG 里面会有很多 object。采用 CRUSH 算法，将 pgid 代入其中，然后得到一组 OSD。PG->OSD 映射：

a) CRUSH(pgid)->(osd1,osd2,osd3) 。

▍2.4 Ceph IO 伪代码流程

1 locator = object_name
2
3 obj_hash =  hash(locator)
4
5 pg = obj_hash % num_pg
6
7 osds_for_pg = crush(pg)    # returns a list of osds
8
9 primary = osds_for_pg[0]
10
11 replicas = osds_for_pg[1:]

客户端写数据 osd 过程：

• 1. 采用的是 librbd 的形式，使用 librbd 创建一个块设备，向这个块设备中写入数据。

• 2. 在客户端本地同过调用 librados 接口，然后经过 pool，rbd，object、pg 进行层层映射,在 PG 这一层中，可以知道数据保存在哪3个 OSD 上，这3个 OSD 分为主从的关系。

• 3. 客户端与 primay OSD 建立 SOCKET 通信，将要写入的数据传给 primary OSD，由primary OSD 再将数据发送给其他 replica OSD 数据节点。

▍2.7 Ceph Pool 和 PG 分布情况

说明：

• a. pool 是 ceph 存储数据时的逻辑分区，它起到 namespace 的作用。

• b. 每个 pool 包含一定数量(可配置)的 PG。

• c. PG 里的对象被映射到不同的 OSD 上。

• d. pool 是分布到整个集群的。

• e. pool 可以做故障隔离域，根据不同的用户场景不一进行隔离。

▍2.8 Ceph 数据扩容 PG 分布

场景数据迁移流程：

a. 现状3个 OSD, 4个 PG

b. 扩容到4个 OSD, 4个 PG

现状：

扩容后：

说明：

每个 OSD 上分布很多 PG, 并且每个 PG 会自动散落在不同的 OSD 上。如果扩容那么相应的 PG 会进行迁移到新的 OSD 上，保证 PG 数量的均衡。

▍3. Ceph 心跳机制

▍3.1 心跳介绍

心跳是用于节点间检测对方是否故障的，以便及时发现故障节点进入相应的故障处理流程。

问题：

a. 故障检测时间和心跳报文带来的负载之间做权衡。

b. 心跳频率太高则过多的心跳报文会影响系统性能。

c. 心跳频率过低则会延长发现故障节点的时间，从而影响系统的可用性。

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

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

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

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

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

▍3.2 Ceph 心跳检测

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

· public 端口：监听来自 Monitor 和 Client 的连接。

· cluster 端口：监听来自 OSD Peer 的连接。

· front 端口：供客户端连接集群使用的网卡, 这里临时给集群内部之间进行心跳。

· back 端口：供客集群内部使用的网卡。集群内部之间进行心跳。

· hbclient：发送 ping 心跳的 messenger。

▍3.3 Ceph OSD 之间相互心跳检测

步骤：

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

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

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

▍3.4 Ceph OSD与Mon心跳检测

OSD 报告给 Monitor：

• a. OSD 有事件发生时（比如故障、PG 变更）。

• b. 自身启动5秒内。

• c. OSD 周期性的上报给 Monito

• d. OSD 检查 failure_queue 中的伙伴 OSD 失败信息。

• e. 向 Monitor 发送失效报告，并将失败信息加入 failure_pending 队列，然后将其从 failure_queue 移除。

• f. 收到来自 failure_queue 或者 failure_pending 中的 OSD 的心跳时，将其从两个队列中移除，并告知 Monitor 取消之前的失效报告。

• g. 当发生与 Monitor 网络重连时，会将 failure_pending 中的错误报告加回到 failure_queue 中，并再次发送给 Monitor。

• h. Monitor 统计下线 OSD

• i. Monitor 收集来自 OSD 的伙伴失效报告。

• j. 当错误报告指向的 OSD 失效超过一定阈值，且有足够多的 OSD 报告其失效时，将该 OSD 下线。

▍3.5 Ceph 心跳检测总结

Ceph 通过伙伴 OSD 汇报失效节点和 Monitor 统计来自 OSD 的心跳两种方式判定 OSD 节点失效。

及时：

伙伴 OSD 可以在秒级发现节点失效并汇报 Monitor，并在几分钟内由 Monitor 将失效 OSD 下线。

适当的压力：

由于有伙伴 OSD 汇报机制，Monitor 与 OSD 之间的心跳统计更像是一种保险措施，因此 OSD 向 Monitor 发送心跳的间隔可以长达600秒，Monitor 的检测阈值也可以长达900秒。Ceph 实际上是将故障检测过程中中心节点的压力分散到所有的 OSD 上，以此提高中心节点 Monitor 的可靠性，进而提高整个集群的可扩展性。

容忍网络抖动：

Monitor 收到 OSD 对其伙伴 OSD 的汇报后，并没有马上将目标 OSD 下线，而是周期性的等待几个条件：

1. 目标 OSD 的失效时间大于通过固定量 osd_heartbeat_grace 和历史网络条件动态确定的阈值。

2. 来自不同主机的汇报达到 mon_osd_min_down_reporters。

3. 满足前两个条件前失效汇报没有被源 OSD 取消。

扩散：

作为中心节点的 Monitor 并没有在更新 OSDMap 后尝试广播通知所有的 OSD 和 Client，而是惰性的等待 OSD 和 Client 来获取。以此来减少 Monitor 压力并简化交互逻辑。

▍4. Ceph 通信框架

▍4.1 Ceph 通信框架种类介绍

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

Simple 线程模式

特点：每一个网络链接，都会创建两个线程，一个用于接收，一个用于发送。

缺点：大量的链接会产生大量的线程，会消耗 CPU 资源，影响性能。

Async 事件的I/O多路复用模式

特点：这种是目前网络通信中广泛采用的方式。k版默认已经使用 Asnyc 了。

XIO 方式使用了开源的网络通信库 accelio 来实现

特点：这种方式需要依赖第三方的库 accelio 稳定性，目前处于试验阶段。

▍4.2 Ceph 通信框架设计模式

设计模式(Subscribe/Publish)：

订阅发布模式又名观察者模式，它意图是“定义对象间的一种一对多的依赖关系，

当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新”。

▍4.3 Ceph 通信框架流程图

步骤：

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

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

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

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

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

▍4.4 Ceph 通信框架类图

▍4.5 Ceph 通信数据格式

通信协议格式需要双方约定数据格式。

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

· header //消息头，类型消息的信封

· user data //需要发送的实际数据

        o payload //操作保存元数据

        o middle //预留字段

        o data //读写数据

        o footer //消息的结束标记

1   class Message : public RefCountedObject {
2   protected:
3    ceph_msg_header  header;      // 消息头
4    ceph_msg_footer  footer;      // 消息尾
5    bufferlist       payload;  // "front" unaligned blob
6    bufferlist       middle;   // "middle" unaligned blob
7    bufferlist       data;     // data payload (page-alignment will be preserved where possible)
8 
9  /* recv_stamp is set when the Messenger starts reading the
10  * Message off the wire */
11 utime_t recv_stamp;       //开始接收数据的时间戳
12  /* dispatch_stamp is set when the Messenger starts calling dispatch() on
13    * its endpoints */
14   utime_t dispatch_stamp;   //dispatch 的时间戳
15  /* throttle_stamp is the point at which we got throttle */
16  utime_t throttle_stamp;   //获取throttle 的slot的时间戳
17   /* time at which message was fully read */
18   utime_t recv_complete_stamp;  //接收完成的时间戳
19
20  ConnectionRef connection;     //网络连接
21 
22  uint32_t magic = 0;           //消息的魔术字
23 
24  bi::list_member_hook<> dispatch_q;  //boost::intrusive 成员字段
25  };
26
27 struct ceph_msg_header {
28     __le64 seq;       // 当前session内 消息的唯一 序号
29     __le64 tid;       // 消息的全局唯一的 id
30     __le16 type;      // 消息类型
31     __le16 priority;  // 优先级
32     __le16 version;   // 版本号 
33
34     __le32 front_len; // payload 的长度
35     __le32 middle_len;// middle 的长度
36     __le32 data_len;  // data 的 长度
37     __le16 data_off;  // 对象的数据偏移量
38
39
40    struct ceph_entity_name src; //消息源
41
42    /* oldest code we think can decode this.  unknown if zero. */ 
43     __le16 compat_version;
44     __le16 reserved;
45     __le32 crc;       /* header crc32c */
46   } __attribute__ ((packed));
47
48   struct ceph_msg_footer {
49    __le32 front_crc, middle_crc, data_crc; //crc校验码
50    __le64  sig; //消息的64位signature
51    __u8 flags; //结束标志
52  } __attribute__ ((packed));

▍5. Ceph CRUSH 算法

▍5.1 数据分布算法挑战

数据分布和负载均衡：

1. 数据分布均衡，使数据能均匀的分布到各个节点上。

2. 负载均衡，使数据访问读写操作的负载在各个节点和磁盘的负载均衡。

灵活应对集群伸缩：

1. 系统可以方便的增加或者删除节点设备，并且对节点失效进行处理。

2. 增加或者删除节点设备后，能自动实现数据的均衡，并且尽可能少的迁移数据。

支持大规模集群：

1. 要求数据分布算法维护的元数据相对较小，并且计算量不能太大。随着集群规模的增 加，数据分布算法开销相对比较小。

▍5.2 Ceph CRUSH 算法说明

CRUSH 算法的全称为：Controlled Scalable Decentralized Placement of Replicated Data，可控的、可扩展的、分布式的副本数据放置算法。

PG到OSD 的映射的过程算法叫做 CRUSH 算法。(一个 Object 需要保存三个副本，也就是需要保存在三个 osd 上)。

CRUSH 算法是一个伪随机的过程，他可以从所有的 OSD 中，随机性选择一个 OSD 集合，但是同一个 PG 每次随机选择的结果是不变的，也就是映射的 OSD 集合是固定的。

▍5.3 Ceph CRUSH 算法原理

CRUSH 算法因子：

层次化的 Cluster Map

反映了存储系统层级的物理拓扑结构。定义了 OSD 集群具有层级关系的静态拓扑结构。OSD 层级使得 CRUSH 算法在选择 OSD 时实现了机架感知能力，也就是通过规则定义， 使得副本可以分布在不同的机 架、不同的机房中、提供数据的安全性 。

Placement Rules

决定了一个 PG 的对象副本如何选择的规则，通过这些可以自己设定规则，用户可以自定义设置副本在集群中的分布。

● 5.3.1 层级化的 Cluster Map

CRUSH Map 是一个树形结构，OSDMap 更多记录的是 OSDMap 的属性(epoch/fsid/pool 信息以及 osd 的 ip 等等)。

叶子节点是 device（也就是 osd），其他的节点称为 bucket 节点，这些 bucket 都是虚构的节点，可以根据物理结构进行抽象，当然树形结构只有一个最终的根节点称之为 root 节点，中间虚拟的 bucket 节点可以是数据中心抽象、机房抽象、机架抽象、主机抽象等。

● 5.3.2 数据分布策略 Placement Rules

数据分布策略 Placement Rules 主要有特点：

1. 从 CRUSH Map 中的哪个节点开始查找

2. 使用那个节点作为故障隔离域

3. 定位副本的搜索模式（广度优先 or 深度优先）

1 rule replicated_ruleset  #规则集的命名，创建pool时可以指定rule集
2 
3 {
4
5    ruleset 0                #rules集的编号，顺序编即可 
6
7    type replicated          #定义pool类型为replicated(还有erasure模式) 
8
9     min_size 1                #pool中最小指定的副本数量不能小1
10 
11    max_size 10               #pool中最大指定的副本数量不能大于10
12 
13    step take default         #查找bucket入口点，一般是root类型的bucket 
14 
15    step chooseleaf  firstn  0  type  host #选择一个host,并递归选择叶子节点osd 
16
17    step emit        #结束
18
19 }