zoukankan      html  css  js  c++  java
  • 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
  • 相关阅读:
    PHP-redis中文文档
    thinkphp5操作redis系列教程】列表类型之lRange,lGetRange
    微信小程序利用canvas生成海报分享图片
    layui 富文本 图片上传 后端PHP接口
    Redis 学习笔记(十二)Redis 复制功能详解 ----- (error) READONLY You can't write against a read only slave
    php 从2维数组组合为四维数组分析(项目中前台侧边栏导航三级分类显示)
    MySQL中的外键是什么、有什么作用
    微信小程序之自定义模态弹窗(带动画)实例
    【JZOJ4805】【NOIP2016提高A组模拟9.28】跟踪
    【JZOJ4804】【NOIP2016提高A组模拟9.28】成绩调研
  • 原文地址:https://www.cnblogs.com/zphj1987/p/13575346.html
Copyright © 2011-2022 走看看