ceph erasure默认的min_size分析

引言

最近接触了两个集群都使用到了erasure code,一个集群是hammer版本的,一个环境是luminous版本的,两个环境都出现了incomplete,触发的原因有类似的地方,都是有osd的离线的问题

准备在本地环境进行复验的时候,发现了一个跟之前接触的erasure不同的地方,这里做个记录,以防后面出现同样的问题

分析过程

准备了一个luminous的集群,使用默认的erasure的profile进行了创建存储池的相关工作

1
2
3
4
5
[root@lab102 ~]# ceph osd erasure-code-profile get default
k=2
m=1
plugin=jerasure
technique=reed_sol_van

默认的是2+1的纠删码的配置,创建完了以后存储池的配置是这样的

1
2
[root@lab102 ~]# ceph osd dump|grep pool
pool 1 'rbd' erasure size 3 min_size 3 crush_rule 2 object_hash rjenkins pg_num 256 pgp_num 256 last_change 41 flags hashpspool stripe_width 8192 application rbdrc

然后停止了一个osd以后,状态变成了这样的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@lab102 ~]# ceph -s
cluster:
id: 9ec7768a-5e7c-4f8e-8a85-89895e338cca
health: HEALTH_WARN
1 osds down
Reduced data availability: 42 pgs inactive, 131 pgs incomplete

services:
mon: 1 daemons, quorum lab102
mgr: lab102(active)
osd: 6 osds: 5 up, 6 in

data:
pools: 3 pools, 288 pgs
objects: 1666k objects, 13331 MB
usage: 319 GB used, 21659 GB / 21979 GB avail
pgs: 45.486% pgs not active
157 active+clean
131 incomplete

停止一个osd也会出现incomplete的状态,也就是在默认状态下,是一个osd也不允许down掉的,不然pg就进入了无法使用的状态,这个在我这里感觉无法理解的,开始以为这个是L版本的bug,在查了下资料以后,发现并不是的

查询到一个这样的patch:default min_size for erasure pools

这个里面就讨论了min_size的问题,上面的环境我也发现了,默认的配置的2+1,这个在我的理解下,正常应该会配置为min_size 2,在down掉一个的时候还是可写,可读的

实际上在/src/mon/OSDMonitor.cc 这个里面已经把erasure的min_size的控制改为了

1
2
3
*min_size = erasure_code->get_data_chunk_count();
变成
*min_size = erasure_code->get_data_chunk_count() + 1;

最后面作者提出了自己的担心,假如在K+M的配置下,只有K个的osd允许可以读写的时候,环境是K个OSD是好的,M个OSD挂掉了,这个时候启动一个M中的osd的时候,会进行backfilling,这个时候如果K个osd当中的某个osd挂掉的话,这个时候实际上PG里面的数据就是不完整的,如果是K+1的时候,这个时候做恢复的时候再挂掉一个,实际上还是完整的,也就是开发者考虑的是恢复过程的异常状况还留一个冗余,这个实际我们在日常的维护过程当中也经常遇到恢复过程中确实有osd的挂掉的情况,这个在其他文件系统里面的做法是设计成可读不可写状态

也就是现在ceph的erasure的min_size设计成了

1
min_size=K+1

也就是默认的环境下的是min_size是3

到这里就知道上面为什么会出现上面的状况了,也就是这个编码设置的时候需要自己去控制下,比如4+2的ec,最多能挂掉几个,如果在以前可以很肯定的说是2个,实际在新的情况下是4+1=5也就是只允许挂掉一个是可读可写的

当然真正生产环境出现了4+2挂掉两个变成了incomplete的时候,因为这个时候数据还是完整可拼接的,所以可以强制mark-complete或者自己把代码里面的min_size改掉来触发恢复也是可以的

总结

对于ec这块接触的很早,里面还是有很多有意思的可以研究的东西的,ec最适合的场景就是归档,当然在某些配置下面,性能也是很不错的,也能支持一些低延时的任务,这个最大的特点就是一定需要根据实际环境去跑性能测试,拆成几比几性能有多少,这个一般还是不太好预估的,跟写入的文件模型也有关联

虽然作者的设计初衷是没问题的,但是这个默认配置实际是不符合生产要求的,所以个人觉得这个不是很合理,默认的应该是不需要调整也是可用的,一个osd也不允许down的话,真正也没法用起来,所以不清楚是否有其他可改变的配置来处理这个,自己配置的时候注意下这个min_size,如果未来有控制的参数,会补充进这篇文章

补充

通过测试发现,可以通过存储池设置这个min_size来实现继续使用

1
ceph osd pool set rbd min_size 2

也就是这个地方跟副本池的设计类似,给定一个初始值,然后可以通过设置进行修改

官方已经更新这里

https://github.com/ceph/ceph/pull/8008

Default min_size to k+1

已经准备改成了

min_size = k + min(1, m - 1)

变更记录

Why Who When
创建 武汉-运维-磨渣 2018-06-12
更新ec的min_size设置 武汉-运维-磨渣 2018-06-12
官方修改ec的min_size设置 武汉-运维-磨渣 2019-03-21