高可用性和高可靠性需要一种容错方法来管理硬件和软件问题。Ceph 没有单点故障，并且可以以“降级”模式为数据请求提供服务。Ceph 的数据放置引入了一个间接层，以确保数据不会直接绑定到特定的 OSD 地址。这意味着跟踪系统故障需要找到问题根源所在的归置组和底层 OSD。

提示 集群的某一部分出现故障可能会阻止您访问特定对象，但这并不意味着您无法访问其他对象。当你遇到故障时，不要惊慌。只需按照步骤监控您的 OSD 和归置组。然后，开始故障排除。

Ceph 通常是自我修复的。但是，当问题仍然存在时，监控 OSD 和归置组将帮助您识别问题。

监控 OSD

OSD 的状态是在集群中（in）或集群外（out）；并且，它要么启动并运行 ( up)，要么已关闭且未运行 ( down)。如果一个 OSD 是up，它可能是in（你可以读写数据）或者是out的。如果是 in并且最近移动out，Ceph 会将归置组迁移到其他 OSD。如果一个 OSD 属于out，CRUSH 不会将归置组分配给该 OSD。如果一个 OSD 是down，它也应该是 out。

笔记：如果 OSD 为down和in，则表示存在问题，集群将不会处于健康状态。

如果您执行诸如ceph health、ceph -s或ceph -w之类的命令，您可能会注意到集群并不总是回显HEALTH OK。不要惊慌。对于 OSD，您应该期望集群在一些预期的情况下不会 回 显HEALTH OK：

1. 您尚未启动集群（它不会响应）。
2. 您刚刚启动或重新启动了集群，但它还没有准备好，因为正在创建归置组并且 OSD 正在进行对等互连。
3. 您刚刚添加或删除了一个 OSD。
4. 您刚刚修改了集群图。


监控 OSD 的一个重要方面是确保当集群启动并运行时，作为集群的所有 OSD 都在up运行并且是in的。要查看是否所有 OSD 都在运行，请执行：

ceph osd stat


