8 pool(s) backfillfull health： HEALTH_ERR

admin · 发表于 2022-7-21 15:52:34

使用检查
ceph osd status
id  host  userd avail    wr ops  wr data rb ops  rb data state
3 mon2  1111  1111    0          0       0          0          backfillfull，exists,up

今天检查 CEPH 发现有一个 OSD 接近要满了的状态.
[root@storage02-ib ~]# ceph osd status
+----+----------------------------+-------+-------+--------+---------+--------+---------+------------------------+
| id |          host          |  used | avail | wr ops | wr data | rd ops | rd data |       state       |
+----+----------------------------+-------+-------+--------+---------+--------+---------+------------------------+

| 8  | compute02| 1374G | 4214G | 0 |    0 | 0 |    0 |    exists,up       |
| 9  | compute02| 2098G | 3490G | 0 |    0 | 0 |    0 |    exists,up       |
| 10 | compute02| 1715G | 3873G | 0 |    0 | 0 |    0 |    exists,up       |
| 13 |compute02|  172G | 13.7G | 0 |    0 | 0 |    0 | backfillfull,exists,up |

+----+----------------------------+-------+-------+--------+---------+--------+---------+------------------------+
情况如上, ceph osd status 命令可以发现 OSD 13 已经接近要满了的状态.
————————————————

admin · 发表于 2022-7-21 15:55:11

ceph -s 命令也可以看见提示 1 backfillfull osd(s), 由于 OSD pool 没有指定与 OSD 的 map 关系, 所以默认所有OSD都承载这些 pool 的, 所以也提示了 5 pool(s) backfillfull.

之所以还会提示 objects misplaced 是因为之前维护替换了一块硬盘, 正在数据恢复中.

由于这个满了的 OSD 正好是之前还没来得及下掉的 NVMe 存储, NVMe 想用做其他用途, 所以这次准备干脆把 NVMe 下掉了.

下掉 13 - 20 这几个 NVMe 的 OSD, CEPH 会自动将数据平衡到其他 OSD 中. 所以我们只需要先 mark OSD out, 然后删除 OSD, 最后移除硬件即可.

在移除过程一定先提前计算好容量是否足够, 如果下掉过多 OSD 导致整体容量不足, 将会导致 OSD 趋近于满的情况, 会造成集群读写性能下降甚至完全不能读写.

在移除的过程中, 也会占用系统的磁盘 IO 和网络带宽, 因此如果是线上业务, 一定规划好移除时间, 避免影响业务.

首先, 我们移除 OSD 13, 14 作为演示.

[root@storage02-ib ~]# ceph osd out 13 14;
marked out osd.13 osd.14
  cluster:
id:    0f7be0a4-2a05-4658-8829-f3d2f62579d2
health: HEALTH_WARN
         258661/4527742 objects misplaced (5.713%)
         Degraded data redundancy: 22131/4527742 objects degraded (0.489%), 3 pgs degraded

  services:
mon: 3 daemons, quorum storage01-ib,storage02-ib,storage03-ib
mgr: storage01-ib(active), standbys: storage03-ib, storage02-ib
osd: 19 osds: 19 up, 11 in; 36 remapped pgs
rgw: 2 daemons active

  data:
pools: 5 pools, 288 pgs
objects: 2.26 M objects, 8.6 TiB
usage: 18 TiB used, 43 TiB / 61 TiB avail
pgs:    22131/4527742 objects degraded (0.489%)
         258661/4527742 objects misplaced (5.713%)
         252 active+clean
         28  active+remapped+backfill_wait
         5 active+remapped+backfilling
         2 active+undersized+degraded+remapped+backfill_wait
         1 active+undersized+degraded+remapped+backfilling

  io:
recovery: 90 MiB/s, 22 objects/s

可以看到提示 258661/4527742 objects misplaced, 22131/4527742 objects degraded, 这些都是正在自动调整的数据.

等待调整完毕后, 我们依次下掉其他的OSD即可.

