Akemi

MGR进行集群监控和维护

2025/07/14

概念介绍

  • MGR至少两个，以提供高可用性
    第一个MGR被认为是active的，其他为备用MGR

主MGR会周期发送信标，默认超时时间30s，修改mon_mgr_beacon_grace参数来调整

1
2
3
4
5
6
7
ceph mgr stat
{
    "epoch": 37,
    "available": true,
    "active_name": "cephadm-3.zwfiyn",
    "num_standby": 3
}
  • MGR是模块化架构
    可以根据需求启用或禁用模块
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
查看可用和启用的模块
ceph mgr module ls
MODULE
balancer           on (always on)
crash              on (always on)
devicehealth       on (always on)
orchestrator       on (always on)
pg_autoscaler      on (always on)
progress           on (always on)
rbd_support        on (always on)
status             on (always on)
telemetry          on (always on)
volumes            on (always on)
cephadm            on
dashboard          on
iostat             on
nfs                on
prometheus         on
restful            on
alerts             -
influx             -
insights           -
k8sevents          -
localpool          -
mds_autoscaler     -
mirroring          -
osd_perf_query     -
osd_support        -
rgw                -
rook               -
selftest           -
snap_schedule      -
stats              -
telegraf           -
test_orchestrator  -
zabbix             -

查看已发布地址
ceph mgr services
{
    "dashboard": "https://192.168.10.143:8443/",
    "prometheus": "http://192.168.10.143:9283/"
}

其中dashboard是默认开启的

健康检查命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
快速返回集群状态是否正常
ceph health
HEALTH_OK
HEALTH_WARN
HEALTH_ERR

如果处于错误或警告状态，获取更多信息
ceph health detail

实时监控
ceph -w

查看集群日志
ceph log last [<num:int>] [<level:debug|info|sec|warn|error>] [<channel:*|cluster|audit|cephadm>]

可以查看多种等级和服务的日志
ceph log last audit
2025-07-10T10:32:16.744351+0000 mon.cephadm-3 (mon.0) 292692 : audit [INF] from='mgr.14200 192.168.10.143:0/3306424811' entity='mgr.cephadm-3.zwfiyn'
2025-07-10T10:32:17.997508+0000 mon.cephadm-3 (mon.0) 292693 : audit [INF] from='mgr.14200 192.168.10.143:0/3306424811' entity='mgr.cephadm-3.zwfiyn'

管理Ceph服务

集群守护进程由$daemon类型和守护进程$id指定

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
$daemon的类型有mon, mgr, mds, osd, rgw, rdb-mirror，crash，ceph-mirror

MON，MGR，RGW的$id是主机名
OSD的$id就是OSD的ID               比如0~23
MDS的$id是文件系统名后跟主机名     比如cephfs.node05

列出所有集群守护进程
ceph orch ps

使用--daemon_type=DAEMON选筛选特定守护进程
ceph orch ps --daemon_type=osd
NAME   HOST       PORTS  STATUS         REFRESHED  AGE  MEM USE  MEM LIM  VERSION  IMAGE ID      CONTAINER ID
osd.0  cephadm-3         running (13d)   118s ago  13d     649M    4096M  17.2.8   259b35566514  1f95dbaebbee
osd.1  cephadm-3         running (13d)   118s ago  13d     719M    4096M  17.2.8   259b35566514  362323dddb54
osd.2  cephadm-3         running (13d)   118s ago  13d     692M    4096M  17.2.8   259b35566514  3b0b783bb7de
osd.3  cephadm-2         running (13d)   117s ago  13d     618M    4096M  17.2.8   259b35566514  b264677293a3
osd.4  cephadm-1         running (13d)   118s ago  13d     599M    4096M  17.2.8   259b35566514  bcc1be4e4d72
osd.5  cephadm-2         running (13d)   117s ago  13d     717M    4096M  17.2.8   259b35566514  7bb8614175a4
osd.6  cephadm-1         running (13d)   118s ago  13d     602M    4096M  17.2.8   259b35566514  4defe8190a41
osd.7  cephadm-2         running (13d)   117s ago  13d     722M    4096M  17.2.8   259b35566514  13b444da41b6
osd.8  cephadm-1         running (13d)   118s ago  13d     879M    4096M  17.2.8   259b35566514  746950dd7060

