深入Ceph原理包含核心算法Crush说明和通信机制原理（五）（下）

四、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 变成副本。

五、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 处理消息。

六、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数据节点。

七、Ceph 心跳和故障检测机制

问题：

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

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

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

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

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

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

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

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

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