ceph卡在active+remapped状态
最近看到了有人的环境出现了出现了卡在active+remapped状态，并且卡住不动的状态，从pg的状态去看，这个pg值分配了主的pg，没有分配到副本的osd，集群的其他设置一切正常
这个从网上搜寻到的资料来看，大多数都是由于不均衡的主机osd引起的，所谓不平衡的osd
- 一台机器上面的磁盘的容量不一样，有的3T，有的1T
- 两台主机上面的OSD个数不一样，有的5个，有的2个
这样会造成主机的crush 的weight的差别很大的问题，以及分布算法上的不平衡问题，建议对于一个存储池来说，它所映射的osd至少需要是磁盘大小一致和个数一致的
这个问题我在我的环境下做了复现，确实有卡在remapped的问题
出现这个情况一般是什么操作引起的？
做osd的reweight的操作引起的，这个因为一般在做reweight的操作的时候，根据算法，这个上面的pg是会尽量分布在这个主机上的，而crush reweight不变的情况下，去修改osd 的reweight的时候，可能算法上会出现无法映射的问题
怎么解决这个问题？
直接做osd crush reweigh的调整即可避免这个问题，这个straw算法里面还是有点小问题的，在调整某个因子的时候会引起整个因子的变动
之前看到过sage在回复这种remapped问题的时候，都是不把这个归到bug里面去的，这个我也认为是配置问题引起的极端的问题，正常情况下都能避免的
更新
从FIREFLY (CRUSH_TUNABLES3)开始crush里面增加了一个参数：
chooseleaf_vary_r
是否进行递归的进行chooseleaf，如果非0，就递归的进行，这个基于parent已经做了多少次尝试，默认是0，但是常常找不到合适的mapping.在计算成本和正确性上来看最佳的值是1
对迁移的影响,对于已经有大量数据的集群来说，从0调整为1将会有大量的数值的迁移，调整为4或者5的话，将会找到一个更有效的映射，可以减少数据的移动
查看当前的值
[root@lab8106 ~]# ceph osd crush show-tunables |grep chooseleaf_vary_r
"chooseleaf_vary_r": 0,
修改crushmap内容
修改chooseleaf_vary_r的值
hammer版本下这个参数默认为：
tunable chooseleaf_vary_r 0
jewel版本下这个参数默认为：
tunable chooseleaf_vary_r 1
这个是跟 tunables 的版本有关的
注意：在 3.15 之前的版本中，chooseleaf_vary_r 的值必须为0(原因未知)
参考资料
变更记录
| Why | Who | When |
|---|---|---|
| 创建 | 武汉-运维-磨渣 | 2016-05-14 |
| 修改 | 武汉-运维-磨渣 | 2016-09-23 |
最新文章
- DockerCon 2016 – 微软带来了什么？
- JNI 备注
- ISP路由表分发中的AS与BGP
- Python之路【第七篇】python基础 之socket网络编程
- AngularJs $q promise
- linux 调用java main方法
- Oracle几个基础配置问题：ORA-12154: TNS: 无法解析指定的连接标识符、ORA-12514: TNS: 监听程序当前无法识别连接描述符中请求的服务、ORA-12516 TNS监听程序找不到符合协议堆栈要求的可用处理程序
- Oracle 字符串函数
- 01-Java基础知识：数据类型与变量、标识符、运算符、表达式
- Hibernate关系级别注解
- p2.js物理引擎学习
- IntelliJ IDEA “Finds duplicated code”提示如何关闭
- 简述Apache的ab测试主要有那些关键指标
- C:数据结构与算法之顺序表
- Oracle (11g) 修改默认的用户名及密码
- 15、解决14中csv用excel打开乱码的问题 open('zhihu.csv','w',newline='',encoding='utf-8-sig')
- Jquery+php 动态web表单增删改查
- 交换机telnet配置
- ENode, 领域模型，DDD
- 20165326 java第三周学习笔记