然后到对应的 OSD 的机器上, 停止相应的 OSD daemon.

admin · 发表于 2022-7-22 08:34:59

要以交互模式运行 ceph 工具，请不带任何自变量在命令行中键入 ceph。如果要在一行中输入多条 ceph 命令，则使用交互模式较为方便。例如：

cephadm > ceph

ceph> health

ceph> status

ceph> quorum_status

ceph> mon_status

4.1 检查集群运行状况

在启动集群后到开始读取和/或写入数据期间，检查集群的运行状况：

root # ceph health

HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \

node-1,node-2,node-3

Ceph 集群会返回下列运行状况代码之一：

OSD_DOWN

一个或多个 OSD 标记为已停机。OSD 守护进程可能已停止，或对等 OSD 可能无法通过网络连接 OSD。常见原因包括守护进程已停止或已崩溃、主机已停机或网络中断。

校验主机是否运行良好，守护进程是否已启动，并且网络是否正常工作。如果守护进程已崩溃，守护进程日志文件 (/var/log/ceph/ceph-osd.*) 可能会包含调试信息。

OSD_crush type_DOWN，例如 OSD_HOST_DOWN

特定 CRUSH 子树中的所有 OSD 均标记为已停机，例如主机上的所有 OSD。

OSD_ORPHAN

在 CRUSH 地图层次结构中引用了 OSD，但它不存在。可使用以下命令从 CRUSH 层次结构中删除 OSD：

root # ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

backfillfull、nearfull、full 和/或 failsafe_full 的用量阈值没有采用升序。特别是，我们需要 backfillfull < nearfull，nearfull < full 且 full < failsafe_full。可使用以下命令调整阈值：

root # ceph osd set-backfillfull-ratio ratio

root # ceph osd set-nearfull-ratio ratio

root # ceph osd set-full-ratio ratio

OSD_FULL

一个或多个 OSD 超出了 full 阈值，阻止集群处理写入操作。可使用以下命令检查各存储池的用量：

root # ceph df

可使用以下命令查看当前定义的 full 比例：

root # ceph osd dump | grep full_ratio

恢复写入可用性的临时解决方法是稍稍提高 full 阈值：

root # ceph osd set-full-ratio ratio

请通过部署更多 OSD 将新的存储添加到集群，或者删除现有数据来腾出空间。

OSD_BACKFILLFULL

一个或多个 OSD 超出了 backfillfull 阈值，因而不允许将数据重新平衡到此设备。这是一条预警，意味着重新平衡可能无法完成，并且集群将满。可使用以下命令检查各存储池的用量：

root # ceph df

OSD_NEARFULL

一个或多个 OSD 超出了 nearfull 阈值。这是一条预警，意味着集群将满。可使用以下命令检查各存储池的用量：

root # ceph df

OSDMAP_FLAGS

已设置一个或多个所需的集群标志。可使用以下命令设置或清除这些标志（full 除外）：

root # ceph osd set flag

root # ceph osd unset flag

这些标志包括：

full

集群标记为已满，无法处理写入操作。

pauserd、pausewr

已暂停读取或写入。

noup

不允许 OSD 启动。

nodown

将会忽略 OSD 故障报告，如此监视器便不会将 OSD 标记为 down。

noin

先前标记为 out 的 OSD 在启动时将不会重新标记为 in。

noout

停机的 OSD 在配置间隔过后将不会自动标记为 out。

nobackfill、norecover、norebalance

恢复或数据重新平衡进程已暂停。

noscrub、nodeep_scrub

整理 (scrub) 进程已禁用（请参见第 6.5 节 “整理 (Scrub)”）。

notieragent

快速缓存分层活动已暂停。

OSD_FLAGS

一个或多个 OSD 设置了所需的每 OSD 标志。这些标志包括：

noup

不允许 OSD 启动。

nodown

将会忽略此 OSD 的故障报告。

noin

如果此 OSD 先前在发生故障后自动标记为 out，当它启动时将不会标记为 in。

