12 确定集群状态 #
当集群正在运行时，您可以使用 ceph 工具来监视它。要确定集群状态，通常需要检查 Ceph OSD、Ceph Monitor、归置组和元数据服务器的状态。
要以交互模式运行 ceph 工具，请不带任何参数在命令行中键入 ceph。如果要在一行中输入多条 ceph 命令，则使用交互模式较为方便。例如：
cephuser@adm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon stat12.1 检查集群的状态 #
您可以使用 ceph status 或 ceph -s 了解集群的即时状态：
cephuser@adm > ceph -s
cluster:
id: b4b30c6e-9681-11ea-ac39-525400d7702d
health: HEALTH_OK
services:
mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)
task status:
scrub status:
mds.my_cephfs.ses-min1.oterul: idle
data:
pools: 7 pools, 169 pgs
objects: 250 objects, 10 KiB
usage: 3.1 GiB used, 27 GiB / 30 GiB avail
pgs: 169 active+clean输出内容提供了以下信息：
集群 ID
集群健康状况状态
Monitor 索引版本号和 Monitor 仲裁的状态
OSD 索引版本号和 OSD 的状态
Ceph Manager 的状态
对象网关的状态
归置组索引版本
归置组和存储池数量
理论上存储的数据量和存储的对象数量
所存储数据的总量。
used 值反映实际使用的原始存储量。xxx GB / xxx GB 值表示集群的可用容量（两者中较小的数字），以及集群的整体存储容量。理论数量反映在复制、克隆所存储数据或创建其快照前这些数据的大小。因此，实际存储的数据量通常会超出理论上的存储量，因为 Ceph 会创建数据的副本，可能还会将存储容量用于克隆和创建快照。
显示即时状态信息的其他命令如下：
ceph pg statceph osd pool statsceph dfceph df detail
要实时更新信息，请在 watch 命令中以参数的方式使用以上任意命令（包括 ceph -s）：
# watch -n 10 'ceph -s'如果您看累了，请按 Ctrl–C。
12.2 检查集群健康状况 #
在启动集群后到开始读取和/或写入数据期间，检查集群的健康状况：
cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3如果之前为您的配置或密钥环指定了非默认位置，则此时可以指定它们的位置：
cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring healthCeph 集群会返回下列健康状况代码之一：
- 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：
cephuser@adm >ceph osd crush rm osd.ID- OSD_OUT_OF_ORDER_FULL
以下项的使用率阈值未按升序排列：backfillfull（默认值为 0.90）、nearfull（默认值为 0.85）、full（默认值为 0.95）、failsafe_full。特别是，我们需要 backfillfull < nearfull，nearfull < full 且 full < failsafe_full。
要读取最新的值，请运行以下命令：
cephuser@adm >ceph health detail HEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s) osd.3 is full at 97% osd.4 is backfill full at 91% osd.2 is near full at 87%可以使用以下命令调整阈值：
cephuser@adm >ceph osd set-backfillfull-ratio ratiocephuser@adm >ceph osd set-nearfull-ratio ratiocephuser@adm >ceph osd set-full-ratio ratio- OSD_FULL
一个或多个 OSD 超出了 full 阈值，阻止集群处理写入操作。可使用以下命令检查各存储池的用量：
cephuser@adm >ceph df可使用以下命令查看当前定义的 full 比例：
cephuser@adm >ceph osd dump | grep full_ratio恢复写入可用性的临时解决方法是稍稍提高 full 阈值：
cephuser@adm >ceph osd set-full-ratio ratio请通过部署更多 OSD 将新的存储添加到集群，或者删除现有数据来腾出空间。
- OSD_BACKFILLFULL
一个或多个 OSD 超出了 backfillfull 阈值，因而不允许将数据重新平衡到此设备。这是一条预警，意味着重新平衡可能无法完成，并且集群将满。可使用以下命令检查各存储池的用量：
cephuser@adm >ceph df- OSD_NEARFULL
一个或多个 OSD 超出了 nearfull 阈值。这是一条预警，意味着集群将满。可使用以下命令检查各存储池的用量：
cephuser@adm >ceph df- OSDMAP_FLAGS
已设置一个或多个所需的集群标志。可使用以下命令设置或清除这些标志（full 除外）：
cephuser@adm >ceph osd set flagcephuser@adm >ceph osd unset flag这些标志包括：
- full
集群标记为已满，无法处理写入操作。
- pauserd、pausewr
已暂停读取或写入。
- noup
不允许 OSD 启动。
- nodown
将会忽略 OSD 故障报告，如此 Monitor 便不会将 OSD 标记为 down。
- noin
先前标记为 out 的 OSD 在启动时将不会重新标记为 in。
- noout
停机的 OSD 在配置间隔过后将不会自动标记为 out。
- nobackfill、norecover、norebalance
恢复或数据重新平衡进程已暂停。
- noscrub、nodeep_scrub
洗刷进程已禁用（请参见第 17.6 节 “洗刷归置组”）。
- notieragent
缓存分层活动已暂停。
- OSD_FLAGS
一个或多个 OSD 设置了所需的每 OSD 标志。这些标志包括：
- noup
不允许 OSD 启动。
- nodown
将会忽略此 OSD 的故障报告。
- noin
如果此 OSD 先前在发生故障后自动标记为 out，当它启动时将不会标记为 in。
- noout
如果此 OSD 已停机，则在配置的间隔过后，它将不会自动标记为 out。
可使用以下命令来设置和清除每 OSD 标志：
cephuser@adm >ceph osd add-flag osd-IDcephuser@adm >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
一个或多个缓存池未配置命中集来跟踪用量，这使分层代理无法识别要从缓存中刷新和赶出的冷对象。可使用以下命令对快速缓存池配置命中集：
cephuser@adm >ceph osd pool set poolname hit_set_type typecephuser@adm >ceph osd pool set poolname hit_set_period period-in-secondscephuser@adm >ceph osd pool set poolname hit_set_count number-of-hitsetscephuser@adm >ceph osd pool set poolname hit_set_fpp target-false-positive-rate- OSD_NO_SORTBITWISE
未在运行早于 Luminous 12 版本的 OSD，但是尚未设置
sortbitwise标志。您需要先设置sortbitwise标志，Luminous 12 或更新版本的 OSD 才能启动：cephuser@adm >ceph osd set sortbitwise- POOL_FULL
一个或多个存储池已达到其配额，不再允许写入。可使用以下命令设置存储池配额和用量：
cephuser@adm >ceph df detail您可以使用以下命令提高存储池配额
cephuser@adm >ceph osd pool set-quota poolname max_objects num-objectscephuser@adm >ceph osd pool set-quota poolname max_bytes num-bytes或者删除一些现有数据以减少用量。
- PG_AVAILABILITY
数据可用性下降，这意味着集群无法处理针对集群中某些数据的潜在读取或写入请求。具体而言，一个或多个 PG 处于不允许处理 I/O 请求的状态。有问题的 PG 状态包括正在互联、过时、不完整和不工作（如果这些状况不迅速解决）。运行以下命令可获得有关哪些 PG 受影响的详细信息：
cephuser@adm >ceph health detail大多数情况下，出现此情形的根本原因在于一个或多个 OSD 当前已停机。可使用以下命令查询特定的有问题 PG 的状态：
cephuser@adm >ceph tell pgid query- PG_DEGRADED
某些数据的数据冗余降低，这意味着集群没有所需数量的副本用于所有数据（对于副本存储池）或纠删码分段（对于纠删码存储池）。具体而言，一个或多个 PG 设置了 degraded 或 undersized 标志（集群中没有该归置组的足够实例），或者有一段时间未设置 clean 标志。运行以下命令可获得有关哪些 PG 受影响的详细信息：
cephuser@adm >ceph health detail大多数情况下，出现此情形的根本原因在于一个或多个 OSD 当前已停机。可使用以下命令查询特定的有问题 PG 的状态：
cephuser@adm >ceph tell pgid query- PG_DEGRADED_FULL
由于集群中的可用空间不足，某些数据的数据冗余可能已降低或面临风险。具体而言，一个或多个 PG 设置了 backfill_toofull 或 recovery_tooful 标志，这意味着集群无法迁移或恢复数据，原因是一个或多个 OSD 高于 backfillfull 阈值。
- PG_DAMAGED
数据洗刷（请参见第 17.6 节 “洗刷归置组”）进程发现集群中存在某些数据一致性问题。具体而言，一个或多个 PG 设置了 inconsistent 或 snaptrim_error 标志（表示某个较早的洗刷操作发现问题），或者设置了 repair 标志（表示当前正在修复此类不一致问题）。
- OSD_SCRUB_ERRORS
最近的 OSD 洗刷操作发现了不一致问题。
- CACHE_POOL_NEAR_FULL
缓存层池将满。在此环境中，“满”由缓存池的 target_max_bytes 和 target_max_objects 属性确定。池达到目标阈值时，如果正在从缓存刷新并赶出数据，写入池的请求可能会被阻止，出现常会导致延迟很高且性能变差的状态。可使用以下命令调整缓存池目标大小：
cephuser@adm >ceph osd pool set cache-pool-name target_max_bytes bytescephuser@adm >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值：cephuser@adm >ceph osd pool set pool pgp_num value- SMALLER_PGP_NUM
一个或多个存储池的
pgp_num值小于pg_num。这通常表示 PG 计数有所提高，但未同时提升归置行为。使用以下命令设置pgp_num，使其与触发数据迁移的pg_num相匹配，通常便可解决此问题：cephuser@adm >ceph osd pool set pool pgp_num pg_num_value- MANY_OBJECTS_PER_PG
一个或多个存储池的每 PG 平均对象数大大高于集群的整体平均值。该特定阈值通过
mon_pg_warn_max_object_skew配置值控制。这通常表示包含集群中大部分数据的存储池具有的 PG 太少，以及/或者不包含这么多数据的其他存储池具有的 PG 太多。可通过调整 Monitor 上的mon_pg_warn_max_object_skew配置选项提高阈值，来消除该健康状况警告。- POOL_APP_NOT_ENABLED
存在包含一个或多个对象但尚未标记为供特定应用使用的存储池。将存储池标记为供某个应用使用即可消除此警告。例如，如果存储池由 RBD 使用：
cephuser@adm >rbd pool init pool_name如果存储池正由自定义应用“foo”使用，您还可以使用低级别命令标记它：
cephuser@adm >ceph osd pool application enable foo- POOL_FULL
一个或多个存储池已达到（或几乎要达到）其配额。触发此错误状况的阈值通过
mon_pool_quota_crit_threshold配置选项控制。可使用以下命令上调、下调（或删除）存储池配额：cephuser@adm >ceph osd pool set-quota pool max_bytes bytescephuser@adm >ceph osd pool set-quota pool max_objects objects将配额值设置为 0 将禁用配额。
- POOL_NEAR_FULL
一个或多个存储池接近其配额。触发此警告状况的阈值通过
mon_pool_quota_warn_threshold配置选项控制。可使用以下命令上调、下调（或删除）存储池配额：cephuser@adm >ceph osd osd pool set-quota pool max_bytes bytescephuser@adm >ceph osd osd pool set-quota pool max_objects objects将配额值设置为 0 将禁用配额。
- OBJECT_MISPLACED
集群中的一个或多个对象未存储在集群希望存储的节点上。这表示集群最近的某项更改导致的数据迁移尚未完成。误放的数据本质上不属于危险状况。数据一致性方面永远不会有风险，仅当所需位置放置了对象所需份数的新副本之后，系统才会删除对象的旧副本。
- OBJECT_UNFOUND
找不到集群中的一个或多个对象。具体而言，OSD 知道对象的新副本或更新副本应该存在，但在当前启用的 OSD 上却找不到该版对象的副本。系统将阻止对“未找到”对象的读取或写入请求。从理论上讲，可以将具有未找到对象最近副本的已停用 OSD 重新启用。可通过负责处理未找到对象的 PG 的互联状态识别候选 OSD：
cephuser@adm >ceph tell pgid query- REQUEST_SLOW
正花费很长的时间处理一个或多个 OSD 请求。这可能表示负载极重、存储设备速度缓慢或有软件错误。可以从 OSD 主机执行以下命令来查询有问题的 OSD 上的请求队列：
cephuser@adm >cephadm enter --name osd.ID -- ceph daemon osd.ID ops可以查看近期最慢的请求摘要：
cephuser@adm >cephadm enter --name osd.ID -- ceph daemon osd.ID dump_historic_ops可使用以下命令查找 OSD 的位置：
cephuser@adm >ceph osd find osd.id- REQUEST_STUCK
一个或多个 OSD 请求已被阻止一段相当长的时间，例如 4096 秒。这表示集群已有很长一段时间处于非健康状况（例如，没有足够的运行中 OSD 或非活跃 PG），或者 OSD 存在某种内部问题。
- PG_NOT_SCRUBBED
最近未洗刷（请参见第 17.6 节 “洗刷归置组”）一个或多个 PG。通常每
mon_scrub_interval秒洗刷一次 PG，当mon_warn_not_scrubbed这类间隔已过但未进行洗刷时，就会触发此警告。如果 PG 未标记为清理，系统将不会洗刷它们。如果 PG 放置错误或已降级，就会出现这种情况（请参见上文中的 PG_AVAILABILITY 和 PG_DEGRADED）。您可以使用以下命令手动对标记为清理的 PG 启动洗刷：cephuser@adm >ceph pg scrub pgid- PG_NOT_DEEP_SCRUBBED
最近未深层洗刷（请参见第 17.6 节 “洗刷归置组”）一个或多个 PG。通常每
osd_deep_scrub_interval秒洗刷一次 PG，当mon_warn_not_deep_scrubbed秒已过但未进行洗刷时，就会触发此警告。如果 PG 未标记为清理，系统将不会（深层）洗刷它们。如果 PG 放置错误或已降级，就会出现这种情况（请参见上文中的 PG_AVAILABILITY 和 PG_DEGRADED）。您可以使用以下命令手动对标记为清理的 PG 启动洗刷：cephuser@adm >ceph pg deep-scrub pgid
如果之前为您的配置或密钥环指定了非默认位置，则此时可以指定它们的位置：
# ceph -c /path/to/conf -k /path/to/keyring health12.3 检查集群的使用率统计数据 #
要查看集群的数据使用率以及数据在多个存储池之间的分布，请使用 ceph df 命令。要获取更多详细信息，请使用 ceph df detail。
cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 30 GiB 27 GiB 121 MiB 3.1 GiB 10.40
TOTAL 30 GiB 27 GiB 121 MiB 3.1 GiB 10.40
--- POOLS ---
POOL ID STORED OBJECTS USED %USED MAX AVAIL
device_health_metrics 1 0 B 0 0 B 0 8.5 GiB
cephfs.my_cephfs.meta 2 1.0 MiB 22 4.5 MiB 0.02 8.5 GiB
cephfs.my_cephfs.data 3 0 B 0 0 B 0 8.5 GiB
.rgw.root 4 1.9 KiB 13 2.2 MiB 0 8.5 GiB
myzone.rgw.log 5 3.4 KiB 207 6 MiB 0.02 8.5 GiB
myzone.rgw.control 6 0 B 8 0 B 0 8.5 GiB
myzone.rgw.meta 7 0 B 0 0 B 0 8.5 GiB
输出中的 RAW STORAGE 段落提供集群用于数据的存储空间容量概览。
CLASS：设备的存储类别。有关设备类型的更多详细信息，请参见第 17.1.1 节 “设备类型”。SIZE：集群的整体存储容量。AVAIL：集群中可以使用的可用空间容量。USED：单纯为块设备中保存的数据对象分配的空间（所有 OSD 上的累计空间）。RAW USED：“USED”空间与块设备上为实现 Ceph 而分配/预留的空间（例如 BlueStore 的 BlueFS 部分）之和。% RAW USED：已用的原始存储量百分比。将此数字与full ratio和near full ratio搭配使用，可确保您不会用完集群的容量。有关其他详细信息，请参见第 12.8 节 “储存容量”。
注意：集群填充程度当原始存储填满级别接近 100% 时，您需要向集群添加新存储空间。较高的用量可能导致单个 OSD 填满，集群健康状况出现问题。
使用命令
ceph osd df tree可列出所有 OSD 的填充程度。
输出内容的 POOLS 段落提供了存储池列表和每个存储池的理论用量。此段落的输出不反映副本、克隆数据或快照。例如，如果您存储含 1MB 数据的对象，理论用量将是 1MB，但是根据副本、克隆数据或快照数量，实际用量可能是 2MB 或更多。
POOL：存储池的名称。ID：存储池 ID。STORED：用户存储的数据量。OBJECTS：每个存储池的理论已存储对象数。USED：所有 OSD 节点单纯为数据分配的空间容量，以 kB 为单位。%USED：每个存储池的理论已用存储百分比。MAX AVAIL：给定存储池中的最大可用空间。
POOLS 段落中的数字是理论上的。它们不包括副本、快照或克隆数量。因此，USED 与 %USED 数量之和不会加总到输出内容 RAW STORAGE 段落中的 RAW USED 和 %RAW USED 数量中。
12.4 检查 OSD 状态 #
可通过执行以下命令来检查 OSD，以确保它们已启动且正在运行：
cephuser@adm > ceph osd stat或
cephuser@adm > ceph osd dump还可以根据 OSD 在 CRUSH 索引中的位置查看 OSD。
ceph osd tree 将列显 CRUSH 树及主机、它的 OSD、OSD 是否已启动及其权重：
cephuser@adm > ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 3 0.02939 root default
-3 3 0.00980 rack mainrack
-2 3 0.00980 host osd-host
0 1 0.00980 osd.0 up 1.00000 1.00000
1 1 0.00980 osd.1 up 1.00000 1.00000
2 1 0.00980 osd.2 up 1.00000 1.0000012.5 检查填满的 OSD #
Ceph 可阻止您向填满的 OSD 写入数据，以防丢失数据。在正常运行的集群中，当集群接近其填满比例时，您会收到警告。mon osd full ratio 默认设为容量的 0.95 (95%)，达到该比例后，集群会阻止客户端写入数据。mon osd nearfull ratio 默认设为容量的 0.85 (85%)，达到该比例时，集群会生成健康状况警告。
可通过 ceph health 命令报告填满的 OSD 节点：
cephuser@adm > ceph health
HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%或
cephuser@adm > 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 变满（即用完 100% 的磁盘空间）之后，往往会迅速崩溃而不发出警告。管理 OSD 节点时需记住下面几点提示。
每个 OSD 的磁盘空间（通常挂载在
/var/lib/ceph/osd/osd-{1,2..}下）需放置在专用的底层磁盘或分区上。检查 Ceph 配置文件，确保 Ceph 不会将其日志文件存储在专供 OSD 使用的磁盘/分区上。
确保没有其他进程写入专供 OSD 使用的磁盘/分区。
12.6 检查 Monitor 状态 #
启动集群后，请在第一次读取和/或写入数据之前检查 Ceph Monitor 的仲裁状态。如果集群已在处理请求，请定期检查 Ceph Monitor 的状态，确保其正在运行。
要显示 Monitor 索引，请执行以下命令：
cephuser@adm > ceph mon stat或
cephuser@adm > ceph mon dump要检查 Monitor 集群的仲裁状态，请执行以下命令：
cephuser@adm > ceph quorum_statusCeph 将返回仲裁状态。例如，由三个 Monitor 组成的 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": "192.168.1.10:6789\/0"},
{ "rank": 1,
"name": "b",
"addr": "192.168.1.11:6789\/0"},
{ "rank": 2,
"name": "c",
"addr": "192.168.1.12:6789\/0"}
]
}
}12.7 检查归置组状态 #
归置组会将对象映射到 OSD。监视归置组时，您希望它们处于 active 和 clean 状态。有关详细内容，请参见第 12.9 节 “监控 OSD 和归置组”。
12.8 储存容量 #
作为防止数据丢失的安全措施，当 Ceph 存储集群接近其容量上限时，Ceph 将阻止您向 Ceph OSD 写入或从中读取数据。因此，让生产集群接近其填满比例不是一种好的做法，因为这样会牺牲高可用性。默认的填满比例设置为 0.95，即容量的 95%。对于所含 OSD 数量较少的测试集群而言，如此设置是非常激进的。
在监视集群时，请注意与 nearfull 比例有关的警告。出现该警告表示，如果一个或多个 OSD 发生故障，某些 OSD 的故障可能会导致服务暂时中断。请考虑添加更多 OSD 以增加存储容量。
测试集群的一种常见情境是系统管理员从 Ceph 存储集群中删除 Ceph OSD，等待集群重新达到平衡。然后再删除另一个 Ceph OSD，以此类推，直到集群最终达到填满比例并锁死。我们建议即使使用测试集群时也进行一定的容量规划。通过规划，您可以预估维持高可用性所需的备用容量。从理论上讲，您需要规划能够应对一系列 Ceph OSD 发生故障的情况的方案，使集群无需立即替换这些 Ceph OSD 也可恢复到 active + clean 状态。您可以运行 active + degraded 状态的集群，但这不适合正常运行状况。
下图展示了一个包含 33 个 Ceph 节点的简化 Ceph 存储集群，其中每个主机有一个 Ceph OSD，每个 Ceph OSD 从 3 TB 驱动器读取以及向其中写入数据。此示例集群实际的容量上限为 99 TB。mon osd full ratio 选项设置为 0.95。如果集群的剩余容量降至 5 TB，集群将不允许客户端读取和写入数据。因此，存储集群的运行容量为 95 TB，而不是 99 TB。
在这样的集群中，有一个或两个 OSD 发生故障属于正常现象。一种不常发生但合乎常理的情况是机柜的路由器或电源发生故障，导致多个 OSD（例如 OSD 7-12）同时停用。在这种情况下，您仍然应该设法使集群保持正常运行并达到 active + clean 状态，即使这意味着需要立即添加一些主机及额外的 OSD。如果容量使用率过高，您可能不会丢失数据。但是，如果集群的容量使用率超过填满比例，您虽然解决了故障域内发生的中断问题，却可能会损失数据可用性。因此，我们建议至少进行大致的容量规划。
针对您的集群确定以下两个数值：
OSD 的数量。
集群的总容量。
如果您将集群的总容量除以集群中的 OSD 数量，将得到集群内单个 OSD 的平均容量。将该数值与您预期正常运行期间将同时发生故障的 OSD 数量（一个相对较小的数值）相乘。最后，将集群容量与填满比例相乘得到运行容量上限。然后，减去您预期将发生故障的 OSD 中的数据量，即可得到一个合理的填满比例。使用更高的 OSD 故障数（一整个机柜的 OSD）重复上述过程，即可得到一个合理的接近填满比例数值。
以下设置仅在创建集群时才会应用，随后会存储在 OSD 索引中：
[global] mon osd full ratio = .80 mon osd backfillfull ratio = .75 mon osd nearfull ratio = .70
仅在创建集群时才会应用这些设置。此后，需要使用 ceph osd set-nearfull-ratio 和 ceph osd set-full-ratio 命令在 OSD 索引中更改这些设置。
- mon osd full ratio
在将 OSD 视为
满之前使用的磁盘空间百分比。默认值为 0.95- mon osd backfillfull ratio
在将 OSD 视为过
满而无法回填之前使用的磁盘空间百分比。默认值为 0.90- mon osd nearfull ratio
在将 OSD 视为
将满之前使用的磁盘空间百分比。默认值为 0.85
如果某些 OSD 将满，但其他 OSD 的容量充足，则表示将满 OSD 的 CRUSH 权重可能有问题。
12.9 监控 OSD 和归置组 #
高可用性和高可靠性要求采用容错方法来管理硬件和软件问题。Ceph 没有单一故障点，可以在“已降级”模式下处理数据请求。Ceph 的数据归置引入了一个间接层，以确保数据不会与特定 OSD 地址直接绑定。这表示跟踪系统故障原因需要找到属于问题根源的归置组和底层 OSD。
如果集群的某个部分发生故障，集群可能会阻止您访问特定对象，但这并不意味着您无法访问其他对象。遇到故障时，请执行相关步骤来监视 OSD 和归置组。然后开始进行查错。
Ceph 一般情况下会进行自我修复。但如果问题仍然存在，监视 OSD 和归置组将有助于您找到问题所在。
12.9.1 监视 OSD #
OSD 可能处于在集群内（“in”）状态，也可能处于在集群外（“out”）状态。同时，它也可能处于启用并运行（“up”）或停用且未运行（“down”）状态。如果某个 OSD 处于“up”状态，则它可能在集群内（您可以读取和写入数据），也可能在集群外。如果该 OSD 之前在集群内，最近已移出集群，则 Ceph 会将归置组迁移到其他 OSD。如果某个 OSD 在集群外，CRUSH 将不会为其指定归置组。如果某个 OSD 处于“down”状态，则它应该也处于“out”状态。
如果某个 OSD 处于“down”和“in”状态，则表示存在问题，并且集群将处于不健康状态。
如果您执行 ceph health、ceph -s 或 ceph -w 等命令，可能会注意到集群并非始终回显 HEALTH OK。对于 OSD，您应当预期集群在以下情况下不会回显 HEALTH OK：
您尚未启动集群（它不会响应）。
您已启动或重启动集群，但它尚未准备就绪，因为系统正在创建归置组，并且 OSD 正在互联。
您已添加或删除某个 OSD。
您已修改集群索引。
监视 OSD 的一个重要目的是确保当集群已启用且在运行时，集群中的所有 OSD 也已启用且在运行。要确定是否所有 OSD 都在运行，请执行以下命令：
# ceph osd stat
x osds: y up, z in; epoch: eNNNN
结果应显示 OSD 总数 (x)、处于“up”状态的 OSD 数量 (y)、处于“in”状态的 OSD 数量 (z)，以及索引版本号 (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例如，如果 ID 为 1 的 OSD 处于停用状态，请将其启动：
cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service有关与已停止或不会重启动的 OSD 相关的问题，请参见Section 4.3, “OSDs not running”。
12.9.2 指定归置组集 #
CRUSH 向 OSD 指定归置组时，会查看存储池的副本数量，然后再为 OSD 指定归置组，以便将每个归置组副本都指定给不同的 OSD。例如，如果存储池需要三个归置组副本，CRUSH 可能会将这三个副本分别指定给 osd.1、osd.2 和 osd.3。CRUSH 实际上会寻找一种伪随机归置方法，这种方法会将您在 CRUSH 索引中设置的故障域纳入考量，因此在大型集群中，您很少会看到归置组被指定给最邻近的 OSD 的情况。我们将应包含特定归置组的副本的 OSD 集称为在任集。在某些情况下，在任集中的 OSD 会处于停用状态，或者无法处理要访问归置组中对象的请求。当以下其中一种情况发生时，可能会出现这些情况：
您添加或删除了某个 OSD。CRUSH 随后会将归置组重新指定给其他 OSD，因而更改了在任集的组成部分，导致系统通过“回填”过程迁移数据。
某个 OSD 之前处于“down”状态、之前进行了重启动，而现在正在恢复。
在任集中的某个 OSD 处于“down”状态，或者无法处理请求，并且另一个 OSD 已暂代其职。
Ceph 使用启用集来处理客户端请求，启用集是实际处理请求的 OSD 集。在大多数情况下，启用集和在任集几乎完全相同。当两者不同时，可能表示 Ceph 正在迁移数据、某个 OSD 正在恢复，或者集群存在问题（例如，在此类情况下，Ceph 通常会回显
HEALTH WARN状态及“stuck stale”消息）。
要检索归置组列表，请运行以下命令：
cephuser@adm > ceph pg dump要查看哪些 OSD 在给定归置组的在任集或启用集内，请运行以下命令：
cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]结果应该会显示 OSD 索引版本号 (eNNN)、归置组数量 (PG_NUM)、启用集（“up”）中的 OSD，以及在任集（“acting”）中的 OSD：
如果启用集与在任集不一致，则可能表示集群正在自我重新平衡，或者集群可能存在问题。
12.9.3 正在互联 #
归置组必须处于 active 及 clean 状态，您才能将数据写入其中。为了让 Ceph 确定某个归置组的当前状态，该归置组的主 OSD（在任集中的第一个 OSD）会与第二个和第三个 OSD 建立互联，以便就归置组的当前状态达成一致（假设存储池包含三个归置组副本）。
12.9.4 监控归置组状态 #
如果您执行 ceph health、ceph -s 或 ceph -w 等命令，可能会注意到集群并非始终回显 HEALTH OK 消息。检查 OSD 是否正在运行之后，还应检查归置组状态。
在一些与归置组互联相关的情况下，集群预期将不会回显 HEALTH OK：
您已创建存储池，并且归置组尚未互联。
归置组正在恢复。
您已向集群添加了 OSD，或已从集群中删除了 OSD。
您已修改 CRUSH 索引，并且您的归置组正在迁移。
在不同的归置组副本中存在数据不一致的情况。
Ceph 正在洗刷归置组的副本。
Ceph 的存储容量不足，无法完成回填操作。
如果上述其中一种情况导致 Ceph 回显 HEALTH WARN，请不要惊慌。集群在许多情况下都会自行恢复。在有些情况下，您可能需要采取措施。监视归置组的一个重要目的是确保当集群已启用并运行时，所有归置组都处于“active”状态并且最好处于“clean”状态。要查看所有归置组的状态，请运行以下命令：
cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail结果应该会显示归置组总数 (x)、处于特定状态（例如“active+clean”）的归置组数量 (y)，以及存储的数据量 (z)。
除了归置组状态以外，Ceph 还会回显使用的存储容量 (aa)、剩余的存储容量 (bb)，以及归置组的总存储容量。在以下情况下，这些数值可能非常重要：
已达到
near full ratio或full ratio。由于您的 CRUSH 配置中存在错误，您的数据未在集群中分布。
归置组 ID 由存储池编号（并非存储池名称）加一个句点 (.)和归置组 ID（一个十六进制数）组成。您可以在 ceph osd lspools 的输出中查看存储池编号及其名称。例如，默认存储池 rbd 与存储池编号 0 对应。完全限定的归置组 ID 的格式如下：
POOL_NUM.PG_ID
通常显示如下：
0.1f
要检索归置组列表，请运行以下命令：
cephuser@adm > ceph pg dump您还可以将输出内容设置为 JSON 格式，并将其保存到文件中：
cephuser@adm > ceph pg dump -o FILE_NAME --format=json要查询特定归置组，请运行以下命令：
cephuser@adm > ceph pg POOL_NUM.PG_ID query以下列表详细说明了常见的归置组状态。
- CREATING（正在创建）
当您创建存储池时，Ceph 会创建您指定数量的归置组。Ceph 会在创建一个或多个归置组时回显“creating”。创建归置组之后，属于归置组在任集的各 OSD 将会互联。完成互联过程时，归置组状态应该为“active+clean”，这表示 Ceph 客户端可以开始向归置组写入数据。
图 12.3︰ 归置组状态 #- PEERING（正在互联）
当 Ceph 在对归置组执行互联操作时，会在存储归置组副本的各 OSD 之间就该归置组中的对象和元数据的状态达成一致。当 Ceph 完成互联过程时，便表示存储归置组的各 OSD 之间就归置组的当前状态达成一致。不过，完成互联过程并不表示每个副本都有最新的内容。
注意：权威历史在在任集的所有 OSD 都持续进行写入操作之前，Ceph 将不会向客户端确认写入操作。这样做可确保在上次成功完成互联操作之后，至少有一个在任集成员将拥有每个确认的写入操作的记录。
通过准确记录每个确认的写入操作，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 变成停用状态，Ceph 会将指定给该 OSD 的每个归置组都标记为“degraded”。当该 OSD 恢复启用状态后，各 OSD 必须再次互联。不过，如果某个已降级归置组处于“active”状态，客户端仍然可以将新对象写入该归置组。
如果某个 OSD 处于“down”状态，并且持续保持“degraded”状况，Ceph 可能会将该停用的 OSD 标记为“out”（表示移出集群），并将停用（“down”）的 OSD 的数据重新映射到另一个 OSD。从将 OSD 标记为“down”到将其标记为“out”相隔的时间通过
mon osd down out interval选项控制，该选项默认设置为 600 秒。归置组也可能处于“degraded”状态，当 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”表示回填操作待处理，但尚未执行；“backfill”表示正在进行回填操作；“backfill_too_full”表示已请求进行回填操作，但由于存储容量不足而无法完成。如果某个归置组无法回填，则可能会被视为“incomplete”。
Ceph 提供了一些设置来管理与向某个 OSD（尤其是新 OSD）重新指定归置组有关的负载。默认情况下，
osd max backfills将向或从一个 OSD 同时进行的最大回填数设置为 10。backfill full ratio允许 OSD 在接近其填满比例（默认为 90%）时拒绝回填请求，并使用ceph osd set-backfillfull-ratio命令进行更改。如果某个 OSD 拒绝回填请求，osd backfill retry interval可让 OSD 重试请求（默认在 10 秒后）。OSD 还可以设置osd backfill scan min和osd backfill scan max，以管理扫描间隔（默认值分别为 64 和 512）。- REMAPPED（已重新映射）
当用于处理归置组的在任集发生变化时，数据会从旧在任集迁移到新在任集。新主 OSD 可能需要一段时间才能处理请求。因此，新主 OSD 可能会要求旧主 OSD 继续处理请求，直到归置组迁移完成。数据迁移完成时，映射将使用新在任集的主 OSD。
- STALE（过时）
尽管 Ceph 使用检测信号来确保主机和守护进程正在运行，但
ceph-osd守护进程也可能会卡住，无法及时报告统计数据（例如，当发生暂时的网络故障时）。默认情况下，OSD 守护进程每半秒钟 (0.5) 报告一次其归置组、引导及故障统计数据，这个频率高于检测信号阈值。如果某个归置组在任集的主 OSD 未能向 Monitor 报告，或者其他 OSD 已将该主 OSD 报告为“down”，则 Monitor 会将该归置组标记为“stale”。当您启动集群后，集群常常会在互联过程完成之前显示为“stale”状态。集群运行一段时间之后，如果归置组显示为“stale”状态，则表示这些归置组的主 OSD 处于停用状态，或者未向 Monitor 报告归置组统计数据。
12.9.5 查找对象位置 #
要在 Ceph 对象存储中存储对象数据，Ceph 客户端需要设置对象名称并指定相关的存储池。Ceph 客户端会检索最新的集群索引，并且 CRUSH 算法会计算如何将对象映射到归置组，然后计算如何以动态方式将该归置组指定给 OSD。要查找对象位置，您只需知道对象名称和存储池名称。例如：
cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]
作为示范，我们来创建一个对象。在命令行上使用 rados put 命令指定对象名称“test-object-1”、包含一些对象数据的示例文件“testfile.txt”的路径，以及存储池名称“data”。
cephuser@adm > rados put test-object-1 testfile.txt --pool=data要确认 Ceph 对象存储是否已存储对象，请运行以下命令：
cephuser@adm > rados -p data ls现在，我们来确定对象位置。Ceph 将会输出对象的位置：
cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)
要移除示例对象，只需使用 rados rm 命令将其删除：
cephuser@adm > rados rm test-object-1 --pool=data