Ceph _backfill and recovery 之间的不同以及 peering理解

Ceph中的数据同步通过recovery和backfill进行,两者在OSD之间同步PG数据。recovery用于OSD启动时,当pglog中的更新少于设定值时。backfill则在其他情况下使用。peering是OSD比较状态的过程,会阻止数据访问。异步恢复的引入旨在减少recovery对IO的影响。可以通过调整参数强制backfill并使用nobackfill/norecover标志避免同步操作。

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

在 Ceph 中,有两种方法可以在集群内的 OSD 之间同步数据,recovery和backfill。虽然这两种方法都实现了相同的最终目标,但在这两个过程中存在细微差别,如下所述。

什么时候使用 Recovery 而不是 Backfill?

  • Ceph OSD 进程为每个归置组 (PG) 维护一个名为 的日志pglog,其中包含该 PG 中最近 3,000 到 10,000 次更改的详细信息。
  • 与 Ceph 中的大多数东西一样,日志条目的数量可以使用osd_min_pg_log_entries和osd_max_pg_log_entries参数进行调整。
    • entry 是 PG不存在时要保留的max条目数。 active+clean
    • entry 是 PG时要保留的min条目数。 active+clean
  • 如果:
    OSD 已关闭但现在已启动
    pglog并且该 OSD 上的给定 PG 发生的可用更新少于
  • 然后:
    recovery用于那个PG。
  • 除非:
    backfill用于那个PG。

有什么区别?
在这里插入图片描述
为什么访问在期间被阻止recovery,而不是在期间backfill

我可以强制backfill而不是recovery这样我永远不会阻止客户端 IO 吗?
是的!
为此,您只需调整上面min提到的和maxlog 值。

#the number of entries to keep in the pg log when trimming it. Defaults to 3000.
osd_min_pg_log_entries = 1
# the max entries, say when degraded, before we trim. Defaults to 10000.
osd_max_pg_log_entries = 2

重要的!我们强烈建议在生产中实施之前在测试环境中测试这些选项,以便您了解它们在生产中的行为方式。

什么是peering?

  • peering是 OSD 比较 PG 状态以确定 PG 的正确当前状态的过程。
  • peering还记录了哪些 OSD 具有 PG 中各种对象的最新数据和元数据。
  • peering当一个 OSD 启动(一个新的 OSD,或者之前关闭的 OSD)或关闭时发生。
  • 整个 PG 的数据访问peering在进行 时被阻止
  • 这可以防止客户端 IO 请求的更改使peering进程无效。
  • peering完成后,PG 将进入或backfill_wait状态recovery_wait。
  • PG 应该从waitstate 移动到backfillingor recoveringas slots for these operations become available on the target OSD.

注意:状态一致并不代表它们都是最新的内容。这是什么backfill和recovery成就。
在某些情况下,我们已经看到对等互连需要相当多的时间。
设置recovery_deletes标志可以peering缩短时间。

这些过程能否导致slow request日志条目

  • 如果您ceph.log在 Ceph MON 节点上监控或查看,您可能会看到slow request条目。
  • “慢速请求”行的末尾将指示哪种类型的操作是该请求的阻碍。
    • Typewaiting on peering表示当 PG 正在对等时 IO 被阻塞。
    • Typewaiting on degraded objects表示 IO 被阻塞到那些正在等待或处于活动状态的对象recovery。

可以预防backfill或recovery避免发生吗?

可以,
为此,我们有nobackfill和norecover标志。

ceph osd set nobackfill
ceph osd set norecover

当你的进化完成并且你想重新启用backfillandrecovery时,你可以unset使用标志。

ceph osd unset nobackfill
ceph osd unset norecover

norebalance flag呢?

  • 这个标志比nobackfillor更具选择性norecover。
  • 具体来说,只要 PG 是 only ,这个标志就会阻止数据移动remapped,但不是degraded

remappeddegraded有什么区别?

  • remappedPG 状态表示 PG 在非最佳位置至少有 1 个数据副本。
  • degradedPG 状态表示 PG 至少丢失了 1 个数据副本。

请珍惜劳动成果,支持原创,欢迎点赞或者关注收藏,你每一次的点赞和收藏都是作者的动力,内容如有问题请私信随时联系作者,谢谢!

