PG（放置组）笔记

来自电子邮件的杂项复制粘贴，当这些内容被清理时，应该从/dev目录中移除。

概述

PG = “placement group”。当在集群中放置数据时，对象被映射到PG中，然后这些PG被映射到OSD上。我们使用这种间接映射，以便我们可以将对象分组，这减少了我们需要跟踪的每个对象的元数据数量以及需要运行的进程（以每个对象为单位跟踪放置历史将会非常昂贵）。增加PG的数量可以减少集群中每个OSD负载的差异，但每个PG都需要在存储它的OSD上消耗更多的CPU和内存。我们尝试将其估算为每个OSD 100个PG，尽管根据您的集群，它可以有很大的差异而没有不良影响。您遇到了我们根据集群描述计算初始PG编号的bug。

有几种不同类型的PG；原始电子邮件发送者输出中存在的6个是“本地”PG，它们与特定的OSD相关联。然而，这些实际上在标准的Ceph配置中并不使用。ceph -s output) are “local” PGs which are tied to a specific OSD. However, those aren’t actually used in a standard Ceph configuration.

映射算法（简化版）

> 对象到PG的映射看起来怎么样，您在一个PG上映射多个对象，还是有时将一个对象映射到多个PG？PG到OSD的映射呢，一个PG是否正好属于一个OSD？
> one PG, or do you sometimes map an object to more than one PG? How about the
> 一个PG代表固定数量的存储空间吗？
>
> 一个PG是否代表固定数量的存储空间？

许多对象映射到一个PG。

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

一个PG映射到一个单独的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状态

Todo

状态图以及它们如何重叠

创建中: PG仍在创建中
active: 对PG的请求将被处理
clean: PG中的所有对象都正确地复制了次数
down: 具有必要数据的副本已下线，因此pg离线
恢复未找到: 恢复未能完成，因为对象未找到。
填充未找到: 回填未能完成，因为对象未找到。
预合并: 由于即将进行PG合并，PG处于静默IO状态。当pg_num_pending < pg_num时会发生这种情况，并且适用于pg_num_pending <= ps < pg_num以及与之合并的相应对等PG。
扫描中: PG正在检查不一致性
degraded: PG中的一些对象尚未复制足够的次数
inconsistent: PG的副本不一致（例如，对象大小不正确，对象从某个副本中丢失后恢复完成等）
对等: PG正在经历对等process
repair: PG正在检查，任何发现的不一致性都将被修复（如果可能）
恢复中: 对象正在迁移/同步副本
填充等待: PG正在排队以开始回填
incomplete: 一个pg缺少其日志中必要的某些历史记录。如果您看到这个状态，请报告一个bug，并尝试启动可能包含所需信息的任何失败的OSD。
stale: PG处于未知状态——监视器自PG映射更改以来尚未收到其更新。
重新映射: PG暂时映射到与CRUSH指定的不同OSD集。
deep: 与扫描中刷洗是深度刷洗
填充中: 恢复的一种特殊情况，其中扫描并同步PG的全部内容，而不是从最近操作的PG日志中推断需要传输的内容
backfill_toofull: 回填保留被拒绝，OSD太满
恢复等待: PG正在等待本地/远程恢复保留
undersized: PG根据其大小无法选择足够的OSD
激活中: PG已经对等，但尚未激活
已对等: PG已经对等，但无法激活
快照修剪: PG正在修剪快照
快照修剪等待: PG正在排队修剪快照
recovery_toofull: 恢复保留被拒绝，OSD太满
快照修剪错误: 由于错误，PG未能完成快照修剪
强制恢复: PG已被标记为最高优先级恢复
强制填充: PG已被标记为最高优先级回填
失败的修复: 修复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 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.