每一个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

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是否支持这个特性。

root@host:/home/demo# ceph mgr module ls
{
    "always_on_modules": [
        "balancer",
        "crash",
        "devicehealth",
        "orchestrator_cli",
        "progress",
        "rbd_support",
        "status",
        "volumes"
    ],
    "enabled_modules": [
        "iostat",
        "restful"
    ],

新版本已经不支持手动关闭。

root@host:/home/demo# ceph mgr module disable balancer
Error EINVAL: module 'balancer' cannot be disabled (always-on)

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

root@host:/home/demo# ceph balancer status
{
    "last_optimize_duration": "0:00:22.402340",
    "plans": [],
    "mode": "crush-compat",
    "active": false,
    "optimize_result": "Unable to find further optimization, change balancer mode and retry might help",
    "last_optimize_started": "Tue Nov 16 18:29:38 2021"
}

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

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

3.资源池自动伸缩 autoscale

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

#默认策略是warn
root@host:/home/demo# ceph daemon /home/ceph/var/run/ceph-osd.10.asok config show|grep scale
    "osd_pool_default_pg_autoscale_mode": "warn",
    "rgw_rados_pool_autoscale_bias": "4.000000",

#通过pool set命令设置对应策略
root@host:/home/demo# ceph osd pool set
Invalid command: missing required parameter pool(<poolname>)
osd pool set <poolname> size|min_size|pg_num|pgp_num|pgp_num_actual|crush_rule|hashpspool|nodelete|nopgchange|nosizechange|write_fadvise_dontneed|noscrub|nodeep-scrub|hit_set_type|hit_set_period|hit_set_count|hit_set_fpp|use_gmt_hitset|target_max_bytes|target_max_objects|cache_target_dirty_ratio|cache_target_dirty_high_ratio|cache_target_full_ratio|cache_min_flush_age|cache_min_evict_age|min_read_recency_for_promote|min_write_recency_for_promote|fast_read|hit_set_grade_decay_rate|hit_set_search_last_n|scrub_min_interval|scrub_max_interval|deep_scrub_interval|recovery_priority|recovery_op_priority|scrub_priority|compression_mode|compression_algorithm|compression_required_ratio|compression_max_blob_size|compression_min_blob_size|csum_type|csum_min_block|csum_max_block|allow_ec_overwrites|fingerprint_algorithm|pg_autoscale_mode|pg_autoscale_bias|pg_num_min|target_size_bytes|target_size_ratio <val> {--yes-i-really-mean-it} :  set pool parameter <var> to <val>


root@host:/home/demo# ceph osd pool get .rgw.root pg_autoscale_mode
pg_autoscale_mode: warn

具体的设置参考这里

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的基本原理和机制，这里就不再赘述了，感兴趣的同学去看之前的文章内容吧。

https://docs.ceph.com/en/latest/radosgw/dynamicresharding/

总结

无论新手还是老司机，凡是Ceph分布式系统里面的自动化机制，都要尽可能了解其背后逻辑与机制，谨慎开启。很多时候自动化/傻瓜化的设定，只是开发人员的一厢情愿，他们不会了解运维、生产环境的复杂度，很难做到100%适配你的业务场景，因此要想不被带进沟里，先得开启对这些基础知识的深入探索和学习，在实践中去验证这些功能的有效性，而不是一开始就把一切都寄托在官方的默认设定上。

发表评论

邮箱地址不会被公开。 必填项已用*标注