noout

如果此 OSD 已停机，则在配置的间隔过后，它将不会自动标记为 out。

可使用以下命令来设置和清除每 OSD 标志：

root # ceph osd add-flag osd-ID

root # ceph osd rm-flag osd-ID

OLD_CRUSH_TUNABLES

CRUSH 地图目前使用的设置很旧，应予以更新。mon_crush_min_required_version 配置选项可确定使用时不会触发此运行状况警告的最旧可调变量（即能够连接到集群的最旧客户端版本）。

OLD_CRUSH_STRAW_CALC_VERSION

CRUSH 地图目前使用较旧的非最佳方法来计算 straw 桶的中间权重值。应该更新 CRUSH 地图以使用较新的方法 (straw_calc_version=1)。

CACHE_POOL_NO_HIT_SET

一个或多个快速缓存池未配置命中集来跟踪用量，这使分层代理无法识别要从快速缓存中清理和逐出的冷对象。可使用以下命令对快速缓存池配置命中集：

root # ceph osd pool set poolname hit_set_type type

root # ceph osd pool set poolname hit_set_period period-in-seconds

root # ceph osd pool set poolname hit_set_count number-of-hitsets

root # ceph osd pool set poolname hit_set_fpp target-false-positive-rate

OSD_NO_SORTBITWISE

未在运行早于 Luminous 12 版本的 OSD，但是尚未设置 sortbitwise 标志。您需要先设置 sortbitwise 标志，Luminous 12 或更新版本的 OSD 才能启动：

root # ceph osd set sortbitwise

POOL_FULL

一个或多个存储池已达到其配额，不再允许写入。可使用以下命令设置存储池配额和用量：

root # ceph df detail

您可以使用以下命令提高存储池配额

root # ceph osd pool set-quota poolname max_objects num-objects

root # ceph osd pool set-quota poolname max_bytes num-bytes

或者删除一些现有数据以减少用量。

PG_AVAILABILITY

数据可用性下降，这意味着集群无法处理针对集群中某些数据的潜在读取或写入请求。具体而言，一个或多个 PG 处于不允许处理 IO 请求的状态。有问题的 PG 状态包括连接建立中、不新鲜、不完整和不活跃（如果这些状况不迅速解决）。运行以下命令可获得有关哪些 PG 受影响的详细信息：

root # ceph health detail

大多数情况下，出现此情形的根本原因在于一个或多个 OSD 当前已停机。可使用以下命令查询特定的有问题 PG 的状态：

root # ceph tell pgid query

PG_DEGRADED

某些数据的数据冗余降低，这意味着集群没有所需数量的副本用于所有数据（对于副本池）或纠删码分段（对于纠删码池）。具体而言，一个或多个 PG 设置了 degraded 或 undersized 标志（集群中没有该归置组的足够实例），或者有一段时间未设置 clean 标志。运行以下命令可获得有关哪些 PG 受影响的详细信息：

root # ceph health detail

大多数情况下，出现此情形的根本原因在于一个或多个 OSD 当前已停机。可使用以下命令查询特定的有问题 PG 的状态：

root # ceph tell pgid query

PG_DEGRADED_FULL

由于集群中的可用空间不足，某些数据的数据冗余可能已降低或面临风险。具体而言，一个或多个 PG 设置了 backfill_toofull 或 recovery_tooful 标志，这意味着集群无法迁移或恢复数据，原因是一个或多个 OSD 高于 backfillfull 阈值。

PG_DAMAGED

数据整理 (scrub)（请参见第 6.5 节 “整理 (Scrub)”）进程发现集群中存在某些数据一致性问题。具体而言，一个或多个 PG 设置了 inconsistent 或 snaptrim_error 标志（表示某个较早的整理操作发现问题），或者设置了 repair 标志（表示当前正在修复此类不一致问题）。

OSD_SCRUB_ERRORS

最近的 OSD 整理 (scrub) 操作发现了不一致问题。

CACHE_POOL_NEAR_FULL

