osd daemon 状态: 默认每2s汇报自己的状态给monitor (同时监控组内其他OSD状态)
up
:可以提供IOdown
:不能提供IOin
:有数据out
:没有数据epoach
: 单调递增的版本号,用于数据校验使用acting set
: OSD 列表,第一个为 primary OSD
,其余的为replicated OSD
PG 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