运维Ceph集群的人大概都逃不过这个场景某个周一早上监控突然报警cephfs的空间还剩不到10%客户端开始出现卡顿日志里全是POOL_FULL。你赶到机房一边安抚业务同事一边在脑子里飞快过了一遍解决方案——扩容量。于是你拉了一批新磁盘准备往集群里加OSD。又或者反过来老板让你降本增效回收几台服务器你得从集群里安全退掉一批OSD还不能让上面跑着的文件系统出任何状况。这两种操作一个加、一个减看似是Ceph运维里最常见的动作但真正做起来坑不少。尤其是配合CephFS这种对延迟和一致性都敏感的上层服务OSD的增减不只是执行几条命令那么简单。扩容后的数据均衡会影响客户端IO缩容时的数据迁移会占用空间和带宽稍有不慎就可能把集群状态从HEALTH_OK推到HEALTH_WARN甚至HEALTH_ERR。这篇就专门讲CephFS环境下OSD的增删从原理到实操再到我踩过的那些坑一条龙说清楚。1. 先搞明白CephFS和OSD的关系1.1 CephFS读写链路中的OSD角色CephFS不是个独立的文件系统守护进程它由三部分组成客户端挂载的基础MDS元数据服务器以及底层真正存放数据的OSD集群。当你访问一个CephFS目录客户端的请求会先经过MDS去查元数据——比如文件在哪个目录、叫什么、权限是什么。但文件内容本身是被切成一个个对象object通过CRUSH算法映射到osd上去刷盘的。这里容易有个错觉很多人以为CephFS的数据主要靠MDS管理OSD只是底层存储。实际上恰恰相反MDS只负责目录树和文件元数据真正的数据写入压力全都落在OSD上。一个OSD就是一个对象存储守护进程通常对应一块盘。CephFS的元数据池通常是cephfs_metadata和数据池cephfs_data最终都由OSD来承载。也就是说OSD的数量和健康度直接决定了这个文件系统的可用容量和整体性能。所以你在为CephFS扩容的时候本质上是在为文件系统增加可供数据落盘的OSD。缩容的时候也一样你是在减少文件系统可用的存储底座这个动作会触发数据迁移因为CRUSH算法需要重新分布数据保持副本数满足配置要求。1.2 什么情况下你会动OSD实践中增删OSD的触发原因就几类容量水位告急这是最常见的扩容信号。数据池使用率超过80%cephfs写入出现EDQUOT或者卡顿这时候你得加盘扩容。硬件故障替换某块盘IO错误SMART报警或者OSD频繁down你需要让这个OSD下线并更换硬件。缩容降本某些业务下线服务器要退回机房或者项目组要求把集群规模收敛这时候需要主动淘汰一批OSD。性能调优集群里OSD过少单个OSD承担的压力太大你希望增加OSD来分散IO压力提升并发能力。确定了你属于哪种场景才能选对操作路径。比如只是临时调低某个OSD的权重来压数据量跟直接remove掉一个OSD两者的风险等级完全不一样。下面我把增加和删除两个方向分开来写每个方向你都能照着一步步做。2. 增加OSD的完整操作流程2.1 硬件与系统准备在敲命令之前先花半小时把准备工作做扎实后面会省掉很多麻烦。第一件事是确认新磁盘的状态。拿到的机器可能装过系统或者被人用来放过ZFS/RAID分区直接交给ceph-volume很可能报错。我习惯上用lsblk和blkid看一眼盘符和文件系统类型如果有残留先用wipefs -a /dev/sdb把分区表和文件系统签名全清掉。注意这步会摧毁盘上所有数据操作前务必确认盘的序列号和你规划的槽位对得上。第二件事是检查网络和时钟。OSD之间的数据迁移、复制都走网络建议至少万兆网卡并且做了bond。同时NTP不能省时钟漂移会造成MON误判OSD宕机我在一个混合硬件集群里吃过这个亏。另外确认/etc/ceph/ceph.conf里配置了正确的cluster网络新加的节点如果网段不对找MON注册都费劲。第三件事确认你用的是哪种部署工具。如果集群是用cephadm部署的那加OSD可以直接走orch省事很多。如果是手动用ceph-volume部署的传统集群那你得确保新节点的OSD软件包已安装并且/etc/ceph/里放着和集群一致的keyring文件。两种方式下面都会讲到但核心逻辑是一样的让Ceph认领这块盘初始化为一个OSD。2.2 用ceph-volume部署一个OSD传统手动部署方式下我推荐用ceph-volume而不是老旧的ceph-disk前者支持BLUESTORE且功能更全。执行步骤大致是这样# 先清除磁盘残留 ceph-volume lvm zap /dev/sdb # 创建OSD自动创建LV并配置bluestore ceph-volume lvm create --data /dev/sdb执行完以后系统会创建一个以UUID为名的LV并把该块盘注册为OSD。你可以用ceph-volume lvm list查看结果确认磁盘设备、OSD ID和FSID对应关系。如果你的集群用的是cephadm命令更简单在MON所在的容器环境中执行ceph orch device ls ceph orch daemon add osd hostname:/dev/sdb或者直接让cephadm自动扫描未使用的设备ceph orch apply osd不过我不太建议在已有生产数据的情况下让orch全自动apply那可能会把一些规划外的盘也拉进来。最好手动指定主机和盘符一次一个稳。创建完OSD后它会自动加入CRUSH map进入集群并参与PG的数据分布。不需要手动调整权重因为刚加入的OSD权重是默认值CRUSH会逐步把PG迁移过来。这里有一个经验如果是老集群扩容新OSD加入后整个集群的PG会自动开始回填回填速度取决于集群里设置的osd_max_backfills参数。想让新盘尽快收到数据可以临时把这个值调高一点但不要超过8否则客户端IO延迟会明显上升。2.3 扩容后的验证与数据均衡OSD加完后至少要到第三步确认状态ceph osd tree ceph osd stat ceph health detail看三件事新的OSD状态是否为up和in集群整体HEALTH状态还是没有PG异常数据池里的PG是否在逐步回填。回填过程中你会看到很多activeremapped或者backfilling的PG这很正常说明数据正在重新分布。有个容易被忽略的细节CephFS有元数据池和数据池OSD扩容后你可能希望让某个文件系统专门使用新加的那批高性能盘而不是让它和旧数据混在一起。这时候需要提前把池的CRUSH规则区分开比如用ssd类别的OSD专门承载cephfs_data池。我在实际项目里见过太多人没规划好这个结果SATA和NVMe混在一个池里性能被低效盘拖垮。如果你有这个诉求得在添加OSD的时候给不同设备的OSD设置不同的device class然后为数据池创建对应的CRUSH rule。这个属于规划层面的话题不是简单加个盘就完事的但列出来提醒你。3. 删除OSD的完整操作流程3.1 删除前的评估和规划删OSD比加OSD危险得多因为数据要迁走期间任何意外都可能造成PG不可用。所以第一步别急着敲命令先回答这几个问题集群当前磁盘空间还剩多少数据迁移期间源OSD上的数据会被复制到其他OSD目标位置需要的容量约等于源OSD上已用数据量乘副本数再除以目标OSD数量总之会留出冗余。如果集群空间低于30%可用我劝你先别急着删。目标OSD上现在分布着哪些PG用ceph osd find id找到对应节点再看ceph pg ls-by-osd id里PG数量。如果这个OSD承担了很多热点PG删除前最好还是等业务低峰期。集群里有没有足够健康的OSD来接管数据查看ceph osd tree确认其他OSD状态正常没有大量down的盘。是否要保留这个OSD的数据副本如果是计划内更换硬件数据不需要保留直接走淘汰流程。做完整评估后我习惯先把目标OSD在纸面上记录下来OSD ID、对应宿主机、设备路径、实际使用的pool。这样后面无论哪一步出了问题都能快速回滚或定位。3.2 标准删除流程out - crush reweight - purge很多人上来就执行ceph osd rm那是大忌。除非你是想强行从集群里踢掉一个已损坏的OSD来减少故障影响否则正常淘汰流程应该严格按下面顺序来第一步让OSD退出。所谓“退出”就是让CRUSH算法不再把新的PG分配给这个OSD同时触发该OSD上已有PG向其他OSD迁移。ceph osd out osd_id执行之后你会看到这个OSD的状态从in变成out。数据迁移马上开始这个OSD上的活动PG会逐渐重映射到其他OSD上。这一步本身无风险因为它不涉及删除任何东西随时可以用ceph osd in osd_id恢复。第二步等待所有PG恢复为clean。这一步可能是整个流程里最耗时也最容易让人焦虑的部分。你需要持续观察ceph pg stat ceph pg dump | grep -c activeclean当目标OSD上的PG数减少到0也就是ceph pg ls-by-osd osd_id输出为空时数据已经全部迁出。此时就算物理拔盘也不会丢数据。有些版本下你还可能看到PG处于activebackfill状态这表示还在写数据继续等。如果等待过程太长想加速可以临时调高osd_max_backfills和osd_recovery_max_active两个参数并在回填完成后调回原值。注意这个操作会占用集群IO业务高峰期慎用。第三步永久剔除OSD。确认PG迁移完成后执行ceph osd purge osd_id --yes-i-really-mean-it这条命令会把OSD从OSD map、CRUSH map中彻底移除并把这个OSD上的认证key也删掉。如果集群里该OSD其实还在运行purge前最好先执行ceph osd down osd_id再把对应进程停掉否则OSD进程会反复尝试连MON并重新注册导致状态异常。如果你用的不是太老的版本也可以分步执行ceph osd down osd_id ceph osd crush remove osd_name ceph osd rm osd_id效果类似但不如purge一步到位。我个人推荐直接用purge除非你想对CRUSH权重做特殊处理比如某个OSD只是临时调整并不想删除实体。第四步清理物理资源。OSD从集群移除后磁盘可能还保留着LVM卷和BLUESTORE元数据。如果这块盘还要继续用执行ceph-volume lvm zap /dev/sdb如果这块盘要被物理拔掉直接拔也没问题但最好先把LV清理干净避免后续别人插上这块盘时误以为它是系统盘。3.3 物理更换与后续清理如果是故障盘替换流程上还多一个步骤确认故障盘对应的槽位记录盘序列号拔盘后插新盘然后按照第二节新增OSD的流程重新初始化。这里重点提醒新盘的序列号可能跟旧盘不一样但OSD ID会重新分配一个不会沿用旧的。你要是还在监控脚本里写死了“这个槽位对应OSD.12”那替换后就要同步更新脚本。曾经遇到过这样的情况某台机器上原OSD.12挂了我们把系统盘身份信息清除后插了新盘用ceph-volume lvm create初始化结果发现新OSD起不来。排查到最后是因为新盘上遗留着老LVM设备ceph-volume默认拒绝覆盖已有VG。解决办法其实很简单就是先ceph-volume lvm zap /dev/sdb --destroy彻底清掉所有VG/LV信息再创建。记住这条能帮你省掉半小时。4. CephFS场景下的注意事项4.1 容量阈值和监控指标CephFS对集群容量的敏感度可能比RBD卷还高。因为RBD卷的使用率是由客户端文件系统控制的Ceph自身只关心底层pool的空间有没有被撑满。而CephFS是一个共享文件系统客户端随时可能写文件如果容量接近上限没有任何优雅的降级方式——满池直接导致元数据写入失败、文件系统只读。所以你在增删OSD时一定要清楚CephFS两大核心池的容量分布。建议把ceph df detail的输出纳入常规监控重点关注cephfs_data池的UTIL值以及cephfs_metadata池的USED值变化。增加OSD后文件系统容量理论上会随之上涨但要注意新建的OSD会按CRUSH规则均衡地分散到集群里所有pool中并不保证“我的文件系统容量立刻翻倍”。如果你希望新增的OSD真正为cephfs_data池所用最好把池对应的CRUSH rule只关联到新加入的那组OSD上。删除OSD则相反目标OSD里可能既有文件系统数据也有块存储数据。为了不让文件系统空间在迁移中触顶删之前最好用ceph osd pool autoscale-status查一下各pool的容量如果cephfs_data的使用率本来就很高那迁移时要特别小心。我通常的做法是在迁移期间把文件系统池的full_ratio再稍微放宽一点例如调到0.95防止因为空间紧张导致Ceph进入full状态后云里雾里。4.2 文件系统与PG数的影响CephFS的PG数由pool的pgp_num决定而PG数量又受OSD数量影响。缩容后如果OSD数量大幅减少但pool的PG数没有调整就会出现PG分布不均少数OSD上可能压着几十个PG其他OSD却只有几个。这种不均衡会直接影响文件系统的吞吐。举个例子原来集群有60个OSDcephfs_data池设置了512个PG每个OSD平均约8.5个PG还算均衡。如果一次性下线了20个OSD剩下40个OSD平均每个要扛12.8个PG压力上升50%而且因为CRUSH算法重新分布很多PG会rebalance短期内性能波动很大。所以在删除OSD之前我建议先评估最终保留的OSD数量必要时提前调整cephfs_data和cephfs_metadata池的pg_num和pgp_num。但这又是一个大坑——pg_num只增不减要减的话得重新创建pool这可以说是灾难级操作。所以真实生产里更好的策略是分批次删OSD一批删两到三个等集群完全clean再继续下一批。千万不要一次性把20个OSD全部out那会让剩余OSD的PG数量瞬间暴涨甚至因为回填风暴拖垮整个集群。4.3 删除OSD时对客户端IO的影响CephFS客户端对延迟比较敏感尤其是小文件读写场景。删除OSD时数据回填占用磁盘和网络IO必然会对客户端的IO造成一定干扰。很多运维在ceph osd out之后就把注意力放在PG状态上忽略了客户端的实际感受。如果业务侧反馈卡顿你得马上意识到可能是回填风暴。控制回填风暴有三板斧。第一板斧限制回填速度设置osd_max_backfills为1或2让集群“优雅地”迁移数据。第二板斧调整osd_recovery_delay_start让OSD启动后延迟一段时间再开始回填给客户端一段平稳窗口。第三板斧利用osd_recovery_op_priority降低恢复操作优先级让正常IO优先回填任务靠后。这三个参数可以动态调整实测对CephFS整体可用性帮助很大。另外一个很隐蔽的问题CephFS挂载客户端在OSD删除进程中有可能碰到MDS的元数据请求超时。表现为客户端目录ls卡住或者某个文件stat无响应。这通常不是MDS故障而是底层数据迁移太猛导致对应元数据所在的OSD被挤占资源。此时优先降回填速度等缓解后再继续观察。5. 常见问题排查与避坑记录5.1 问题速查表我把这些年做OSD增删时遇到的高频问题整理成了表格你在实际操作中如果踩到类似的直接对照着处理现象可能原因处理方式ceph osd out后PG长时间不迁移集群本来就不健康或者有PG处于down状态ceph pg dump_stuck查找异常PG先修复基础故障再继续删除OSD后还有activeremapped的PG有其他OSD同时down导致副本数不够先恢复其他down掉的OSD或检查min_size副本配置新加入的OSD状态为down磁盘或文件系统遭到破坏或Ceph服务未启动systemctl status ceph-osdid查看日志多半需要ceph-volume lvm zap后重建扩容后CephFS写速下降回填任务占用了集群IO调低osd_max_backfills和回填优先级ceph osd purge报权限错误输入的认证key没有管理员权限使用client.admin的keyring或检查capspool空间不够迁移无法完成Ceph进入full状态禁止写入立即临时加OSD或用ceph osd set noout暂时防止数据迁移把空间释放出来拔掉旧盘后Ceph的device monitor一直在报警物理移除后未清理OSD记录执行ceph device rm手动清理设备记录或等待ceph-device自动管理端润滑删除OSD期间CephFS目录操作卡顿回填导致元数据池的OSD负载过高调低回填速度必要时重启MDS低峰期看到表格里的“重启MDS”我得多说一句别轻易重启MDS除非你确认元数据池所在OSD一切正常并且重启窗口不影响业务。MDS故障切换本身没问题但会产生短暂的元数据downtime对于很多应用来说这就够“卡”了。5.2 我的几个独家心得第一个心得增删OSD的最佳时机永远是业务低峰期。我知道很多运维会想“反正数据迁移是自动的白天晚上没区别”但实际体验告诉你区别非常大。白天突然的写入高峰会叠加回填峰值集群的IO曲线会出现双峰互相放大最终谁都跑不动。我在夜班窗口做这种操作一次也没有翻过车。第二个心得给新OSD做预写入测试。别直接拿一块新盘就进生产环境先用FIO或者vdbench压一下盘的最大顺序写和随机读能力选掉那些体质差的盘。这个步骤可能让你多花两个小时但能避免几个月后因为坏盘再次触碰到OSD增删这个麻烦流程。第三个心得记得在变更后刷新监控基线。很多团队的监控系统还在用半个月前的容量数据你增删完OSD如果不更新Prometheus或者Zabbix的指标基线报警阈值可能一直对不上。特别是CephFS的使用率删除完后可能从80%降到60%但报警还挂在80%上到时候误报了你都不知道问题在哪。第四个心得也是我认为最有价值的做好OSD变更的“回滚演练”。我知道直接把OSD in回去比out更简单但purge之后是没有后悔药的。所以我在大批量删除OSD前一定先拿去某台测试环境完整跑一遍out、等待、purge、zap确认操作脚本没有任何意外才在正式集群执行。这套演练的成本不高但给了你足够的安全感。6. 结尾还是想说点实在的CephFS下的OSD增删说到底考验的不是你会不会几条命令而是对数据分布、集群容量、IO折损的综合理解。加盘时要会控制回填节奏删盘时要等数据完全迁出每一步都要监控PG状态和客户端体验。我这些年在生产环境里进进出出几十个OSD最深的体会就是慢就是快多等一会儿PG变clean比在出问题时抢救强一百倍。如果你正准备在自己的环境做一次OSD变更建议先对照这篇的步骤列一个checklist尤其是如果计划一次性删一批盘宁可分几次操作也别挑战CRUSH的极限。最后提醒一句执行ceph osd purge时那句--yes-i-really-mean-it不是开玩笑按下去之前再确认一次盘符和OSD ID这是我踩过无数次坑后最值钱的教训。