Ceph 细节原理

目录

Ceph 细节原理

OSD daemon

osd daemon 状态： 默认每2s汇报自己的状态给monitor (同时监控组内其他OSD状态)

  1. up ：可以提供IO
  2. down ：不能提供IO
  3. in ：有数据
  4. out ：没有数据

PG 的概念

  • epoach: 单调递增的版本号，用于数据校验使用
  • acting set： OSD 列表，第一个为 primary OSD，其余的为replicated OSD
  • PG tmp：当主OSD故障后，monitor 通过 CRUSH 找一个OSD顶替，但此OSD中没有数据，会在副本OSD中临时当做主的，就是此状态
    当新调过来的主OSD数据同步完成后，恢复正常状态
  • up set: 是 acting set 过去版本，是出现 PG tmp后，以前的一个版本

PG 中 OSD 组长是如何建立的

如在 副本数为 3 的配置中，一个 PG 中 包含 三个 OSD daemon，也就是三块硬盘，其中一个是 master，剩下两个是 副本；

PG 和 OSD daemon 之间的关系，是通过 CRUSH 算法得出的；常规这三个 OSD daemon 可以在一台机器上，也可以在不同机器上；那么根据 CRUSH 算法会尽可能的保证一个平衡，就是不在同一个机器上；毕竟Ceph中的数据是一个为平衡的状态，一切都是通过CRUSH 算法来实现的数据平衡；

而 PG 本身是个有序列表，位于第一的位置是 master；这个列表的产生是由 monitor 来产生的；

  1. 在 monitor 节点上会运行一个叫 PG monitor 的进程;
  2. 定时检索整个集群中是否存在新建的存储池pool(这个存储池其实就一个一堆 PG 的集合)；
  3. 当发现新的 存储池 时，会继续检查存储池中的 PG 状态；
  4. 检查出PG的状态为新状态(待创建)，该PG会进入一个creating 的状态，会把该PG放到创建队列中
  5. 之后 monitor 再根据 CRUSH 算法 计算得出 PG 中包含的三个 OSD daemon 同时算出组长；
  6. 此时 monitor 会把刚刚计算出来的所有 PG、 OSD daemon 的信息直接发给组长；
  7. PG 中的 OSD daemon 组长收到信息后，此时组员之间的就知道彼此，这个过程叫做 peer 建立连接；
  8. 最终生成PG

由以上步骤看出，PG 实际是个逻辑单位，PG 的信息保存在 crush map 和 OSD daemon 中。

PG 的状态

ceph -s 命令查看

  • creating： 正在创建的状态
  • peering： PG内OSD内相互认知的状态
  • active： PG内OSD相互认识后，就会处于此状态，能写数据，但PG内的OSD相互数据并没有同步
  • clean：PG内的的OSD能写数据，并且所有的OSD的数据已同步
  • stable：PG 内有OSD在 2s内没有汇报自己的状态给monitor
  • backfilling：一个新的OSD被加入到PG组内，正在做全量的数据拷贝
  • recovery：同PG组内一个OSD与主OSD的数据存在差异被检测出来，会被改为此状态，同时进行数据同步

stable 状态说明：

monitor 一旦发现 OSD daemon 没有汇报状态，会立即把此OSD daemon对应的PG组，标记为 stable;
表示该 PG 组内有OSD daemon在 2s 中没有汇报状态；如果在300s内OSD daemon还没有汇报状态，此 OSD daemon 就会被踢出 对应的PG组；
被踢出后，PG组内的副本数就变少了，monitor 又会使用 CRUSH 算法重新加入一个新的 OSD daemon 加入到PG组中

PG 内 OSD 的数据校验方式

  1. HASH 校验，同PG下的OSD数据进行HASH比较，副本OSD会跟主OSD比较，有区别就会同步主OSD的数据
  2. 版本号校验，同PG下的OSD数据每次同步时，都会产生一个版本号，当版本号有差异时，会同步数据
  3. 数据大小SIZE 的比较，同PG下的OSD数据直接比较大小，有差异的副本OSD就会同步主OSD的数据

pool：存储池

提供的功能：

  1. PG 的逻辑集合
  2. 副本数，提供数据冗余性
  3. CRUSH 规则，PG 是如何 发现 OSD 的
  4. 存储池存在用户权限

pool 类型：

  1. 复制类型 一个 PG 中 有多个 OSD
  2. 纠错码类型 分为 k 个 数据块、M个编码快，然后进行存放，没有一个数据存放多份
    缺点：1.速度慢 2. 不支持Ceph 所有的操作 ，如：在数据清理是，不支持局部锁定清理的功能