快速缓存层池将满。在此环境中，“满”由快速缓存池的 target_max_bytes 和 target_max_objects 属性确定。池达到目标阈值时，如果正在从快速缓存清理并逐出数据，写入池的请求可能会被阻止，出现常会导致延迟很高且性能变差的状态。可使用以下命令调整快速缓存池目标大小：

root # ceph osd pool set cache-pool-name target_max_bytes bytes

root # ceph osd pool set cache-pool-name target_max_objects objects

正常的快速缓存清理和逐出活动还可能因基础层可用性或性能下降或者集群的整体负载较高而受到限制。

TOO_FEW_PGS

使用中的 PG 数量低于每个 OSD 的 PG 数的可配置阈值 mon_pg_warn_min_per_osd。这可能导致集群中各 OSD 间的数据分布和平衡未达到最佳，以致降低整体性能。

TOO_MANY_PGS

使用中的 PG 数量高于每个 OSD 的 PG 数的可配置阈值 mon_pg_warn_max_per_osd。这可能导致 OSD 守护进程的内存用量较高，集群状态更改（例如 OSD 重启动、添加或删除）之后建立连接速度降低，并且 Ceph manager 和 Ceph monitor 上的负载较高。

虽然不能降低现有存储池的 pg_num 值，但是可以降低 pgp_num 值。这样可有效地在同组 OSD 上并置一些 PG，从而减轻上述的一些负面影响。可使用以下命令调整 pgp_num 值：

root # ceph osd pool set pool pgp_num value

SMALLER_PGP_NUM

一个或多个存储池的 pgp_num 值小于 pg_num。这通常表示 PG 计数有所提高，但未同时提升归置行为。使用以下命令设置 pgp_num，使其与触发数据迁移的 pg_num 相匹配，通常便可解决此问题：

ceph osd pool set pool pgp_num pg_num_value

MANY_OBJECTS_PER_PG

一个或多个存储池的每 PG 平均对象数大大高于集群的整体平均值。该特定阈值通过 mon_pg_warn_max_object_skew 配置值控制。这通常表示包含集群中大部分数据的存储池具有的 PG 太少，以及/或者不包含这么多数据的其他存储池具有的 PG 太多。可通过调整监视器上的 mon_pg_warn_max_object_skew 配置选项提高阈值，来消除该运行状况警告。

POOL_APP_NOT_ENABLED

存在包含一个或多个对象但尚未标记为供特定应用使用的存储池。将存储池标记为供某个应用使用即可消除此警告。例如，如果存储池由 RBD 使用：

root # rbd pool init pool_name

如果存储池正由自定义应用“foo”使用，您还可以使用低级别命令标记它：

root # ceph osd pool application enable foo

POOL_FULL

一个或多个存储池已达到（或几乎要达到）其配额。触发此错误状况的阈值通过 mon_pool_quota_crit_threshold 配置选项控制。可使用以下命令上调、下调（或删除）存储池配额：

root # ceph osd pool set-quota pool max_bytes bytes

root # ceph osd pool set-quota pool max_objects objects

将配额值设置为 0 将禁用配额。

POOL_NEAR_FULL

一个或多个存储池接近其配额。触发此警告状况的阈值通过 mon_pool_quota_warn_threshold 配置选项控制。可使用以下命令上调、下调（或删除）存储池配额：

root # ceph osd osd pool set-quota pool max_bytes bytes

root # ceph osd osd pool set-quota pool max_objects objects

将配额值设置为 0 将禁用配额。

OBJECT_MISPLACED

集群中的一个或多个对象未存储在集群希望用于存储这些对象的节点上。这表示集群最近的某项更改导致的数据迁移尚未完成。误放的数据本质上不属于危险状况。数据一致性方面永远不会有风险，仅当所需位置放置了对象所需份数的新副本之后，系统才会删除对象的旧副本。

OBJECT_UNFOUND