使用systemctl重启ceph进程
直接在主机上使用systemctl管理：
systemctl list-units 'ceph*'
UNIT                                                LOAD   ACTIVE SUB     DESCRIPTION
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@crash.cephadm-1.service loaded active running Ceph crash.>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@iscsi.iscsi.cephadm-1.spcmkp.service loaded active runnin>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@mds.ws-cephfs.cephadm-1.cvcevd.service loaded active runn>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@mgr.cephadm-1.cedioe.service loaded active running Ceph m>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@mon.cephadm-1.service loaded active running Ceph mon.ceph>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@nfs.cephfs-nfs.0.0.cephadm-1.tbqbkw.service loaded active>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@node-exporter.cephadm-1.service loaded active running Cep>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@osd.4.service loaded active running Ceph osd.4 for 8b2788>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@osd.6.service loaded active running Ceph osd.6 for 8b2788>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@osd.8.service loaded active running Ceph osd.8 for 8b2788>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@rgw.realm.zone.cephadm-1.caxyqu.service loaded active run>
ceph-8b27889e-52af-11f0-bedb-bc2411f9a113.target    loaded active active  Ceph cluster 8b27889e-52a>
ceph.target                                         loaded active active  All Ceph clusters and ser>

systemctl restart ceph.target

使用ceph orch重启ceph进程
orch ls
NAME                     PORTS        RUNNING  REFRESHED  AGE  PLACEMENT
alertmanager             ?:9093,9094      1/1  8m ago     2w   count:1
crash                                     4/4  8m ago     2w   *
grafana                  ?:3000           1/1  8m ago     2w   count:1
iscsi.iscsi              ?:5000           3/3  6m ago     20h  cephadm-1;cephadm-2;cephadm-3
mds.ws-cephfs                             3/3  6m ago     15h  cephadm-1;cephadm-2;cephadm-3
mgr                                       4/4  8m ago     20h  ansible;cephadm-1;cephadm-2;cephadm-3
mon                                       3/3  6m ago     20h  cephadm-1;cephadm-2;cephadm-3
nfs.cephfs-nfs           ?:2049           3/3  6m ago     22h  cephadm-1;cephadm-2;cephadm-3
node-exporter            ?:9100           4/4  8m ago     2w   *
osd.default_drive_group                     9  6m ago     20h  count:3;label:ssd-node;cephadm-*
prometheus               ?:9095           1/1  8m ago     2w   count:1
rgw.realm.zone           ?:8080           4/4  6m ago     20h  cephadm-1;cephadm-2;cephadm-3;count:4

重启某个服务的所有进程
ceph orch restart alertmanager

重启某个服务的单个进程
ceph orch daemon restart osd.1

集群重启

优雅重启集群，ceph通过tag来控制集群行为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
标签	
noup	     阻止OSD从down状态自动恢复为up状态
           一般OSD如果网络延时，会互相打这tag
nodown	   阻止 OSD 被标记为 down 状态（即使实际已宕机）
noout	     阻止OSD被自动标记为out（防止OSD被踢出集群）
					 防止CRUSH在osd停止时自动重新平衡集群
noin	     阻止新 OSD 自动加入集群
norecover	 禁止数据恢复操作
nobackfill	禁止数据回填操作，数据丢失后按位进行数据恢复
norebalance 阻止重新平衡操作的运行
noscrub	   禁止普通数据校验（scrub）
nodeep-scrub	禁止深度数据校验（deep-scrub）

集群关闭
执行以下步骤关闭整个集群。
1.禁止客户端访问集群。
2.在继续之前，请确保集群处于正常状态(HEALTH_OK)，并且所有pg都处于活动+clean状态。
3.关闭cephfs。
4.设置noout, norecover, norebalance, nobackfill, nodown和pause标志。
5.关闭所有RGW (Ceph Object gateway)和iSCSI gateway。
6.逐个关闭OSD。
7.逐个关闭MON节点和MGR节点
8.关闭admin节点。

集群启动
集群上电的操作步骤如下:
1.集群节点依次上电:admin节点、MON节点和MGR节点、OSD节点、MDS节点。
2.清除noout, norecover, norebalance, nobackfill, nodown和pause标志。
3.打开Ceph对象网关和iSCSI网关。
4.打开cephfs。

ceph集群监控

1
2
3
4
5
6
ceph mon stat
ceph quorum_status -f json-pretty

查看服务日志
journalctl -u ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@osd.1.service
journalctl -u ceph-8b27889e-52af-11f0-bedb-bc2411f9a113@mgr.ansible.ovfsfi.service

OSD状态监控

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
1.osd当前状态
2.OSD容量限制信息
3.pg状态

查看空间相关的告警信息
ceph health
ceph status

