Ceph自动化四大坑王

Ceph自动化四大坑王

Deng YongJie's blog 509 2023-04-22

Ceph 自动化四大坑王

每一个Ceph新手,都或多或少被文中提到的四大坑王吊打过,或钢筋铁骨成为大神,或删库跑路沦为亡魂。因此有必要普及一下这四大坑王的手段。

本文需建立在你已经基本了解Ceph的构架和基本原理,如果不熟悉的可以看下面内容:

https://docs.ceph.com/en/pacific/architecture/

1.OSD自动化加入crush

很多新手,上来也不看基本的Crush算法原理,照着其他人的ceph.conf就是抄作业,其中抄得最不走心的就是下面这条配置。

osd crush update on start = false

重启以后或者加入新的OSD,发现自己的集群pg异常了,一个个OSD成了没妈的孩子,到处都是小蝌蚪找妈妈。殊不知,默认Crushmap中会按host为单位,自动化将启动的osd加入到所在的host中,如果你开启了这个osd crush update on start = false的配置,则会关掉自动化分配,只能按用户自定义的Crushmap分布规则进行配置,而新手往往都没有自定义的Crushmap规则,于是就遇上了一大堆的孤儿osd。所以抄作业之前,一定要搞清楚自己的环境和对方环境的差异性,盲抄作业是要吃大亏的。

每一个新手,一定要去学习的就是crush算法的基本原理,并认真按照下面的文档,进行crush-map编辑操作的学习与模拟。

https://docs.ceph.com/en/pacific/rados/operations/crush-map-edits/

类似的设置还有osd class update on start = false

解决方法:新集群建立初期,可以自动化分布规则后,再进行反编译Crushmap,修改rule规则、osd权重等

2.pg自动化平衡 balancer

掌握基本的Crush算法和基本概念,会你发现crush的伪随机算法并不能100%确保你的每一个OSD都能均衡的实现数据分布,随着你写入的数据增加,很多情况下会发现OSD磁盘的利用率非常的不均匀。于是你会遇上如何平衡OSD数据分布这一难题,好在官方也一直在努力做好这件事情,并推出了一系列自动化工具。

The balancer can optimize the placement of PGs across OSDs in order to achieve a balanced distribution, either automatically or in a supervised fashion.

最早的时候是通过扩展mgr模块,实现了一个名为balancer的模块,通过手工方式来调度这个模块,实现OSD上面的PG分布调优。你可以通过下面的命令查看你的ceph是否支持这个特性。

ceph mgr module ls|head -20

{
    "always_on_modules": [
        "balancer",
        "crash",
        "devicehealth",
        "orchestrator",
        "pg_autoscaler",
        "progress",
        "rbd_support",
        "status",
        "telemetry",
        "volumes"
    ],
    "enabled_modules": [
        "dashboard",
        "iostat",
        "nfs",
        "prometheus",
        "restful"
    ],

新版本手动关闭命令:

ceph balancer off

你可以通过下面的命令查看当前该模块的开启状态

ceph balancer status
{
    "active": true, #这是关闭之前的状态
    "last_optimize_duration": "0:00:00.071703",
    "last_optimize_started": "Tue Apr 18 10:40:40 2023",
    "mode": "upmap",
    "optimize_result": "Unable to find further optimization, or pool(s) pg_num is decreasing, or distribution is already perfect",
    "plans": []
}

一旦balancer的active=true,那么这里的坑就挖好了,之后随着你集群的用量变化,一旦满足自动balancer调节条件,集群就会自动化实现OSD上的PG调整。PG自动化平衡功能是很多新手看起来很美好的事情,但是真正用起来你会发现,集群压力大的时候自动化平衡一下,或者频繁的触发了自动化平衡,你的集群性能会持续抖动,最终造成业务延迟增加或者卡顿,要命的是一旦触发平衡还不能中途停止,因此只能等待平衡完成,但是平衡这种事情,很多时候是没办法预期什么时候开始、什么时候结束,因此集群的性能也是处于间歇性抽风。所以生产上,这种策略能关闭最好,看起来的美好,更多的是带来无尽烦恼。具体可以参考下面

https://docs.ceph.com/en/latest/rados/operations/balancer/#balancer

举例:

dev环境的ceph集群,客户端偶发性连接超时、io 100%,主要原因是:

1.osd进行scrub,由于scrub时间设置在凌晨00-08进行,如果在此期间scrub没有完成任务,则会继续执行,因此导致了24小时不间断循环scrub,底层存储占用了大部分IO,引发osd down,导致osd震荡。

2.pg auto balancer,满足 auto balancer的条件,则多个存储池同事开始 auto balancer,导致集群性能抖动,客户端延迟增加或者卡顿。

3.资源池自动伸缩 autoscale

作为新手,你是不是还在幻想着集群扩容,只需要简单的加机器加磁盘,然后调整一下PG数一顿操作猛如虎就行了。残酷的现实就是,一旦你做了这件事情,集群性能就会因为数据平衡而抽风,如何平衡扩容带来的性能影响已经是一门Ceph维护的艺术。然鹅,官方贴心的给各位开发了一个自动化pg扩容模块,根据集群的当前规模,实现自动化的pg数设定,不再让新手烦恼。好在默认是开启的warn模式,只是在特定情况下会告警,但是不做执行。如果你线上经常性的扩容/缩容,那么你打开这个pg_autoscale_mode=on,会体会到无与伦比的酸爽,如果你想让自己睡个好觉,就老老实实off掉这个模块吧,不要瞎折腾才是上上策,自动化的东西没你看起来那么美好。

#新版默认策略是on
root@cluster-ceph-01:~# ceph --admin-daemon  /var/run/ceph/ceph-osd.0.asok config show | grep scale
    "osd_pool_default_pg_autoscale_mode": "on",
    "rgw_rados_pool_autoscale_bias": "4.000000",

root@cluster-ceph-01:~# ceph osd pool get .rgw.root pg_autoscale_mode
pg_autoscale_mode: on


#通过pool set命令设置对应策略
#全局生效,在随后创建的pool中,默认都是关闭
root@cluster-ceph-01:~# ceph config set global osd_pool_default_pg_autoscale_mode off

#关闭后查看配置
root@cluster-ceph-01:~# ceph --admin-daemon  /var/run/ceph/ceph-osd.0.asok config show | grep scale
    "osd_pool_default_pg_autoscale_mode": "off",
    "rgw_rados_pool_autoscale_bias": "4.000000",


#已创建的pool,需要逐个手动关闭
root@cluster-ceph-01:~# ceph osd pool set <pool-name> pg_autoscale_mode off
ceph osd pool set .rgw.root pg_autoscale_mode off

#查看单个pool
root@cluster-ceph-01:~# ceph osd pool get .rgw.root pg_autoscale_mode

具体的设置参考这里

https://docs.ceph.com/en/latest/rados/operations/placement-groups/#autoscaling-placement-groups

4.RGW自动化Shard重分配

最后一个可能只有部分RGW用户会遇到,当单个Bucket内的文件数量不断增长,其底层的数据库分片会不断的进行ReShard,整个reshard过程不可控,文件数越多时间越长,reshard过程中因为要加锁,因此会导致业务卡IO,直接造成服务不可用。所以这个特性在官方推出的时候,我第一时间就是进行了rgw_dynamic_resharding = false关闭,shard的基本原理和机制后面再整理。