找不到集群中的一个或多个对象。具体而言，OSD 知道对象的新副本或已更新副本应该存在，但当前在线的 OSD 上找不到该版本的对象副本。系统将阻止对“未找到”对象的读取和写入请求。理想情况下，系统可将具有未找到对象的最近副本的已停机 OSD 恢复在线状态。可通过负责处理未找到对象的 PG 的互联状态识别候选 OSD：

root # ceph tell pgid query

REQUEST_SLOW

正花费很长的时间处理一个或多个 OSD 请求。这可能表示负载极重、存储设备速度缓慢或有软件错误。可以从 OSD 主机执行以下命令来查询有问题的 OSD 上的请求队列：

root # ceph daemon osd.id ops

可以查看近期最慢的请求摘要：

root # ceph daemon osd.id dump_historic_ops

可使用以下命令查找 OSD 的位置：

root # ceph osd find osd.id

REQUEST_STUCK

已将一个或多个 OSD 请求阻止了很长时间。这表示集群很长一段时间运行状况不佳（例如没有足够的运行中 OSD），或 OSD 存在一些内部问题。

PG_NOT_SCRUBBED

最近未整理 (scrub)（请参见第 6.5 节 “整理 (Scrub)”）一个或多个 PG。通常每 mon_scrub_interval 秒整理 (scrub) 一次 PG，当 mon_warn_not_scrubbed 这类间隔已过但未进行整理 (scrub) 时，就会触发此警告。如果 PG 未标记为清理，系统将不会整理 (scrub) 它们。如果 PG 放置错误或已降级，就会出现这种情况（请参见上文中的 PG_AVAILABILITY 和 PG_DEGRADED）。您可以使用以下命令手动对标记为清理的 PG 启动整理 (scrub)：

root # ceph pg scrub pgid

PG_NOT_DEEP_SCRUBBED

最近未深层整理 (deep scrub)（请参见第 6.5 节 “整理 (Scrub)”）一个或多个 PG。通常每 osd_deep_scrub_interval 秒整理 (scrub) 一次 PG，当 mon_warn_not_deep_scrubbed 这类间隔已过但未进行整理 (scrub) 时，就会触发此警告。如果 PG 未标记为清理，系统将不会（深层）整理 (scrub) 它们。如果 PG 放置错误或已降级，就会出现这种情况（请参见上文中的 PG_AVAILABILITY 和 PG_DEGRADED）。您可以使用以下命令手动对标记为清理的 PG 启动整理 (scrub)：

admin · 发表于 2022-7-22 08:35:49

root # ceph pg deep-scrub pgid

提示

如果之前为您的配置或密钥环指定了非默认位置，则此时可以指定它们的位置：

root # ceph -c /path/to/conf -k /path/to/keyring health

4.2 监视集群

可以使用 ceph -s 了解集群的即时状态。例如，由一个监视器和两个 OSD 组成的微型 Ceph 集群可在某工作负载正在运行时列显以下内容：

cluster:

  id:    6586341d-4565-3755-a4fd-b50f51bee248

  health: HEALTH_OK

services:

  mon: 3 daemons, quorum blueshark1,blueshark2,blueshark3

  mgr: blueshark3(active), standbys: blueshark2, blueshark1

  osd: 15 osds: 15 up, 15 in

data:

  pools: 8 pools, 340 pgs

  objects: 537 objects, 1985 MB

  usage: 23881 MB used, 5571 GB / 5595 GB avail

  pgs:    340 active+clean

io:

  client: 100 MB/s rd, 26256 op/s rd, 0 op/s wr

输出内容提供了以下信息：

集群 ID
集群运行状况
监视器地图版本号和监视器仲裁的状态
OSD 地图版本号和 OSD 的状态
归置组地图版本
归置组和存储池数量
所存储数据理论上的数量和所存储对象的数量；以及
所存储数据的总量。

提示：Ceph 计算数据用量的方式