查看容量信息
ceph osd df
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA     OMAP    META     AVAIL    %USE  VAR   PGS  STATUS
 4    hdd  0.05859   1.00000   60 GiB  1.3 GiB  452 MiB   1 KiB  873 MiB   59 GiB  2.16  1.04  130      up
 6    hdd  0.05859   1.00000   60 GiB  1.3 GiB  419 MiB   1 KiB  885 MiB   59 GiB  2.12  1.03  117      up
 8    hdd  0.05859   1.00000   60 GiB  1.5 GiB  380 MiB   1 KiB  1.1 GiB   58 GiB  2.52  1.22  122      up
 3    hdd  0.05859   1.00000   60 GiB  1.1 GiB  270 MiB   1 KiB  871 MiB   59 GiB  1.86  0.90  129      up
 5    hdd  0.05859   1.00000   60 GiB  1.4 GiB  553 MiB   1 KiB  890 MiB   59 GiB  2.35  1.14  129      up
 7    hdd  0.05859   1.00000   60 GiB  1.3 GiB  428 MiB   1 KiB  891 MiB   59 GiB  2.15  1.04  111      up
 0    hdd  0.05859   1.00000   60 GiB  1.2 GiB  328 MiB   1 KiB  881 MiB   59 GiB  1.97  0.95  125      up
 1    hdd  0.05859   1.00000   60 GiB  796 MiB  451 MiB  13 KiB  345 MiB   59 GiB  1.30  0.63  132      up
 2    hdd  0.05859   1.00000   60 GiB  1.3 GiB  472 MiB   1 KiB  871 MiB   59 GiB  2.19  1.06  112      up
                       TOTAL  540 GiB   11 GiB  3.7 GiB  27 KiB  7.5 GiB  529 GiB  2.07             
MIN/MAX VAR: 0.63/1.22  STDDEV: 0.33

查看osd读写延迟
ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
  8                   4                  4
  7                   4                  4
  6                   4                  4
  5                   4                  4
  4                   0                  0
  3                   3                  3
  2                   5                  5
  1                   0                  0
  0                   4                  4

ceph status
...
    osd:         9 osds: 9 up (since 2d), 9 in (since 2w)
...
down或up: 表示osd能否与mon通信
out或in: 表示osd是否参与集群数据放置
osd正常运行就是up+in

短暂的网络中断，可能会导致osd报告为down，在一段时间之后
集群会报告其down+out，失败的osd上的PG会被迁移到其他OSD上

如果osd恢复到up状态，并且是in状态，集群会根据新OSD重新分配PG
并重新平衡集群中的对象

相关参数：
osd_heartbeat_interval
osd_heartbeat_grace
mon_osd_min_down_reporters
mon_osd_min_down_reports
mon_osd_down_out_subtree_limit
osd_mon_report_interval_min
osd_mon_report_interval_max
参数名称 默认值 含义解释 作用与影响
osd_heartbeat_interval 6 秒 OSD 之间发送心跳包的间隔时间 控制 OSD 节点间的健康检测频率。值越小故障检测越快，但会增加网络负载
osd_heartbeat_grace 20 秒 等待心跳响应的超时时间 超过此时限未收到响应会将 OSD 标记为 down。需大于 osd_heartbeat_interval
mon_osd_min_down_reporters 1 最少需要多少个报告者 要求至少有多少个 OSD 报告某个 OSD 故障，MON 才将其标记为 down
mon_osd_min_down_reports 1 最少需要多少次报告 要求某个 OSD 被报告多少次故障，MON 才将其标记为 down
mon_osd_down_out_subtree_limit root 自动标记为 out 的故障域限制 控制当 OSD 宕机时，在哪个层级（如 host/rack）自动标记为 out 并触发数据迁移
osd_mon_report_interval_min 5 秒 向 MON 报告状态的最小间隔 OSD 向 Monitor 报告状态的最小时间间隔（实际间隔在此值和最大值之间随机）
osd_mon_report_interval_max 20 秒 向 MON 报告状态的最大间隔 OSD 向 Monitor 报告状态的最大时间间隔，增大可减轻 MON 负载但会延迟状态更新

OSD容量监控

ceph提供了一些参数，防止由于集群中存储空间不足而导致的数据丢失

1
2
3
4
5
6
7
8
9
10
ceph osd set-nearfull-ratio
ceph osd set-backfillfull-ratio
ceph osd set-full-ratio
可以分别设置参数
mon_osd_nearfull_ratio
mon_osd_backfillfull_ratio
mon_osd_full_ratio

默认比率设置适用于小型集群
生产集群通常需要更低的比率
对应参数 默认值 作用 触发后果
mon_osd_nearfull_ratio 0.85 (85%) 设置空间接近满载的警戒线 1. 集群状态变为 HEALTH_WARN
2. 产生 OSD_NEARFULL 警告
3. 新写入仍被允许
mon_osd_backfillfull_ratio 0.90 (90%) 设置影响数据平衡操作的警戒线 1. 停止数据回填(backfill)操作2. 停止PG重平衡(recovery)3. 客户端写入仍可继续
mon_osd_full_ratio 0.95 (95%) 设置完全满载的封锁线 1. 集群状态变为 HEALTH_ERR2. 阻塞所有客户端写入
3. 返回 ENOSPC 错误

