注意
本文档适用于 Ceph 的开发版本。
监控 OSD 和 PG
高可用性和高可靠性要求采用容错方法来管理硬件和软件问题。Ceph 没有单点故障，即使处于“降级”模式，它也能为数据请求提供服务。Ceph 的数据放置引入了一个间接层，以确保数据不直接绑定到特定的 OSD。因此，跟踪系统故障需要找到放置组 (PG) 以及作为问题根源的底层 OSD。
提示
集群某个部分的故障可能会阻止您访问特定对象，但这并不意味着您无法访问其他对象。当您遇到故障时，请不要惊慌。只需按照步骤监控 OSD 和放置组，然后开始故障排除。
Ceph 是自修复的。但是，当问题持续存在时，监控 OSD 和放置组将帮助您确定问题。
监控 OSD
OSD 要么处于在用状态 (in)，要么处于不在用状态 (out)。OSD 要么正在运行且可访问 (up)，要么未运行且不可访问 (down)。
如果 OSD 处于 up 状态，它可能处于 in 服务状态（客户端可以读写数据）或处于 out 服务状态。如果 OSD 处于 in 状态，但由于故障或手动操作而被设置为 out 状态，Ceph 会将放置组迁移到其他 OSD，以保持配置的冗余。
如果 OSD 处于 out 状态，CRUSH 将不会向其分配放置组。如果 OSD 处于 down 状态，它也将处于 out 状态。
注意
如果 OSD 处于 down 和 in 状态，则表明存在问题，并且表明集群处于不健康状态。
如果您运行命令 ceph health、ceph -s 或 ceph -w，您可能会注意到集群并不总是显示 HEALTH OK。不要惊慌。在某些情况下，集群不显示 HEALTH OK 是预期且正常的
您尚未启动集群。
您刚刚启动或重新启动了集群，但它尚未准备好显示健康状态，因为 PG 正在创建中，OSD 正在对等中。
您刚刚添加或删除了 OSD。
您刚刚修改了集群地图。
检查 OSD 是否 up 并正在运行是监控它们的一个重要方面：只要集群启动并运行，集群中 in 的每个 OSD 都应同时 up 并运行。要查看集群的所有 OSD 是否正在运行，请运行以下命令
ceph osd stat
输出提供以下信息：OSD 总数 (x)，有多少 OSD 处于 up 状态 (y)，有多少 OSD 处于 in 状态 (z)，以及地图 epoch (eNNNN)。
x osds: y up, z in; epoch: eNNNN
如果集群中 in 的 OSD 数量大于 up 的 OSD 数量，请运行以下命令以识别未运行的 ceph-osd 守护程序
ceph osd tree
#ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 2.00000 pool openstack
-3 2.00000 rack dell-2950-rack-A
-2 2.00000 host dell-2950-A1
0 ssd 1.00000 osd.0 up 1.00000 1.00000
1 ssd 1.00000 osd.1 down 1.00000 1.00000
提示
搜索设计良好的 CRUSH 层次结构以识别特定 OSD 的物理位置可能有助于您对集群进行故障排除。
如果 OSD 处于 down 状态，请运行以下命令启动它
sudo systemctl start ceph-osd@1
对于与已停止或无法重新启动的 OSD 相关的问题，请参阅OSD 未运行。
PG 集
当 CRUSH 将 PG 分配给 OSD 时，它会记录池所需的 PG 副本数，然后将每个副本分配给不同的 OSD。例如，如果池需要 PG 的三个副本，CRUSH 可能会将它们分别分配给 osd.1、osd.2 和 osd.3。CRUSH 寻求伪随机放置，同时考虑到您在 CRUSH 地图中设置的故障域；因此，在大型集群中，PG 很少分配给紧邻的 OSD。
Ceph 使用 Acting Set（活动集）OSD 处理客户端请求：这是当前拥有 PG 分片完整且正常工作版本并因此负责处理请求的 OSD 集合。相比之下，Up Set（向上集）是包含特定 PG 分片的 OSD 集合。数据被移动或复制到 Up Set，或计划被移动或复制到 Up Set。请参阅放置组概念。
有时，Acting Set 中的 OSD 处于 down 状态，或者无法为 PG 中的对象提供请求服务。当出现这种情况时，不要惊慌。这种情况的常见示例包括
您添加或删除了 OSD，CRUSH 将 PG 重新分配给其他 OSD，此重新分配更改了 Acting Set 的组成，并通过“回填”过程触发了数据迁移。
OSD 处于
down状态，已重新启动，现在正在recovering。Acting Set 中的 OSD 处于
down状态或无法提供请求服务，另一个 OSD 已暂时承担其职责。
通常，Up Set 和 Acting Set 是相同的。当它们不相同时，可能表明 Ceph 正在迁移 PG（换句话说，PG 已被重新映射）、OSD 正在恢复，或者集群存在问题（在这种情况下，Ceph 通常显示“HEALTH WARN”状态并带有“stuck stale”消息）。
要检索 PG 列表，请运行以下命令
ceph pg dump
要查看特定 PG 的 Acting Set 和 Up Set 中有哪些 OSD，请运行以下命令
ceph pg map {pg-num}
输出提供以下信息：osdmap epoch (eNNN)，PG 编号 ({pg-num})，Up Set 中的 OSD (up[])，以及 Acting Set 中的 OSD (acting[])
osdmap eNNN pg {raw-pg-num} ({pg-num}) -> up [0,1,2] acting [0,1,2]
注意
如果 Up Set 和 Acting Set 不匹配，这可能表明集群正在重新平衡自身，或者集群存在问题。
对等
在您可以将数据写入 PG 之前，它必须处于 active 状态，并且最好处于 clean 状态。为了让 Ceph 确定 PG 的当前状态，必须进行对等。也就是说，PG 的主 OSD（Acting Set 中的第一个 OSD）必须与辅助 OSD 和后续 OSD 进行对等，以便就 PG 的当前状态达成共识。在下图中，我们假设一个具有 PG 三个副本的池
OSD 还会向监视器报告其状态。有关详细信息，请参阅配置监视器/OSD 交互。要解决对等问题，请参阅对等故障。
监控 PG 状态
如果您运行命令 ceph health、ceph -s 或 ceph -w，您可能会注意到集群并不总是显示 HEALTH OK。在首先检查 OSD 是否正在运行之后，您还应该检查 PG 状态。在某些与 PG 对等相关的特定情况下，集群不显示 HEALTH OK 是预期且正常的
您刚刚创建了一个池，PG 尚未对等。
PG 正在恢复。
您刚刚向集群添加了一个 OSD 或从集群中删除了一个 OSD。
您刚刚修改了 CRUSH 地图，PG 正在迁移。
PG 的不同副本中存在不一致的数据。
Ceph 正在擦洗 PG 的副本。
Ceph 没有足够的存储容量来完成回填操作。
如果其中一种情况导致 Ceph 显示 HEALTH WARN，请不要惊慌。在许多情况下，集群会自行恢复。但在某些情况下，您可能需要采取行动。监控 PG 的一个重要方面是检查它们的状态是否为 active 和 clean：也就是说，重要的是确保当集群启动并运行时，所有 PG 都处于 active 状态（并且最好处于 clean 状态）。要查看每个 PG 的状态，请运行以下命令
ceph pg stat
输出提供以下信息：PG 总数 (x)，有多少 PG 处于特定状态（例如 active+clean (y)），以及存储的数据量 (z)。
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail
注意
Ceph 报告 PGs 的多个状态是很常见的（例如，active+clean, active+clean+remapped, active+clean+scrubbing）。
此处 Ceph 不仅显示 PG 状态，还显示已使用的存储容量 (aa)、剩余的存储容量 (bb) 和 PG 的总存储容量。这些值在某些情况下很重要
集群正在接近其
near full ratio或full ratio。由于 CRUSH 配置错误，数据未在集群中分发。
要检索 PG 列表，请运行以下命令
ceph pg dump
要将输出格式化为 JSON 格式并将其保存到文件，请运行以下命令
ceph pg dump -o {filename} --format=json
要查询特定 PG，请运行以下命令
ceph pg {poolnum}.{pg-id} query
Ceph 将以 JSON 格式输出查询结果。
以下小节详细描述了最常见的 PG 状态。
创建中
当您创建池时，会创建 PG：创建池的命令指定了该池的 PG 总数，并且当池创建时，所有这些 PG 也会被创建。Ceph 会在创建 PG 时回显 creating。PG 创建后，作为 PG 的 Acting Set 一部分的 OSD 将进行对等。对等完成后，PG 状态应为 active+clean。此状态意味着 Ceph 客户端可以开始向 PG 写入。
对等
当 PG 进行对等时，存储其数据副本的 OSD 会就该 PG 内的数据和元数据的约定状态达成一致。对等完成后，这些 OSD 会就该 PG 的状态达成一致。但是，对等过程的完成并不意味着每个副本都具有最新内容。
活动
在 Ceph 完成对等过程后，PG 应变为 active。 active 状态意味着 PG 中的数据通常可用于主 OSD 和副本 OSD 上的读取和写入操作。
干净
当 PG 处于 clean 状态时，所有持有其数据和元数据的 OSD 都已成功对等，并且没有多余的副本。Ceph 已将 PG 中的所有对象复制了正确的次数。
降级
当客户端将对象写入主 OSD 时，主 OSD 负责将副本写入副本 OSD。在主 OSD 将对象写入存储后，PG 将保持 degraded 状态，直到主 OSD 从副本 OSD 收到 Ceph 成功创建副本对象的确认。
PG 可以处于 active+degraded 状态的原因是 OSD 可以处于 active 状态，即使它尚未持有 PG 的所有对象。如果 OSD 处于 down 状态，Ceph 会将分配给 OSD 的每个 PG 标记为 degraded。当 OSD 重新联机时，PG 必须再次对等。但是，如果 PG 处于 active 状态，客户端仍然可以将新对象写入 degraded PG。
如果 OSD 处于 down 状态且 degraded 条件持续存在，Ceph 可能会将 down OSD 标记为集群 out，并将数据从 down OSD 重新映射到另一个 OSD。从被标记为 down 到被标记为 out 之间的时间由 mon_osd_down_out_interval 确定，默认设置为 600 秒。
PG 也可能处于 degraded 状态，因为 Ceph 期望在 PG 中找到一个或多个对象，但 Ceph 找不到。尽管您无法读取或写入找不到的对象，但您仍然可以访问 degraded PG 中的所有其他对象。
恢复中
Ceph 的设计目标是容错，因为硬件和其他服务器问题是预期甚至常规的。当 OSD 处于 down 状态时，其内容可能会落后于 PG 中其他副本的当前状态。当 OSD 返回到 up 状态时，必须更新 PG 的内容以反映当前状态。在此期间，OSD 可能处于 recovering 状态。
恢复并不总是微不足道的，因为硬件故障可能会导致多个 OSD 级联故障。例如，机架或机柜的网络交换机可能会发生故障，这可能导致许多主机机器的 OSD 落后于集群的当前状态。在这种情况下，只有在故障解决后每个 OSD 都恢复才能进行全面恢复。]
Ceph 提供了许多设置来确定集群如何平衡资源争用，即在处理新服务请求的需求与恢复数据对象和将 PG 恢复到当前状态的需求之间取得平衡。 osd_recovery_delay_start 设置允许 OSD 在开始恢复过程之前重新启动、重新对等甚至处理一些重放请求。 osd_recovery_thread_timeout 设置确定线程超时持续时间，因为多个 OSD 可能会以交错的速率失败、重新启动和重新对等。 osd_recovery_max_active 设置限制 OSD 可以同时处理的恢复请求数，以防止 OSD 无法提供服务。 osd_recovery_max_chunk 设置限制恢复数据块的大小，以防止网络拥塞。
回填
当新的 OSD 加入集群时，CRUSH 会将 PG 从已在集群中的 OSD 重新分配给新添加的 OSD。如果强制新 OSD 立即接受重新分配的 PG，可能会给新 OSD 带来过高的负载。通过回填 OSD，允许此过程在后台开始。回填操作完成后，新 OSD 将在准备就绪后立即开始提供请求。
在回填操作期间，您可能会看到几种状态：backfill_wait 表示回填操作待处理，但尚未开始；backfilling 表示回填操作正在进行中；backfill_toofull 表示请求了回填操作，但由于存储容量不足而无法完成。当 PG 无法回填时，它可能被视为 incomplete。
backfill_toofull 状态可能是短暂的。随着 PG 的移动，空间可能会变得可用。 backfill_toofull 状态与 backfill_wait 类似，因为条件改变后回填操作可以继续进行。
Ceph 提供了许多设置来管理与将 PG 重新分配给 OSD（尤其是新 OSD）相关的负载峰值。 osd_max_backfills 设置指定 OSD 同时进行回填的最大数量（默认值：1；请注意，如果 mClock 调度程序处于活动状态，您无法更改此设置，除非您设置 osd_mclock_override_recovery_settings = true，请参阅 mClock 回填）。 backfill_full_ratio 设置允许 OSD 在接近其满容量比率时拒绝回填请求（默认值：90%）。此设置可以通过 ceph osd set-backfillfull-ratio 命令更改。如果 OSD 拒绝回填请求， osd_backfill_retry_interval 设置允许 OSD 在特定间隔后重试请求（默认值：30 秒）。OSD 还可以设置 osd_backfill_scan_min 和 osd_backfill_scan_max 以管理扫描间隔（默认值分别为 64 和 512）。
重新映射
当为 PG 服务_Acting Set_ 发生变化时，数据会从旧的 Acting Set 迁移到新的 Acting Set。由于新的主 OSD 可能需要时间才能开始提供请求服务，因此可能需要旧的主 OSD 继续提供请求服务，直到 PG 数据迁移完成。数据迁移完成后，映射将使用新的 Acting Set 的主 OSD。
过时
尽管 Ceph 使用心跳来确保主机和守护程序正在运行，但 ceph-osd 守护程序可能会进入 stuck 状态，即它们没有及时报告统计信息（例如，可能存在暂时的网络故障）。默认情况下，OSD 守护程序每半秒报告一次 PG、up through、boot 和 failure 统计信息（即，根据 0.5 的值），这比心跳阈值定义的报告频率更高。如果 PG 的 Acting Set 的主 OSD 未能向监视器报告，或者如果其他 OSD 报告主 OSD down，监视器会将 PG 标记为 stale。
当您启动集群时，在对等过程完成之前看到 stale 状态是很常见的。但是，在集群运行一段时间后，看到 PG 处于 stale 状态表明这些 PG 的主 OSD 处于 down 状态或未向监视器报告 PG 统计信息。
识别有问题的 PG
如前所述，PG 并非仅仅因为其状态不是 active+clean 就一定有问题。当 PG 被卡住时，这可能表明 Ceph 无法执行自我修复。卡住的状态包括
不干净 (Unclean)：PG 包含未按所需次数复制的对象。在正常情况下，可以假定这些 PG 正在恢复。
非活动 (Inactive)：PG 无法处理读取或写入，因为它们正在等待具有最新数据的 OSD 重新变为
up。过时 (Stale)：PG 处于未知状态，因为托管它们的 OSD 在一段时间内（由
mon_osd_report_timeout确定）没有向监视器集群报告。
要识别卡住的 PG，请运行以下命令
ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]
有关更多详细信息，请参阅放置组子系统。要对卡住的 PG 进行故障排除，请参阅故障排除 PG 错误。
查找对象位置
要将对象数据存储在 Ceph 对象存储中，Ceph 客户端必须
设置对象名称
指定一个池
Ceph 客户端检索最新的集群地图，CRUSH 算法计算如何将对象映射到 PG，然后算法计算如何将 PG 动态分配给 OSD。要仅给定对象名称和池名称来查找对象位置，请运行以下形式的命令
ceph osd map {poolname} {object-name} [namespace]
随着集群的发展，对象位置可能会动态变化。Ceph 动态重新平衡的一个好处是 Ceph 使您免于手动执行迁移的负担。有关详细信息，请参阅架构部分。