used 值反映实际使用的原始存储量。xxx GB / xxx GB 值表示集群的可用容量（两者中较小的数字），以及集群的整体存储容量。理论数量反映在复制、克隆所存储数据或创建其快照前这些数据的大小。因此，实际存储的数据量通常会超出理论上的存储量，因为 Ceph 会创建数据的副本，可能还会将存储容量用于克隆和创建快照。

显示即时状态信息的其他命令如下：

ceph pg stat
ceph osd pool stats
ceph df
ceph df detail
要获得实时更新的信息，请将以上任何命令（包括 ceph -s）放置在等待循环中，例如：

root # while true ; do ceph -s ; sleep 10 ; done

如果您看累了，请按 Ctrl–C。

4.3 检查集群的用量统计数字

要检查集群的数据用量和在各存储池中的数据分布，可以使用 df 选项。它类似于 Linux df。执行以下命令：

root # ceph df

GLOBAL:

SIZE    AVAIL    RAW USED    %RAW USED

55886G    55826G    61731M       0.11

POOLS:

NAME       ID    USED    %USED    MAX AVAIL    OBJECTS

testpool    1       0       0       17676G          0

ecpool    2    4077M    0.01       35352G       2102

test1       3       0       0       17676G          0

rbd       4       16       0       17676G          3

rbd1       5       16       0       17676G          3

ecpool1    6    5708M    0.02       35352G       2871

输出内容的 GLOBAL 段落提供集群用于数据的存储量概览。

SIZE：集群的整体存储容量。
AVAIL：集群中可以使用的可用空间容量。
RAW USED：已用的原始存储量。
% RAW USED：已用的原始存储量百分比。将此数字与 full ratio 和 near full ratio 搭配使用，可确保您不会用完集群的容量。有关其他详细信息，请参见存储容量。

注意：集群填充程度

原始存储填充程度达到 70% - 80%，表示需要向集群添加新的存储。较高的用量可能导致单个 OSD 填满，集群处于不良运行状况。

使用命令 ceph osd df tree 可列出所有 OSD 的填充程度。

输出内容的 POOLS 段落提供了存储池列表和每个存储池的理论用量。此段落的输出不反映副本、克隆数据或快照。例如，如果您存储含 1MB 数据的对象，理论用量将是 1MB，但是根据副本、克隆数据或快照数量，实际用量可能是 2MB 或更多。

NAME：存储池的名称。
ID：存储池 ID。
USED：以千字节 (KB) 为单位的理论已存储数据量，如果该数字附加了 M，则以兆字节为单位，如果附加了 G，则以千兆字节为单位。
%USED：每个存储池的理论已用存储百分比。
MAX AVAIL：给定存储池中的最大可用空间。
OBJECTS：每个存储池的理论已存储对象数。

注意

POOLS 段落中的数字是理论上的。它们不包括副本、快照或克隆数量。因此，USED 和 %USED 数量之和不会加总到输出内容 %GLOBAL 段落中的 RAW USED 和 %RAW USED 数量中。

4.4 检查集群的状态

要检查集群的状态，请执行以下命令：

root # ceph status

或者

root # ceph -s

在交互模式下，键入 status，然后按 Enter。

ceph> status

Ceph 将列显集群状态。例如，由一个监视器和两个 OSD 组成的微型 Ceph 集群可能会列显以下内容：

cluster b370a29d-9287-4ca3-ab57-3d824f65e339

health HEALTH_OK

monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1

osdmap e63: 2 osds: 2 up, 2 in

  pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects

      115 GB used, 167 GB / 297 GB avail

            1 active+clean+scrubbing+deep

         951 active+clean

4.5 检查 OSD 状态

可通过执行以下命令来检查 OSD，以确保它们已启动且正在运行：

root # ceph osd stat

或者

root # ceph osd dump

还可以根据 OSD 在 CRUSH 地图中的位置查看 OSD。

root # ceph osd tree

Ceph 将列显 CRUSH 树及主机、它的 OSD、OSD 是否已启动及其权重。

# id weight  type name    up/down reweight

-1    3    pool default

-3    3             rack mainrack

