引言
最近接触了两个集群都使用到了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 |