Ceph 细节原理
OSD daemon
osd daemon 状态: 默认每2s汇报自己的状态给monitor (同时监控组内其他OSD状态)
up
:可以提供IOdown
:不能提供IOin
:有数据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
来产生的;
- 在
monitor
节点上会运行一个叫PG monitor
的进程; - 定时检索整个集群中是否存在新建的存储池
pool
(这个存储池其实就一个一堆 PG 的集合
); - 当发现新的
存储池
时,会继续检查存储池中的 PG 状态; - 检查出PG的状态为新状态(待创建),该PG会进入一个
creating
的状态,会把该PG放到创建队列中 - 之后
monitor
再根据CRUSH
算法 计算得出 PG 中包含的三个OSD daemon
同时算出组长; - 此时
monitor
会把刚刚计算出来的所有PG
、OSD daemon
的信息直接发给组长; PG
中的OSD daemon
组长收到信息后,此时组员之间的就知道彼此,这个过程叫做peering
建立连接;- 最终生成
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内没有汇报自己的状态给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组中
PG 内 OSD 的数据校验方式
- HASH 校验,同PG下的OSD数据进行HASH比较,副本OSD会跟主OSD比较,有区别就会同步主OSD的数据
- 版本号校验,同PG下的OSD数据每次同步时,都会产生一个版本号,当版本号有差异时,会同步数据
- 数据大小
SIZE
的比较,同PG下的OSD数据直接比较大小,有差异的副本OSD就会同步主OSD的数据
pool:存储池
提供的功能:
- PG 的逻辑集合
- 副本数,提供数据冗余性
- CRUSH 规则,PG 是如何 发现 OSD 的
- 存储池存在用户权限
pool 类型:
- 复制类型 一个 PG 中 有多个 OSD
- 纠错码类型 分为 k 个 数据块、M个编码快,然后进行存放,没有一个数据存放多份
缺点:1.速度慢 2. 不支持Ceph 所有的操作 ,如:在数据清理是,不支持局部锁定清理的功能