Ceph 自动化四大坑王
每一个Ceph新手，都或多或少被文中提到的四大坑王吊打过，或钢筋铁骨成为大神，或删库跑路沦为亡魂。因此有必要普及一下这四大坑王的手段。
本文需建立在你已经基本了解Ceph的构架和基本原理，如果不熟悉的可以看下面内容:
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的基本原理和机制后面再整理。