<think>好的,用户现在问的是“ceph_pg_total - ceph_pg_active > 0”,需要解释这个指标的含义以及如何处理。首先,我需要回忆一下Ceph中的PG相关知识。PG是Placement Group,用于分布数据的重要概念。用户提到的这个指标是总PG数减去活跃PG数,如果差值大于0,说明有部分PG不处于活跃状态。 接下来,我得先解释这个指标的基本含义。用户可能是运维人员或者开发人员,遇到了集群健康问题,需要诊断为什么有些PG不活跃。需要明确PG的状态,比如active、peeringrecoverying等等。当PG不活跃时,可能影响数据的读写,所以用户需要知道如何处理。 然后,要分析可能的原因。可能的原因包括OSD故障、网络问题、数据不一致需要恢复,或者是新创建的PG还没完全激活。需要逐个解释这些原因,并给出对应的排查步骤。例如,检查OSD状态,查看集群日志,确认网络连通性等等。 用户可能已经检查过ceph health,或者通过监控系统发现了这个指标异常,需要进一步的指导。所以需要给出具体的命令,比如ceph pg stat,ceph pg dump_stuck,以及如何查看特定PG的详细信息。 解决方案部分,需要针对不同原因给出不同的处理方法。如果是OSD下线,可能需要重启服务或更换硬件;如果是数据恢复,需要等待或调整恢复参数;如果是网络问题,需要检查配置和连通性。 还需要考虑预防措施,比如监控配置、定期维护、硬件冗余等。用户可能不仅想解决当前问题,还想避免未来再次发生。 需要确保回答清晰,步骤明确,命令正确,并且用中文口语化表达,避免术语过于晦涩。同时,用户可能希望得到直接的解决方案,所以结构要分明,分点列出原因、排查步骤和解决方法,便于用户快速执行。 最后,提醒用户如果问题依然存在,需要提供更多日志或输出来进一步诊断。这有助于用户在遇到复杂问题时,知道如何收集必要的信息寻求帮助。</think>你提到的 **`ceph_pg_total - ceph_pg_active > 0`** 是 Ceph 存储集群中的一个重要监控指标,表示当前集群中存在 **非活跃状态的 PG(Placement Group,放置组)**。以下是详细解释及应对方法: --- ### **1. 术语解释** - **PG(Placement Group)**: Ceph 将数据划分为多个 PG,每个 PG 是数据分布的最小逻辑单元,负责将数据映射到具体的 OSD(Object Storage Daemon)。 - **`ceph_pg_total`**:集群中所有 PG 的总数。 - **`ceph_pg_active`**:处于 **`active`** 状态的 PG 数量(即正常提供读写服务的 PG)。 - **指标含义**: `ceph_pg_total - ceph_pg_active > 0` 表示有部分 PG 处于非活跃状态(如 `peering`、`recovering`、`incomplete` 等),可能导致数据暂时不可访问或性能下降。 --- ### **2. 常见原因** #### **(1) OSD 故障或下线** - 某个 OSD 宕机或网络中断,导致 PG 的副本数不足。 - 触发 PG 进入 `peering` 状态(正在协商副本一致性)。 #### **(2) 数据恢复或回填** - 新增/移除 OSD 或调整 CRUSH Map 后,PG 正在执行数据迁移(`backfilling`、`recovering`)。 - 此时 PG 处于临时非活跃状态。 #### **(3) PG 状态异常** - PG 因数据不一致进入 `incomplete` 状态(无法选举出权威副本)。 - 集群配置错误(如 `pg_num` 设置不合理)。 #### **(4) 资源不足** - OSD 负载过高(CPU、磁盘 IO 或网络带宽耗尽),导致 PG 无法及时激活。 --- ### **3. 排查步骤** #### **(1) 查看集群健康状态** ```bash ceph health detail # 检查具体告警信息 ceph pg stat # 查看 PG 统计(active、peering、recovering 数量) ceph pg dump_stuck # 列出“卡住”的 PG(如 inactive 超过阈值) ``` #### **(2) 检查 PG 详细状态** ```bash # 查看所有 PG 的状态分布 ceph pg stat # 检查具体 PG 的状态(替换 <pg-id>) ceph pg <pg-id> query # 显示 PG 的详细状态、OSD 映射和事件历史 ``` #### **(3) 关联 OSD 状态** ```bash ceph osd tree # 检查 OSD 是否在线(`up`)和容量 ceph osd perf # 查看 OSD 的延迟和负载 ``` #### **(4) 检查日志** ```bash # 查看 Ceph 集群日志(通常位于 /var/log/ceph/) tail -f /var/log/ceph/ceph.log | grep -i pg_stat ``` --- ### **4. 解决方案** #### **(1) 处理 OSD 故障** - 重启故障 OSD: ```bash systemctl restart ceph-osd@<osd-id> ``` - 若 OSD 无法恢复,替换硬件后重新加入集群。 #### **(2) 等待数据恢复完成** - 如果是临时迁移或恢复操作,监控进度: ```bash ceph -w # 实时观察 PG 恢复状态 ceph pg dump | grep recovering ``` - 调整恢复速度(若需加快): ```bash ceph tell osd.* injectargs '--osd-max-backfills=4' # 增加并发恢复数 ``` #### **(3) 修复异常 PG** - 若 PG 卡在 `incomplete` 或 `stale` 状态,尝试修复: ```bash ceph pg repair <pg-id> # 触发 PG 修复(谨慎操作!) ``` - 若修复无效,可能需要手动干预(如重置 PG),建议联系社区或专业支持。 #### **(4) 优化 PG 分布** - 调整 PG 数量(需谨慎,避免数据震荡): ```bash ceph osd pool set <pool-name> pg_num <new-pg-num> ``` - 确保 `pg_num` 和 `pgp_num` 设置合理(参考 [Ceph PG 计算器](https://ceph.io/pgcalc/))。 --- ### **5. 预防措施** - **监控告警**:配置 PG 状态监控(如 `active+clean` 比例)。 - **容量规划**:避免 OSD 过载,预留足够的 PG 数量。 - **定期维护**:升级 Ceph 版本、检查硬件状态、优化 CRUSH Map。 --- 如果需要进一步分析,请提供以下信息: - `ceph pg stat` 的输出 - `ceph health detail` 的告警详情 - 相关 PG 的查询结果(`ceph pg <pg-id> query`)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小Eason哥

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值