PG（放置组）笔记

杂项复制粘贴自电子邮件，清理后应移出 /dev。

概述

PG = “placement group”（放置组）。在集群中放置数据时，对象被映射到 PG，而 PG 被映射到 OSD。我们使用这种间接方式来对对象进行分组，这减少了我们需要跟踪的每个对象的元数据量以及需要运行的进程（以每个对象为基础跟踪放置历史记录将极其昂贵）。增加 PG 数量可以减少集群中每个 OSD 负载的方差，但每个 PG 会在存储它的 OSD 上占用更多 CPU 和内存。我们通常估算为 100 个 PG/OSD，尽管根据集群情况，这个数字可以有很大变化而不会产生不良影响。你遇到了一个关于我们如何根据集群描述计算初始 PG 数量的错误。

PG 有几种不同的类别；（在原始发件人的 ceph -s 输出中）存在的 6 个是“本地”PG，它们与特定的 OSD 绑定。然而，这些在标准的 Ceph 配置中并未实际使用。

映射算法（简化版）

> 对象->PG 的映射看起来是怎样的，你是否将多个对象映射到
> 一个 PG 上，或者有时将一个对象映射到多个 PG 上？PG 到 OSD 的
> 映射又如何？一个 PG 是否恰好属于一个 OSD？
>
> 一个 PG 是否代表固定的存储空间量？

许多对象映射到一个 PG。

每个对象恰好映射到一个 PG。

一个 PG 映射到一个 OSD 列表，其中列表中的第一个是主 OSD，其余是副本。

许多 PG 可以映射到一个 OSD。

PG 仅仅代表对象的集合；你配置你想要的 PG 数量，osd 数量 * 100 是一个很好的起点，你所有存储的对象都被伪随机地均匀分布到 PG 中。因此，PG 明确地不代表固定的存储量；它代表了你 OSD 上总存储量的 1/pg_num’th。

忽略 CRUSH 和自定义放置的细节，它在伪代码中大致如下：

locator = object_name
obj_hash = hash(locator)
pg = obj_hash % num_pg
OSDs_for_pg = crush(pg)  # returns a list of OSDs
primary = osds_for_pg[0]
replicas = osds_for_pg[1:]

如果你想理解上面 crush() 部分，想象一个处于真空中的完美球形数据中心；）也就是说，如果所有 OSD 的权重都是 1.0，并且数据中心没有拓扑结构（所有 OSD 都在顶层），并且你使用默认设置等等，它就会简化为一致性哈希；你可以将其视为：

def crush(pg):
   all_osds = ['osd.0', 'osd.1', 'osd.2', ...]
   result = []
   # size is the number of copies; primary+replicas
   while len(result) < size:
       r = hash(pg)
       chosen = all_osds[ r % len(all_osds) ]
       if chosen in result:
           # OSD can be picked only once
           continue
       result.append(chosen)
   return result

用户可见的 PG 状态

待办事项

状态图及其如何重叠

creating: PG 仍在创建中
active: 对 PG 的请求将被处理
clean: PG 中的所有对象都已按正确的次数复制
down: 具有必要数据的副本已宕机，因此 PG 处于离线状态
recovery_unfound: 恢复未能完成，因为对象未找到。
backfill_unfound: 回填未能完成，因为对象未找到。
premerge: 由于即将进行的 PG 合并，PG 处于静止 IO 状态。这发生在 pg_num_pending < pg_num 时，并且适用于 pg_num_pending <= ps < pg_num 的 PG 以及它正在合并的相应对等 PG。
scrubbing: 正在检查 PG 是否存在不一致
degraded: PG 中的某些对象尚未被充分复制
inconsistent: PG 的副本不一致（例如，对象大小错误，在恢复完成后某个副本中缺少对象等）
peering: PG 正在经历对等（Peering）过程
repair: 正在检查 PG，发现的任何不一致（如果可能）将被修复
recovering: 对象正在迁移/与副本同步
backfill_wait: PG 正在排队等待开始回填
incomplete: PG 缺少其日志中某个必要时期的历史记录。如果您看到此状态，请报告错误，并尝试启动任何可能包含所需信息的已失败 OSD。
stale: PG 处于未知状态 - 自 PG 映射更改以来，监控器尚未收到其更新。
remapped: PG 暂时映射到与 CRUSH 指定的 OSD 不同的 OSD 集
deep: 与 scrubbing 结合使用时，表示擦洗是深度擦洗
backfilling: 恢复的一种特殊情况，其中 PG 的全部内容被扫描和同步，而不是根据 PG 日志中的最近操作推断需要传输的内容
backfill_toofull: 回填预留被拒绝，OSD 空间不足
recovery_wait: PG 正在等待本地/远程恢复预留
undersized: PG 无法根据其大小选择足够多的 OSD
activating: PG 已对等但尚未激活
peered: PG 已对等但无法变为激活状态
snaptrim: PG 正在修剪快照
snaptrim_wait: PG 正在排队等待修剪快照
recovery_toofull: 恢复预留被拒绝，OSD 空间不足
snaptrim_error: 由于错误，PG 无法完成快照修剪
forced_recovery: PG 已被标记为最高优先级恢复
forced_backfill: PG 已被标记为最高优先级回填
failed_repair: 修复 PG 的尝试失败。需要手动干预。

OMAP 统计数据

Omap 统计数据在深度擦洗期间收集，并显示在以下命令的输出中

ceph pg dump
ceph pg dump all
ceph pg dump summary
ceph pg dump pgs
ceph pg dump pools
ceph pg ls

由于这些统计数据不是持续更新的，在深度擦洗不频繁和/或 omap 活动频繁的环境中，它们可能相当不准确。因此，不应依赖它们来获取精确的准确性，而应将其用作指导。运行深度擦洗并立即检查这些统计数据应该能很好地指示当前的 omap 使用情况。

由 Ceph 基金会为您呈现

Ceph 文档是由非营利性 Ceph 基金会资助和托管的社区资源。如果您希望支持这项工作和我们的其他努力，请考虑立即加入。