ceph osd pg upmap

文章讲述了在Ceph集群维护中,如何处理pg分布不均、osd容量不均衡和高危pg的情况,介绍了pgupset调整方法以及实际应用场景,如pgbackfill_toofull和osd使用率不平衡的解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

概述

在我们巡检ceph集群、处理故障或者进行迁移等操作时,pg往往是最需要关注项之一。一方面pg的健康状态会直接影响集群能否正常提供业务,另一方面,pg的分布会影响集群osd的容量与负载均衡。ceph根据crush rule,采用分布式哈希算法,也就是以计算代替查表的方式进行数据分布。由于伪随机性和众多因素(pgnum合理性,硬件规格统一性,后期结构调整,ceph),很多时候pg的分布往往达不到我们想要的效果,此时便需要我们手动进行pg的调整。

常见场景

以下是几种可能需要手动处理的常见场景

  1. 集群osd 容量不均衡,相差较大,需手动均衡
  2. pg卡在backfill_toofull无法自动消除
  3. 多个高危osd存在交叉pg时,手动调整避免风险

PG set

在查看pg dump时,可以看到每个pg都有两个分布信息,分别为up set与acting set。acting set可以理解为pg当前在哪些osd上有数据,up set可以理解为pg最终需要分布在哪些osd上。当acting set值域up set值一致时,且每个osd上的pg数据都正确时,pg状态才会进入active+clean状态。而pg的backfill过程也是从acting set的osd向up set中的osd恢复。

PG_STAT  UP           ACTING 
3.111    [0,1,3]      [0,1,2]

以这个pg为例,当前pg数据在osd[0,1,2]上,最终目标osd组合为[0,1,3],可以简单地理解为该pg数据从osd.2上迁移到osd.3上,对应的结果就是在ceph osd df中预期可以看到osd.2的容量下降,osd.3的容量上升。

调整pg up set

有如下两种方式调整pg up set,命令与参数如下

ceph osd pg-upmap pg.id  [<osd.id> <osd.id> <osd.id>] #参数为pgid和目标的up set组合
ceph osd pg-upmap-items pg.id  oldosd.id newosd.id [<oldosd.id> <newosd.id>] #参数为pgid,和成对出现的osdid

假设当前存在一个集群,其tree如下

ID   CLASS  WEIGHT      TYPE NAME            STATUS  REWEIGHT  PRI-AFF
 -1         6          root default                                                                
              2          host node0                            
       hdd     1             osd.0       up   1.00000  1.00000
       hdd     1             osd.1       up   1.00000  1.00000
              2          host node1                            
       hdd     1             osd.2       up   1.00000  1.00000
       hdd     1             osd.3       up   1.00000  1.00000
              2          host node2                            
       hdd     1             osd.4       up   1.00000  1.00000
       hdd     1             osd.5       up   1.00000  1.00000

当前存在一个clean的pg 3.11b,其up set与acting set都是[0,2,4],而当前osd.2和osd.4使用率过高,osd.3和osd.5使用率较低。以下两条命令都可以实现osd的容量均衡调整

root@mon0:~# ceph osd pg-upmap 3.11b 0 3 5
set 3.11b pg_upmap mapping to [0,3,5]

通过执行返回可以看出,该命令直接将pg的目标up set设置为目标osd组合。
也可以通过如下命令

ceph osd pg-upmap 3.11b 2 3 4 5
set 3.11b pg_upmap_items mapping to [2->3] [4->5] 

相对而言,更推荐第二种方式

  • 比较直观看出pg迁移动向
  • 如果参数输错,或给出的osdid不合理(osdid未成对出现,或者不符合容灾规则),则不会执行

实际场景

以下为几种常用场景

pg backfill_toofull

假设pg处于backfill_toofull状态,一般是up set中的osd存在部分超过osd_backfillfull_ratio阈值的osd,如果该osd本身利用率就很高,还要大量pg 需要向上迁移,这种场景,单单调整osd_backfillfull_ratio只能拖延,过段时间该osd仍会超出阈值,无法从根本上解决问题,如果该osd所在host上存在使用率较低的osd,则可以通过up-upmap-items 进行迁移。

osd使用率不均衡

ceph osd df默认顺序与ceph osd tree一致,假设每个host下一共10个osd,假设host下第一个osd为0,则可以通过如下命令对该host下osd进行排序

ceph osd df |grep -A 9 ^"  0"|sort -k17 -n#排序列各版本不同,需自行确认,“  0”需根据集群osd编号长度确定

高危PG

假如三副本集群中已有一块硬盘损坏,而监测发现,另一块硬盘已经开始计数错误告警,如果直接更换该硬盘,则会导致部分pg单副本,根据pg dump,找出降级的pg,使用upmap提前迁移至其他安全硬盘,避免单副本数据。