结果应该告诉您 OSD 的总数 (x)、有多少up(y)、有多少in(z) 和地图纪元 (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 是down，请启动它：

sudo systemctl start ceph-osd@1


有关与停止或不会重新启动的 OSD 相关的问题，请参阅OSD 未运行。

PG SETS

当 CRUSH 将归置组分配给 OSD 时，它会查看存储池的副本数量，并将归置组分配给 OSD，以便将归置组的每个副本分配给不同的 OSD。例如，如果池需要一个归置组的三个副本，CRUSH 可以将它们分别分配给 osd.1,osd.2和osd.3。CRUSH 实际上会寻找一个伪随机放置，它会考虑您在CRUSH 映射中设置的故障域，因此您很少会看到放置组分配给大型集群中最近的邻居 OSD。

Ceph 使用Acting Set处理客户端请求，Acting Set是实际处理请求的 OSD 集合，因为它们具有完整且可工作的归置组分片版本。应该包含特定归置组的分片作为Up Set的 OSD 集，即数据被移动/复制到（或计划到）的位置。

在某些情况下，Acting Set 中的 OSD down无法为归置组中对象的请求提供服务。当这些情况出现时，不要惊慌。常见的例子包括：

1. 您添加或删除了 OSD。然后，CRUSH 将归置组重新分配给其他 OSD——从而改变了 Acting Set 的组成，并通过“回填”过程产生了数据迁移。
2. 一个 OSD 曾经down，被重新启动，现在是recovering。
3. Acting Set 中的一个 OSD 正在down或无法为请求提供服务，而另一个 OSD 暂时承担了其职责。


在大多数情况下，Up Set 和 Acting Set 是相同的。如果不是，则可能表明 Ceph 正在迁移 PG（它已重新映射）、OSD 正在恢复或存在问题（即，Ceph 通常会回显“HEALTH WARN”状态并在这样的场景）。

要检索归置组列表，请执行：

ceph pg dump


要查看给定归置组的 Acting Set 或 Up Set 中的 OSD，请执行：

ceph pg map {pg-num}


结果应该告诉你 osdmap epoch (eNNN)、归置组编号 ({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 不匹配，这可能是集群重新平衡自身或集群潜在问题的指标。

PEERING

在您可以将数据写入归置组之前，它必须处于一种active 状态，并且它 应该处于一种clean状态。为了让 Ceph 确定一个归置组的当前状态，该归置组的主 OSD（即Acting Set中的第一个 OSD）、与辅助和第三 OSD 对等以就归置组的当前状态建立协议（假设一个池有 3 个 PG 副本）。

OSD 还向MON报告其状态。有关详细信息，请参阅配置MON/OSD 交互。要解决对等互连问题，请参阅对等互连故障。

监控PG（归置组）状态

如果您执行诸如ceph health、ceph -s或ceph -w之类的命令，您可能会注意到集群并不总是回显HEALTH OK。检查 OSD 是否正在运行后，您还应该检查归置组状态。您应该期望集群不会在许多与归置组对等相关的情况下回显HEALTH OK：

1. 您刚刚创建了一个池，而归置组尚未对等。
2. 归置组正在恢复。
3. 您刚刚在集群中添加了一个 OSD 或从集群中删除了一个 OSD。
4. 您刚刚修改了 CRUSH 地图，并且您的归置组正在迁移。
5. 一个归置组的不同副本中存在不一致的数据。
6. Ceph 正在清理归置组的副本。
7. Ceph 没有足够的存储容量来完成回填操作。


如果上述情况之一导致 Ceph 回显HEALTH WARN，请不要惊慌。在许多情况下，集群会自行恢复。在某些情况下，您可能需要采取行动。监控归置组的一个重要方面是确保当集群启动并运行时，所有归置组都处于 active，并且最好处于 clean 状态。要查看所有归置组的状态，请执行：

ceph pg stat


结果应该告诉您归置组的总数 (x)、有多少归置组处于特定状态，例如active+clean(y) 以及存储的数据量 (z)。

x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail


笔记：Ceph 报告归置组的多个状态是很常见的。

除了归置组状态，Ceph 还会回显已使用的存储容量 (aa)、剩余存储容量 (bb) 以及归置组的总存储容量（cc）。这些数字在某些情况下可能很重要：

• 您正在达到您的near full ratio或full ratio。


• 由于 CRUSH 配置中的错误，您的数据没有在集群中分布。

**Placement Group IDs**
归置组 ID 由后跟一个句点 (.) 的池编号（不是池名称）和归置组 ID（一个十六进制数字）组成。您可以从 ceph osd lspools的输出中查看池编号及其名称。例如，创建的第一个池对应于 pool number 1。完全合格的归置组 ID 具有以下形式：
{pool-num}.{pg-id}
它通常看起来像这样：
1.1f


要检索归置组列表，请执行以下操作：

ceph pg dump


您还可以将输出格式化为 JSON 格式并将其保存到文件中：

ceph pg dump -o {filename} --format=json


要查询特定的归置组，请执行以下命令：

ceph pg {poolnum}.{pg-id} query


Ceph 将以 JSON 格式输出查询。

以下小节详细描述了常见的 pg 状态。

CREATING

创建池时，它将创建您指定数量的归置组。Ceph在创建一个或多个归置组时会回显creating。一旦它们被创建，作为归置组Acting Set一部分的 OSD 就会对等。对等连接完成后，归置组状态应为active+clean，这意味着 Ceph 客户端可以开始写入归置组。

PEERING

当 Ceph 与归置组建立 Peering 时，Ceph 使存储归置组副本的 OSD 就归置组 中对象和元数据的状态达成一致。当 Ceph 完成对等互连时，这意味着存储该归置组的 OSD 就该归置组的当前状态达成一致。但是，对等过程的完成并不意味着每个副本都有最新的内容。

**Authoritative History**
Ceph 不会向客户端确认写操作，直到Acting Set的所有 OSD 都坚持写操作。这种做法确保了Acting Set的至少一个成员将拥有自上次成功的对等操作以来每个确认的写操作的记录。
通过准确记录每个已确认的写入操作，Ceph 可以构建和传播新的归置组权威历史记录——一组完整且完全有序的操作，如果执行这些操作，将使 OSD 的归置组副本保持最新.


ACTIVE

一旦 Ceph 完成对等过程，一个归置组可能会变成 active. active状态是指归置组中的数据在主归置组和副本中普遍可用，可进行读写操作。

CLEAN

当归置组处于该clean状态时，主 OSD 和副本 OSD 已成功对等，并且该归置组没有杂散副本。Ceph 将归置组中的所有对象复制了正确的次数。

DEGRADED

当客户端将对象写入主 OSD 时，主 OSD 负责将副本写入副本 OSD。主 OSD 将对象写入存储后，归置组将保持degraded 状态，直到主 OSD 收到来自副本 OSD 的 Ceph 成功创建副本对象的确认。

一个归置组active+degraded的原因是一个 OSD 可能 active即使它还没有保存所有的对象。如果某个 OSD 发生 down故障，Ceph 会将分配给该 OSD 的每个归置组标记为degraded. 当 OSD 重新联机时，OSD 必须再次对等。但是，客户端仍然可以将新对象写入degraded归置组（如果它是active）。

如果一个 OSD 是down并且degraded条件持续存在，Ceph 可能会将 down OSD 标记为out，并将数据从down OSD 重新映射到另一个 OSD。被标记down和被标记out之间的时间由 mon osd down out interval 控制，默认设置为600秒。

归置组也可以是degraded，因为 Ceph 找不到 Ceph 认为应该在归置组中的一个或多个对象。虽然您无法读取或写入未找到的对象，但您仍然可以访问degraded置放群组中的所有其他对象。

RECOVERING

Ceph 设计用于在硬件和软件问题持续存在的规模上进行容错。当一个 OSD 过去down时，它的内容可能落后于归置组中其他副本的当前状态。当 OSD 返回up时，必须更新归置组的内容以反映当前状态。在那个时间段内，OSD 可能会反映一个recovering 状态。

恢复并不总是微不足道的，因为硬件故障可能会导致多个 OSD 的级联故障。例如，机架或机柜的网络交换机可能发生故障，这可能导致许多主机的 OSD 落后于集群的当前状态。一旦故障解决，每个 OSD 都必须恢复。

Ceph 提供了许多设置来平衡新服务请求之间的资源争用以及恢复数据对象和将归置组恢复到当前状态的需要。该osd recovery delay start设置允许 OSD 在开始恢复过程之前重新启动、重新对等甚至处理一些重播请求。osd recovery thread timeout设置线程超时，因为多个 OSD 可能会以交错的速率发生故障、重新启动和重新对等。该osd recovery max active设置限制了 OSD 将同时处理的恢复请求的数量，以防止 OSD 无法服务。该osd recovery max chunk设置限制了恢复的数据块的大小，以防止网络拥塞。

BACK FILLING

当有新的 OSD 加入集群时，CRUSH 会将集群中 OSD 的归置组重新分配给新添加的 OSD。强制新 OSD 立即接受重新分配的归置组可能会给新 OSD 带来过多的负载。使用归置组回填 OSD 允许此过程在后台开始。回填完成后，新的 OSD 将在准备好后开始为请求提供服务。

在回填操作期间，您可能会看到以下几种状态之一： backfill_wait表示回填操作处于挂起状态，但尚未进行；backfilling表示正在进行回填操作；并且，backfill_toofull表示已请求回填操作，但由于存储容量不足而无法完成。当一个归置组不能回填时，可以考虑incomplete。

该backfill_toofull状态可能是暂时的。随着 PG 的移动，空间可能会变得可用。backfill_toofull类似于backfill_wait只要条件改变回填就可以进行。

Ceph 提供了许多设置来管理与将归置组重新分配给 OSD（尤其是新 OSD）相关的负载峰值。默认情况下， osd_max_backfills将进出 OSD 的最大并发回填数设置为 1。如果 OSD 接近其满载率backfill full ratio（默认为 90%）并随命令ceph osd set-backfillfull-ratio更改，这将使 OSD 拒绝回填请求。如果 OSD 拒绝回填请求，则 osd backfill retry interval允许 OSD 重试请求（默认为 30 秒后）。OSD 还可以设置osd backfill scan min和osd backfill scan max 管理扫描间隔（默认为 64 和 512）。

REMAPPED

当为归置组服务的 Acting Set发生变化时，数据会从旧 Acting Set迁移到新 Acting Set。新的主 OSD 可能需要一些时间来处理请求。因此它可能会要求旧的主节点继续为请求提供服务，直到归置组迁移完成。数据迁移完成后，映射将使用新 Acting Set的主 OSD。

STALE

虽然 Ceph 使用心跳来确保主机和守护进程正在运行，但 ceph-osd守护进程也可能会进入一种stuck无法及时报告统计信息的状态（例如，临时网络故障）。默认情况下，OSD 守护进程每半秒（即0.5）报告其归置组、up through、引导和故障统计信息，这比心跳阈值更频繁。如果某个归置组的acting set的主 OSD没有向MON报告，或者如果其他 OSD 已经报告了主 OSD down，MON将标记该归置组stale。

启动集群时，通常会在对等进程完成之前看到stale状态。在集群运行一段时间后，看到归置组stale状态表明这些归置组的主 OSD down是否正在向MON报告归置组统计信息。

识别有问题的 PG

如前所述，一个归置组不一定因为它的状态不是active+clean. 通常，当归置组卡住时，Ceph 的自我修复能力可能无法正常工作。卡住状态包括：

• Unclean：置放群组包含未按所需次数复制的对象。他们应该正在康复。


• Inactive：归置组无法处理读取或写入，因为它们正在等待具有最新数据的 OSD up回来。


• Stale：归置组处于未知状态，因为托管它们的 OSD 有一段时间没有向监控集群报告（由 mon osd report timeout配置）。

要识别卡住的归置组，请执行以下操作：

ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]


有关更多详细信息，请参阅归置组子系统。要排查卡住的置放群组，请参阅排查 PG 错误。

查找对象位置

要将对象数据存储在 Ceph 对象存储中，Ceph 客户端必须：

1. 设置对象名称


2. 指定一个池

Ceph 客户端获取最新的集群映射，CRUSH 算法计算如何将对象映射到归置组，然后计算如何将归置组动态分配给 OSD。要查找对象位置，您只需要对象名称和池名称即可。例如：

ceph osd map {poolname} {object-name} [namespace]


练习：定位对象
作为练习，让我们创建一个对象。使用命令行上的rados put命令指定对象名称、包含一些对象数据的测试文件的路径和池名称 。例如：
rados put {object-name} {file-path} --pool=data
rados put test-object-1 testfile.txt --pool=data
要验证 Ceph 对象存储是否存储了对象，请执行以下命令：
rados -p data ls
现在，确定对象位置：
ceph osd map {pool-name} {object-name}
ceph osd map data test-object-1
Ceph 应该输出对象的位置。例如：
osdmap e537 pool 'data' (1) object 'test-object-1' -> pg 1.d1743484 (1.4) -> up ([0,1], p0) acting ([0,1], p0)
要删除测试对象，只需使用rados rm命令将其删除。例如：
rados rm test-object-1 --pool=data


随着集群的发展，对象位置可能会动态变化。Ceph 动态再平衡的一个好处是，Ceph 使您不必手动执行迁移。有关详细信息，请参阅架构部分。

作者：Varden

出处：http://www.cnblogs.com/varden/

本文内容如有雷同，请联系作者！

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。