-2    3                      host osd-host

0    1                            osd.0 up    1

1    1                            osd.1 up    1

2    1                            osd.2 up    1

4.6 检查填满的 OSD

Ceph 可阻止您向填满的 OSD 写入数据，以防丢失数据。在正常运行的集群中，当集群接近其填满比例时，您会收到警告。mon osd full ratio 默认设为容量的 0.95 (95%)，达到该比例后，集群会阻止客户端写入数据。mon osd nearfull ratio 默认设为容量的 0.85 (85%)，达到该比例时，集群会生成运行状况警告。

可通过 ceph health 命令报告填满的 OSD 节点：

ceph health

  HEALTH_WARN 1 nearfull osds

  osd.2 is near full at 85%

或者

ceph health

  HEALTH_ERR 1 nearfull osds, 1 full osds

  osd.2 is near full at 85%

  osd.3 is full at 97%

处理填满的集群的最佳方法是添加新的 OSD 节点，以让集群将数据重新分布到新的可用存储。

如果 OSD 因填满而无法启动，您可以通过删除已满 OSD 中的一些归置组目录来删除一些数据。

提示：防止 OSD 填满

OSD 变满（即用完 100% 的磁盘空间）之后，往往会迅速崩溃而不发出警告。管理 OSD 节点时需记住下面几点提示。

每个 OSD 的磁盘空间（通常挂载在 /var/lib/ceph/osd/osd-{1,2..} 下）需放置在专用的底层磁盘或分区上。
检查 Ceph 配置文件，确保 Ceph 不会将其日志文件存储在专供 OSD 使用的磁盘/分区上。
确保没有其他进程写入专供 OSD 使用的磁盘/分区。
4.7 检查监视器状态

如果集群有多个监视器（这是很有可能的），则应在启动集群之后到读取和/或写入数据之前的期间检查监视器仲裁状态。有多个监视器在运行时，仲裁必须存在。您还应该定期检查监视器状态，确保它们正在运行。

要显示监视器地图，请执行以下命令：

root # ceph mon stat

或者

root # ceph mon dump

要检查监视器集群的仲裁状态，请执行以下命令：

root # ceph quorum_status

Ceph 将返回仲裁状态。例如，由三个监视器组成的 Ceph 集群可能返回以下内容：

{ "election_epoch": 10,

  "quorum": [

      0,

      1,

      2],

  "monmap": { "epoch": 1,

   "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",

   "modified": "2011-12-12 13:28:27.505520",

   "created": "2011-12-12 13:28:27.505520",

   "mons": [

         { "rank": 0,

            "name": "a",

            "addr": "127.0.0.1:6789\/0"},

         { "rank": 1,

            "name": "b",

            "addr": "127.0.0.1:6790\/0"},

         { "rank": 2,

            "name": "c",

            "addr": "127.0.0.1:6791\/0"}

         ]

}

}

4.8 检查归置组状态

归置组会将对象映射到 OSD。监视归置组时，您希望它们处于 active 和 clean 状态。有关详细的讨论内容，请参见监视 OSD 和归置组。

4.9 使用管理套接字

Ceph 管理套接字可让您通过套接字接口查询守护进程。默认情况下，Ceph 套接字驻留在 /var/run/ceph 下。要通过管理套接字访问守护进程，请登录运行守护进程的主机，并使用以下命令：

root # ceph --admin-daemon /var/run/ceph/socket-name

要查看可用的管理套接字命令，请执行以下命令：

root # ceph --admin-daemon /var/run/ceph/socket-name help

管理套接字命令可让您在运行时显示和设置您的配置。有关详细信息，请参见在运行时查看配置。

另外，您也可以直接在运行时设置配置（管理套接字会绕过监视器，这与 ceph tell daemon-type.id injectargs 不同，后者依赖于监视器，但不需要您直接登录有问题的主机）。

		自动登录	找回密码
密码			注册

8 pool(s) backfillfull health： HEALTH_ERR

浏览过的版块