ceph erasure默认的min_size分析

引言

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

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

分析过程

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

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

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

[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以后，状态变成了这样的

[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的控制改为了

*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设计成了

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来实现继续使用

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