监控PG

每个PG都有一个状态字符串，指示其运行状况，所有PG都处于active+clean的时候，集群处于正常状态

PG清洗scrubbing
PG深度清洗deep-scrubbing

PG清洗是一个后台进程，通过比较对象的大小和其他元数据与其在其他osd上的副本并报告不一致来验证数据一致性
深度清洗是一个资源密集型过程，它通过使用位比较来比较数据对象的内容，并重新计算校验和以识别驱动器上的坏扇区，所以建议错峰清洗

当一个新OSD加入PG时，PG进入peering状态，对等完成后PG就可以处理读写请求

当一个对象被写入PG的主OSD时，PG会报告degraded降级状态，知道所有副本OSD都确认写入了该对象

卡住的PG（stuck）

PG在失败后转换到降级或对等状态，如果长时间处于这种状态，MON将PG标记为卡住stuck

这种状态下pg将不可访问，且pg访问被挂起，必须有一个osd被唤醒，以有一个pg副本可用并开始pg恢复

默认情况下ceph将自动恢复，如果有pg恢复失败，会继续显示HEALTH_ERR

卡住可能的原因：
1.unactive的PG可能存在对等问题
2.unclean的PG在失败后恢复有问题
3.stale陈旧的，PG没有osd报告
4.undersized过小的，PG没有足够的osd来存储配置的副本数量

mon使用mon_pg_stuck_threshold参数来判断PG是否处于错误太长时间，默认300秒

常见PG状态
健康状态：active+clean
恢复中状态：active+recovering+undersized+degraded
数据迁移状态：active+remapped+backfilling
严重问题：stale+inconsistent

状态字符串 含义 是否正常 处理建议
active PG 处于活跃状态，可处理读写请求 正常 -
clean 所有对象都已正确复制且无不一致 正常 -
peering PG 正在建立 OSD 间的元数据一致性 临时 通常短暂出现
degraded 部分对象副本缺失（未达到完整副本数） 警告 检查 OSD 状态
recovering 正在恢复丢失的副本 临时 等待恢复完成
backfilling 正在进行全量数据迁移（如 OSD 增减） 临时 避免同时操作多个 OSD
remapped PG 的 Acting Set 已变更但数据迁移未完成 临时 通常伴随 backfilling
stale 主 OSD 未及时报告状态（>300 秒） 错误 检查主 OSD 是否宕机
undersized 当前副本数少于预期 警告 检查 OSD 状态
scrubbing 正在进行数据校验（轻量级） 临时 -
deep 正在进行深度数据校验 临时 可能影响性能
inconsistent 副本间数据不一致（scrub 发现） 错误 需手动修复
repair 正在修复不一致对象 临时 自动修复过程
snaptrim 正在修剪快照占用的空间 临时 -
incomplete Peering 失败，无法确定权威日志 错误 需人工干预
backfill_too_full 请求进行回填操作，但容量不足无法完成 错误

声明丢失

Ceph可以声明osd或PG丢失，这可能导致数据丢失。当该 OSD 上的数据有其他完整副本时才安全

要确定受影响的osd，首先使用ceph health detail命令检索集群状态的概述。然后使用ceph pg dump_stuck option命令检查pg的状态。

ceph osd lost <osd-id> [--yes-i-really-mean-it]

作用 说明 使用场景
强制移除故障 OSD 当 OSD 无法自动恢复时，手动将其标记为永久丢失 OSD 硬件损坏且无法修复
重置集群状态 清除 MON 中关于该 OSD 的等待状态 OSD 处于 down 状态超过 30 分钟
释放 PG 关联 解除 PG 与该 OSD 的映射关系 避免 PG 卡在 stale 或 incomplete 状态
触发数据重建 强制集群从其他副本恢复数据 当副本数不足导致 PG 处于 undersized+degraded

原文作者：王盛

原文链接：https://akemi.zj.cn/2025/07/14/Ceph-MGR/

发表日期：July 14th 2025, 7:25:45 pm

更新日期：July 14th 2025, 7:26:01 pm

版权声明：本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可

CATALOG
  1. 1. 概念介绍
  2. 2. 健康检查命令
  3. 3. 管理Ceph服务
  4. 4. 集群重启
  5. 5. ceph集群监控
    1. 5.1. OSD状态监控
    2. 5.2. OSD容量监控
    3. 5.3. 监控PG
Total : 246
2025
2024
2023
Linux 云原生 云计算 开发 mysql