osd daemon 状态: 默认每2s汇报自己的状态给monitor (同时监控组内其他OSD状态)
up :可以提供IOdown :不能提供IOin :有数据out :没有数据epoach: 单调递增的版本号,用于数据校验使用acting set: OSD 列表,第一个为 primary OSD,其余的为replicated OSDPG tmp:当主OSD故障后,monitor 通过 CRUSH 找一个OSD顶替,但此OSD中没有数据,会在副本OSD中临时当做主的,就是此状态up set: 是 acting set 过去版本,是出现 PG tmp后,以前的一个版本如在 副本数为 3 的配置中,一个
PG中 包含 三个OSD daemon,也就是三块硬盘,其中一个是master,剩下两个是副本;
PG 和 OSD daemon 之间的关系,是通过 CRUSH 算法得出的;常规这三个 OSD daemon 可以在一台机器上,也可以在不同机器上;那么根据 CRUSH 算法会尽可能的保证一个平衡,就是不在同一个机器上;毕竟Ceph中的数据是一个为平衡的状态,一切都是通过CRUSH 算法来实现的数据平衡;
而 PG 本身是个有序列表,位于第一的位置是 master;这个列表的产生是由 monitor 来产生的;
monitor 节点上会运行一个叫 PG monitor 的进程;pool(这个存储池其实就一个一堆 PG 的集合);存储池 时,会继续检查存储池中的 PG 状态;creating 的状态,会把该PG放到创建队列中monitor 再根据 CRUSH 算法 计算得出 PG 中包含的三个 OSD daemon 同时算出组长;monitor 会把刚刚计算出来的所有 PG、 OSD daemon 的信息直接发给组长;PG 中的 OSD daemon 组长收到信息后,此时组员之间的就知道彼此,这个过程叫做 peering 建立连接;PG由以上步骤看出,PG 实际是个逻辑单位,PG 的信息保存在 crush map 和 OSD daemon 中。
ceph -s 命令查看
creating: 正在创建的状态peering: PG内OSD内相互认知的状态active: PG内OSD相互认识后,就会处于此状态,能写数据,但PG内的OSD相互数据并没有同步clean:PG内的的OSD能写数据,并且所有的OSD的数据已同步stable:PG 内有OSD在 2s内没有汇报自己的状态给monitorbackfilling:一个新的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组中
SIZE 的比较,同PG下的OSD数据直接比较大小,有差异的副本OSD就会同步主OSD的数据提供的功能:
pool 类型:
原文:https://www.cnblogs.com/winstom/p/12499750.html