<think>嗯,用户问的是关于Ceph OSD reweight手动进行数据平衡,有没有官方推荐的操作。首先,我需要回想一下Ceph的文档和相关的最佳实践。 首先,OSD reweight是用来调整数据分布的工具,当某些OSD上的数据过多时,可以通过调整权重来让CRUSH算法重新分布数据。不过,手动调整可能会有风险,比如数据迁移过程中影响集群性能或者导致不稳定性。 接下来,用户可能想知道官方推荐的具体步骤。记得Ceph官方建议谨慎使用手动reweight,优先考虑自动平衡选项,比如使用`balancer`模式。但有时候手动调整也是必要的,比如在替换OSD或者临时解决不均衡问题时。 需要提到`ceph osd reweight`命令的正确用法,以及可能的替代命令如`ceph osd crush reweight`的区别。同时,应该强调在操作前检查集群状态,确保健康,备份CRUSH map,还有逐步调整而非一次性大幅改动的重要性。 另外,用户可能关心操作后的监控,比如使用`ceph -w`或`ceph osd df`来观察数据迁移情况和集群状态的变化。还要提醒他们注意IO性能影响,最好在业务低峰期操作。 可能还需要提到`noout`标志的设置,防止OSD被标记为out,导致意外数据迁移。以及使用`ceph osd test-reweight`来模拟调整后的影响,避免直接操作带来的风险。 最后,确保用户明白这些步骤是基于官方文档的建议,但具体情况可能需要根据集群的实际情况调整,建议参考最新文档或社区支持。</think>Ceph 官方在手动调整 OSD 的 `reweight` 值时,确实提供了一些推荐的操作方法和注意事项,目的是在数据平衡过程中最小化对集群性能的影响,并确保操作的安全性。以下是基于官方文档和最佳实践的推荐步骤: --- ### **1. 优先使用自动平衡器(Balancer)** **官方推荐优先使用内置的 `balancer` 工具**(较新版本默认启用),它能自动优化数据分布,避免手动干预的风险: ```bash # 启用并配置 balancer ceph balancer on ceph balancer mode <upmap/crush-compat> # 选择模式(通常用 crush-compat) ceph balancer optimize <plan-name> # 生成优化计划 ceph balancer execute <plan-name> # 执行计划 ``` 自动平衡器通过小步调整逐步优化,比手动 `reweight` 更安全。 --- ### **2. 手动 `reweight` 的适用场景** 仅当自动平衡器无法解决严重不均衡(如硬件故障、快速扩容后)时,才考虑手动调整 `osd reweight`。典型场景: - 某个 OSD 使用率远高于集群平均(如超过 15%)。 - 需要临时降低某 OSD 的写入压力。 --- ### **3. 手动 `reweight` 操作步骤** #### **(1) 检查当前 OSD 使用率** ```bash ceph osd df # 查看 OSD 使用率排序 ceph osd df tree ``` #### **(2) 逐步调整权重** **避免一次性大幅调整**(如从 1.0 直接降到 0.5),建议每次调整不超过 0.1-0.2,允许集群逐步迁移数据: ```bash ceph osd reweight <osd.id> <new_weight> # new_weight 范围 0.0~1.0 ``` 例如: ```bash ceph osd reweight osd.12 0.8 # 将 osd.12 的权重降至 0.8 ``` #### **(3) 监控数据迁移状态** ```bash ceph -w # 实时观察 PG 状态和迁移进度 ceph osd df # 检查 OSD 使用率变化 ceph health detail # 确保集群保持 HEALTH_OK/WARN ``` #### **(4) 调整间隔与稳定性** - 每次调整后等待集群稳定(迁移完成)再继续下一步操作。 - 迁移速度可通过 `osd_max_backfills` 和 `osd_recovery_max_active` 参数限制,避免影响业务 IO。 --- ### **4. 替代命令:`crush reweight`** 如果需要永久调整 OSD 在 CRUSH 算法中的权重(影响新写入数据分布),使用: ```bash ceph osd crush reweight <osd.id> <new_weight> ``` 此命令修改 CRUSH Map 中的权重,需谨慎操作。 --- ### **5. 关键注意事项** 1. **避免 `reweight 0.0`** 直接将权重设为 0 会导致所有 PG 立即迁移,可能引发性能抖动。建议逐步降低权重或先标记 OSD `out`: ```bash ceph osd out osd.<id> # 安全移除 OSD,触发自动迁移 ``` 2. **预防 `noout` 干扰** 若集群设置了 `noout` 标志(防止 OSD 被标记为 down),需先解除: ```bash ceph osd unset noout ``` 3. **备份 CRUSH Map** 修改前备份 CRUSH Map,防止误操作: ```bash ceph osd getcrushmap -o backup.crush ``` 4. **业务低峰期操作** 数据迁移会占用网络和磁盘资源,建议在低负载时段执行。 --- ### **6. 官方参考** - [Ceph 文档 - 手动调整 OSD 权重](https://docs.ceph.com/en/latest/rados/operations/operating/#changing-an-osd-s-crush-weight) - [Ceph 平衡器文档](https://docs.ceph.com/en/latest/rados/operations/balancer/) 建议始终优先使用自动化工具,手动操作仅作为最后手段,并严格遵循小步调整、实时监控的原则。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值