Ceph 心跳机制

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

问题：

  • 故障检测时间和心跳报文带来的负载之间做权衡。
  • 心跳频率太高则过多的心跳报文会影响系统性能。
  • 心跳频率过低则会延长发现故障节点的时间，从而影响系统的可用性。

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

  • 及时：节点发生异常如宕机或网络中断时，集群可以在可接受的时间范围内感知。
  • 适当的压力：包括对节点的压力，和对网络的压力。
  • 容忍网络抖动：网络偶尔延迟。
  • 扩散机制：节点存活状态改变导致的元信息变化需要通过某种机制扩散到整个集群。

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

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

步骤：

  • 同一个PG内OSD互相心跳，他们互相发送PING/PONG信息。
  • 每隔6s检测一次(实际会在这个基础上加一个随机时间来避免峰值)。
  • 20s没有检测到心跳回复，加入failure队列。

OSD报告给Monitor：

  • OSD有事件发生时（比如故障、PG变更）
  • 自身启动5秒内。
  • SD周期性的上报给Monito
    • OSD检查failure_queue中的伙伴OSD失败信息。
    • 向Monitor发送失效报告，并将失败信息加入failure_pending队列，然后将其从failure_queue移除。
    • 收到来自failure_queue或者failure_pending中的OSD的心跳时，将其从两个队列中移除，并告知Monitor取消之前的失效报告。
    • 当发生与Monitor网络重连时，会将failure_pending中的错误报告加回到failure_queue中，并再次发送给Monitor。
  • Monitor统计下线OSD
    • Monitor收集来自OSD的伙伴失效报告。
    • 当错误报告指向的OSD失效超过一定阈值，且有足够多的OSD报告其失效时，将该OSD下线。

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下线，而是周期性的等待几个条件：
    • 目标OSD的失效时间大于通过固定量osd_heartbeat_grace和历史网络条件动态确定的阈值。
    • 来自不同主机的汇报达到mon_osd_min_down_reporters。
    • 满足前两个条件前失效汇报没有被源OSD取消。
  • 扩散：作为中心节点的Monitor并没有在更新OSDMap后尝试广播通知所有的OSD和Client，而是惰性的等待OSD和Client来获取。以此来减少Monitor压力并简化交互逻辑。

层级化的Cluster Map

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

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

在接下来的部署中，在配置的时候，就会按照此图配置，可以通过命令导出ceph 的cluster map。

Ceph 网络

ceph 分为两种网络

  • 集群网络

    • 客户端接入的网络，用于连接到Ceph集群
    • OSD 向 monitor 汇报状态，更新和维护 Cluster Map

  • 复制网络

    • PG 内部 OSD 之间的数据同步
    • PG 内部 OSD 之间的网络监控

Ceph 的缓存机制

1. 客户端的缓存

客户端的缓存 RBD缓存

通过libvirt 调用 qemu(vm),qemu 调用 librbd(librados) 最后访问到 Ceph

那么在这个过程中，是在 librbd(librados) 这一步下有一个 rdb cache 缓存

读和写都会先找 rdb cache缓存，没有之后才回去继续向后访问 ceph

rdb cache缓存分为两种：
1、write back		异步写，所有写的操作会写入到 rdb cache缓存，之后rdb cache缓存再想Ceph中写入
	优点： 速度快 
	缺点：数据不安全且读写可能会有误差
	试用场景：对数据安全性要求不高，且适用于读写混合型系统
2、write through 	同步写，一边写入到rdb cache缓存并写入到Ceph
	优点：度快，且数据安全
	缺点：写慢
	使用场景：度多，写少的场景，对数据安全要求高的

2. 服务端缓存

服务端的缓存 cache tiering 缓存分层

需要在服务端创建两类 pool，分为 SSD pool 和 机械硬盘 pool

可以配置 SSD pool 为 机械硬盘 pool 的缓存池，这样客户端写书数据先写入 SSD pool，然后 SSD pool 再同步到 机械硬盘 pool

  • 优点：存储性能可以提高
  • 缺点：成本太高，性能提升有限

客户端缓存 和 服务端缓存对比

  1. 客户端内存是基于内存级别，服务端缓存是基于SSD
  2. 服务端缓存不存在数据不一致的问题，因为是基于SSD
posted @ 2020-10-29 23:42  司家勇  阅读(503)  评论(0)  编辑  收藏  举报