OSD故障处理总结
在定位OSD故障之前，首先检查MON和网络。执行ceph health或ceph -s命令，如果发现MON有报错，应当去MON上定位问题。其次检查网络是否正常运行，因为OSD的性能极大程度地受到网络影响。在主机端检查丢包，在交换机端检查CRC错误。
获取OSDs的数据信息
要查看是否所有的OSDs都健康运行，请执行：
$ ceph osd stat
# 4个OSD，全部up，为健康状态
[root@node-1 ~]# ceph osd stat
4 osds: 4 up (since 12m), 4 in (since 3d); epoch: e6835发现up和in状态的OSD数量和总数不匹配，可进一步执行下列命令列出所有OSD状态。
$ ceph osd tree
[root@node-1 ~]# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.03918 root default
-3 0.01959 host node-1
0 hdd 0.00980 osd.0 up 1.00000 1.00000
3 hdd 0.00980 osd.3 up 0.09999 1.00000
-5 0.00980 host node-2
1 hdd 0.00980 osd.1 up 1.00000 1.00000
-7 0.00980 host node-3
2 hdd 0.00980 osd.2 up 1.00000 1.00000如果存在OSD状态为down，说明可能是OSD进程挂了，尝试下列命令来启动进程。
systemctl restart ceph-osd@1Ceph logs
如果没有特别修改的话，Ceph log 的默认路径为/var/log/ceph。
OSD的log也在此目录下。
[root@node-1 ~]# ls /var/log/ceph/
ceph.audit.log ceph-mon.0.log
ceph-client.admin.log ceph-client.foonew.log
ceph.log ceph-mon.1.log
ceph-mon.2.log ceph-mon.node-1.log
ceph-mds.10.log ceph-mds.1.log
ceph-mds.3.log ceph-mon.q.log
ceph-mds.cepfs10.log ceph-osd.0.log
ceph-mds.cephfs.log ceph-osd.3.log
ceph-mds.mds1.log ceph-volume.log
ceph-mds.mds2.log ceph-volume-systemd.log
ceph-mds.node-1.log ceph-mgr.node-1.log可以使用下列命令，将OSD日志输出级别调高，方便在日志文件中看到更加详细的日志信息。
ceph daemon osd.0 config set debug_osd 20/20admin socket
使用admin socket获取运行时信息。查看Ceph守护进程的所有sockets：
$ ls /var/run/ceph
[root@node-1 ~]# ls /var/run/ceph
ceph-mds.cephfs.asok ceph-mds.mds2.asok ceph-mon.node-1.asok ceph-osd.3.asok
ceph-mds.mds1.asok ceph-mgr.node-1.asok ceph-osd.0.asok查看守护进程的sockets支持哪些命令及其用途：
$ ceph daemon {deamon-name/socket-file} help
[root@node-1 ~]# ceph daemon osd.0 help
{
"bluefs debug_inject_read_zeros": "Injects 8K zeros into next BlueFS read. Debug only.",
"bluestore allocator dump block": "dump allocator free regions",
"bluestore allocator dump bluefs-db": "dump allocator free regions",
"bluestore allocator fragmentation block": "give allocator fragmentation (0-no fragmentation, 1-absolute fragmentation)",
"bluestore allocator fragmentation bluefs-db": "give allocator fragmentation (0-no fragmentation, 1-absolute fragmentation)",
"bluestore allocator score block": "give score on allocator fragmentation (0-no fragmentation, 1-absolute fragmentation)",
"bluestore allocator score bluefs-db": "give score on allocator fragmentation (0-no fragmentation, 1-absolute fragmentation)",
"bluestore bluefs available": "Report available space for bluefs. If alloc_size set, make simulation.",
"bluestore bluefs stats": "Dump internal statistics for bluefs.",
"calc_objectstore_db_histogram": "Generate key value histogram of kvdb(rocksdb) which used by bluestore",
"compact": "Commpact object store's omap. WARNING: Compaction probably slows your requests",
"config diff": "dump diff of current config and default config",
"config diff get": "dump diff get <field>: dump diff of current and default config setting <field>",
"config get": "config get <field>: get the config value",
"config help": "get config setting schema and descriptions",
"config set": "config set <field> <val> [<val> ...]: set a config variable",
"config show": "dump current config settings",
"config unset": "config unset <field>: unset a config variable",
"dump_blacklist": "dump blacklisted clients and times",
"dump_blocked_ops": "show the blocked ops currently in flight",
"dump_historic_ops": "show recent ops",
"dump_historic_ops_by_duration": "show slowest recent ops, sorted by duration",
"dump_historic_slow_ops": "show slowest recent ops",
"dump_mempools": "get mempool stats",
"dump_objectstore_kv_stats": "print statistics of kvdb which used by bluestore",
"dump_op_pq_state": "dump op priority queue state",
"dump_ops_in_flight": "show the ops currently in flight",
"dump_osd_network": "Dump osd heartbeat network ping times",
"dump_pgstate_history": "show recent state history",
"dump_recovery_reservations": "show recovery reservations",
"dump_scrub_reservations": "show scrub reservations",
"dump_scrubs": "print scheduled scrubs",
"dump_watchers": "show clients which have active watches, and on which objects",
"flush_journal": "flush the journal to permanent store",
"flush_store_cache": "Flush bluestore internal cache",
"get_command_descriptions": "list available commands",
"get_heap_property": "get malloc extension heap property",
"get_latest_osdmap": "force osd to update the latest map from the mon",
"get_mapped_pools": "dump pools whose PG(s) are mapped to this OSD.",
"getomap": "output entire object map",
"git_version": "get git sha1",
"heap": "show heap usage info (available only if compiled with tcmalloc)",
"help": "list available commands",
"injectdataerr": "inject data error to an object",
"injectfull": "Inject a full disk (optional count times)",
"injectmdataerr": "inject metadata error to an object",
"list_devices": "list OSD devices.",
"log dump": "dump recent log entries to log file",
"log flush": "flush log entries to log file",
"log reopen": "reopen log file",
"objecter_requests": "show in-progress osd requests",
"ops": "show the ops currently in flight",
"perf dump": "dump perfcounters value",
"perf histogram dump": "dump perf histogram values",
"perf histogram schema": "dump perf histogram schema",
"perf reset": "perf reset <name>: perf reset all or one perfcounter name",
"perf schema": "dump perfcounters schema",
"rmomapkey": "remove omap key",
"send_beacon": "send OSD beacon to mon immediately",
"set_heap_property": "update malloc extension heap property",
"set_recovery_delay": "Delay osd recovery by specified seconds",
"setomapheader": "set omap header",
"setomapval": "set omap key",
"smart": "probe OSD devices for SMART data.",
"status": "high-level status of OSD",
"trigger_deep_scrub": "Trigger a scheduled deep scrub ",
"trigger_scrub": "Trigger a scheduled scrub ",
"truncobj": "truncate object to length",
"version": "get ceph version"
}admin socket支持以下功能：
- 列出运行时参数
- 查询历史操作
- 查询操作优先级队列状态
- 查询正在执行的操作
- 查询性能计数器（perfcounters）
文件系统空间情况
可能会出现文件系统问题。要显示文件系统的空闲空间，请执行df。
$ df
[root@node-1 ~]# df
文件系统 1K-块 已用 可用 已用% 挂载点
devtmpfs 919648 0 919648 0% /dev
tmpfs 931496 0 931496 0% /dev/shm
tmpfs 931496 9764 921732 2% /run
tmpfs 931496 0 931496 0% /sys/fs/cgroup
/dev/mapper/centos-root 17811456 5349436 12462020 31% /
/dev/sda1 1038336 198212 840124 20% /boot
tmpfs 931496 24 931472 1% /var/lib/ceph/osd/ceph-3
tmpfs 931496 24 931472 1% /var/lib/ceph/osd/ceph-0
tmpfs 186300 0 186300 0% /run/user/0iostat/iotop
可以用iostat和iotop检测磁盘io情况。
# 安装
yum install sysstat iotop
# 运行示例
[root@node-1 ~]# iostat -x
Linux 3.10.0-1160.41.1.el7.x86_64 (node-1) 2021年10月22日 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.51 0.00 0.82 1.16 0.00 97.52
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.05 0.96 4.46 40.22 206.47 91.00 0.03 5.64 27.82 0.88 2.35 1.27
sdb 0.01 2.90 0.30 1.13 41.12 16.13 80.07 0.03 17.61 82.55 0.26 5.38 0.77
sdc 0.00 0.21 0.04 0.10 5.59 1.21 102.39 0.00 17.36 61.05 0.66 6.26 0.08
scd0 0.00 0.00 0.00 0.00 0.10 0.00 114.22 0.00 1.50 1.50 0.00 1.22 0.00
dm-0 0.00 0.00 0.82 4.51 37.04 206.26 91.22 0.03 5.48 30.84 0.87 2.33 1.24
dm-1 0.00 0.00 0.01 0.00 0.21 0.00 46.58 0.00 4.79 5.09 1.50 3.70 0.00
dm-2 0.00 0.00 0.03 0.30 5.45 1.21 39.81 0.01 15.14 73.45 8.89 2.40 0.08
dm-3 0.00 0.00 0.31 4.03 40.98 16.13 26.33 0.03 6.95 91.56 0.54 1.77 0.77诊断消息
使用dmesg查看内核诊断消息。
[root@node-1 ~]# dmesg | grep scsi
[ 1.985139] scsi host0: ioc0: LSI53C1030 B0, FwRev=01032920h, Ports=1, MaxQ=128, IRQ=17
[ 2.074964] scsi 0:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2
...停止OSD服务
如果是短时间停止某个OSD，来进行一些维护或者修复操作，可以设置noout标志，来禁止CRUSH把它踢出出OSD map。
# 设置所有 OSD 为 no out
$ ceph osd set noout
# 停止OSD服务
$ systemctl stop ceph-osd@{id}
# 重启OSD服务
systemctl restart ceph-osd@{id}OSD无法运行
在正常情况下，只需重新启动ceph-osd守护进程，它就可以重新加入集群并恢复。
OSD不启动
如果启动集群时，发现无法启动OSD，首先检查以下配置：
- 配置文件：检查配置文件是否合理，如host等。
- 检查路径：检查配置中的路径，以及数据和元数据(期刊、WAL、DB)的实际路径本身。如果将OSD数据与元数据分离，配置文件错误或实际挂载错误，可能会导致OSD启动失败。如果希望将元数据存储在单独的块设备上，则应该对驱动器进行分区或LVM，并为每个OSD分配一个分区。
- 检查最大线程数：如果您的节点有很多osd，您可能会达到默认的最大线程数(例如，通常是32k)，特别是在恢复期间。您可以使用sysctl增加线程数，以查看将最大线程数增加到允许的最大可能线程数(即4194303)是否有帮助。例如：
sysctl -w kernel.pid_max=4194303如果增加最大线程数可以解决这个问题，那么可以在内核配置中固化该设置。
# 在 /etc/sysctl.d 目录下的文件中，加入以下配置
# 或者直接在 /etc/sysctl.conf 文件中，加入以下配置
kernel.pid_max = 4194303- 检查“nf_conntrack”
- kernel 版本：检查内核版本是否符合Ceph的要求。
- 段错误：把段错误日志和配置文件发送给https://tracker.ceph/com/projects/ceph 。
OSD失败
当一个ceph-osd进程死亡时，幸存的ceph-osd守护进程将向mons报告该进程已关闭，后者将通过ceph health命令显示新的状态：
$ ceph health
HEALTH_WARN 1/3 in osds are down可以进一步查看错误详细信息：
ceph health detail
HEALTH_WARN 1/3 in osds are down
osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080或者，通过ceph osd tree down查看down OSD。
[root@node-1 ~]# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.03918 root default
-3 0.01959 host node-1
0 hdd 0.00980 osd.0 up 1.00000 1.00000
3 hdd 0.00980 osd.3 up 0.09999 1.00000
-5 0.00980 host node-2
1 hdd 0.00980 osd.1 up 1.00000 1.00000
-7 0.00980 host node-3
2 hdd 0.00980 osd.2 up 1.00000 1.00000无可用的驱动器空间
mon osd full ratio默认为0.95，它表示OSD达到95%空间使用率后便不准再往里写数据。mon osd backfillfull ratio默认为0.90，它表示OSD达到90%空间使用率后，无法进行backfill操作。mon osd nearfull ratio默认为0.85，OSD空间使用率达到85%后，集群会产生一个健康警告，提醒OSD快满了。
可以使用以下命令调整，查看：
# 调整
ceph osd set-nearfull-ratio <float[0.0-1.0]>
ceph osd set-full-ratio <float[0.0-1.0]>
ceph osd set-backfillfull-ratio <float[0.0-1.0]>
# 查看
[root@node-1 ~]# ceph osd dump
...
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.9
...可使用以下命令查看OSD空间使用情况：
[root@node-1 ~]# ceph osd df
ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS
0 hdd 0.00980 1.00000 10 GiB 4.8 GiB 3.8 GiB 20 MiB 1004 MiB 5.2 GiB 47.63 1.21 440 up
3 hdd 0.00980 0.09999 10 GiB 1.2 GiB 194 MiB 1.5 MiB 1022 MiB 8.8 GiB 12.09 0.31 24 up
1 hdd 0.00980 1.00000 10 GiB 4.9 GiB 3.9 GiB 22 MiB 1002 MiB 5.1 GiB 48.89 1.24 464 up
2 hdd 0.00980 1.00000 10 GiB 4.9 GiB 3.9 GiB 22 MiB 1002 MiB 5.1 GiB 48.89 1.24 464 up
TOTAL 40 GiB 16 GiB 12 GiB 66 MiB 3.9 GiB 24 GiB 39.37
MIN/MAX VAR: 0.31/1.24 STDDEV: 10.22
# 查看所有存储池和设备使用情况
[root@node-1 ~]# ceph df
RAW STORAGE:
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 40 GiB 24 GiB 12 GiB 16 GiB 39.37
TOTAL 40 GiB 24 GiB 12 GiB 16 GiB 39.37
POOLS:
POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL
pool-1 1 128 376 MiB 98 1.1 GiB 5.64 6.1 GiB
rbd-pool 2 64 22 MiB 17 67 MiB 0.35 6.1 GiB
cephfs.cephfs.meta 9 16 215 MiB 886 607 MiB 3.11 6.1 GiB
cephfs.cephfs.data 10 64 206 MiB 52.81k 9.7 GiB 34.40 6.1 GiB
cephfs.cephfs2.data 13 64 0 B 0 0 B 0 6.1 GiB
.rgw.root 14 32 1.2 KiB 4 768 KiB 0 6.1 GiB
default.rgw.control 15 32 0 B 8 0 B 0 6.1 GiB
default.rgw.meta 16 32 0 B 0 0 B 0 6.1 GiB
default.rgw.log 17 32 0 B 175 0 B 0 6.1 GiB如果OSD快满了，可以选择删除数据，或者添加OSD。
参考链接：当磁盘容量接近或者超过 mon_osd_full_ratio 时，该怎么去扩容？
OSD 慢或者无响应
常见的问题包括osd响应缓慢或无响应。在深入研究OSD性能问题之前，确保排除了其他故障排除的可能性。例如，确保您的网络正常工作，osd正在运行。检查osd是否正在对恢复流量进行节流。
网络问题
检查Ceph组件是否正常监听或者链接端口。
[root@node-1 ~]# netstat -a | grep ceph
unix 2 [ ACC ] STREAM LISTENING 22789 /var/run/ceph/ceph-mon.node-1.asok
unix 2 [ ACC ] STREAM LISTENING 24102 /var/run/ceph/ceph-mgr.node-1.asok
unix 2 [ ACC ] STREAM LISTENING 24107 /var/run/ceph/ceph-mds.mds2.asok
unix 2 [ ACC ] STREAM LISTENING 23650 /var/run/ceph/ceph-mds.mds1.asok
unix 2 [ ACC ] STREAM LISTENING 25567 /var/run/ceph/ceph-osd.3.asok
unix 2 [ ACC ] STREAM LISTENING 25570 /var/run/ceph/ceph-osd.0.asok
unix 2 [ ACC ] STREAM LISTENING 23548 /var/run/ceph/ceph-mds.cephfs.asok
[root@node-1 ~]# netstat -l | grep ceph
unix 2 [ ACC ] STREAM LISTENING 22789 /var/run/ceph/ceph-mon.node-1.asok
unix 2 [ ACC ] STREAM LISTENING 24102 /var/run/ceph/ceph-mgr.node-1.asok
unix 2 [ ACC ] STREAM LISTENING 24107 /var/run/ceph/ceph-mds.mds2.asok
unix 2 [ ACC ] STREAM LISTENING 23650 /var/run/ceph/ceph-mds.mds1.asok
unix 2 [ ACC ] STREAM LISTENING 25567 /var/run/ceph/ceph-osd.3.asok
unix 2 [ ACC ] STREAM LISTENING 25570 /var/run/ceph/ceph-osd.0.asok
unix 2 [ ACC ] STREAM LISTENING 23548 /var/run/ceph/ceph-mds.cephfs.asok
[root@node-1 ~]# netstat -p | grep ceph
...
tcp 0 0 node-1:41340 node-1:6822 ESTABLISHED 985/ceph-mds
tcp 0 0 node-1:37972 node-1:6806 ESTABLISHED 989/ceph-mds
tcp 0 0 node-1:3300 node-1:43174 ESTABLISHED 982/ceph-mon
unix 3 [ ] STREAM CONNECTED 23529 1587/ceph-osd
unix 3 [ ] STREAM CONNECTED 20638 989/ceph-mds
unix 3 [ ] STREAM CONNECTED 20253 985/ceph-mds
unix 3 [ ] STREAM CONNECTED 24220 1634/ceph-osd
unix 3 [ ] STREAM CONNECTED 20386 986/ceph-mgr
unix 3 [ ] STREAM CONNECTED 20081 984/ceph-mds
unix 3 [ ] STREAM CONNECTED 20310 982/ceph-mon驱动器配置
一个SAS或SATA硬盘只能包含一个OSD;NVMe驱动器很容易处理两个或更多。如果其他进程共享该驱动器，包括日志/元数据、操作系统、Ceph监视器、syslog日志、其他osd和非Ceph进程，则读写吞吐量会出现瓶颈。
注意：对驱动器进行分区不会改变其总吞吐量或顺序读/写限制。在单独的分区中运行日志可能会有帮助，但应该选择单独的物理驱动器。
磁盘损坏/磁盘碎片
MON和OSD在同一节点
监控器是相对轻量级的进程，但它们会发出大量的fsync()调用，这可能会干扰其他工作负载，特别是当监控器与OSD运行在同一个驱动器上时。如果在OSD相同的主机上运行MON，可能会引发与以下方面相关的性能问题：
- 运行旧内核（3.0之前）
- 运行一个无
syncfs(2)系统调用的内核
在这些情况下，运行在同一主机上的多个osd可能会通过执行大量提交而相互拖慢。
同节点的进程
共同驻留的进程(聚合)，如基于云的解决方案、虚拟机和其他将数据写入Ceph的应用程序，同时在与OSD相同的硬件上操作，可能会引入显著的OSD延迟。一般来说，我们建议优化使用Ceph的主机，并为其他进程使用其他主机。将Ceph操作与其他应用程序分离的做法可能有助于提高性能，并有助于简化故障排除和维护工作。
日志等级
将日志级别调高以跟踪问题，然后忘记将日志级别调低，那么OSD可能会将大量日志放到磁盘上。如果打算保持较高的日志级别，可以考虑将单独的驱动器挂载到默认的日志路径(即/var/log/ceph/name.log)。
恢复限流
OSD恢复时的速度限制或者加速可能会影响到正常业务。
# 相关配置介绍
osd_recovery_max_single_start #越大，OSD恢复速度越快，集群对外服务受到影响越大，默认为1
osd_recovery_max_active #越大，OSD恢复速度越快，集群对外服务受到影响越大，默认为3
osd_recovery_op_priority #越大，OSD恢复速度越快，集群对外服务受到影响越大，默认为3
osd_max_backfills #越大，OSD恢复速度越快，集群对外服务受到影响越大，默认为1
osd_recovery_sleep #越小，OSD恢复速度越快，集群对外服务受到影响越大，默认为0秒内存不足
建议每个OSD守护进程至少有4GB的RAM，并建议从6-8GB向上取整。您可能会注意到，在正常操作期间，ceph-osd进程只使用其中的一小部分。未使用的RAM使得人们倾向于将多余的RAM用于共同驻留的应用程序，或者节省每个节点的内存容量。然而，当osd经历恢复时，它们的内存利用率会出现峰值。如果没有足够的RAM可用，OSD的性能将大大降低，守护进程甚至可能崩溃或被Linux OOM杀手杀死。
请求阻塞或慢op
默认情况下，op响应超过30秒，集群会发出一个慢op的警告。
{date} {osd.num} [WRN] 1 slow requests, 1 included below; oldest blocked for > 30.005692 secs
{date} {osd.num} [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]可能产生的原因：
- 驱动器错误（检查dmseg）
- 内核bug
- 过载的集群（检查iostat，system load）
- OSD进程bug
可能解决方案：
- 移除Ceph节点上的虚拟机
- 升级内核
- 升级Ceph
- 重启OSD
- 更换损坏的驱动器或其他设备
调试慢请求
查看op历史详情：
$ ceph deamon osd.<id> dump_historic_ops
[root@node-1 ~]# ceph daemon osd.0 dump_historic_ops
{
"ops": [
{
"description": "osd_op(client.2484118.0:9490 15.14 15:2b04a3e9:::notify.6:head [watch ping cookie 93986076981504] snapc 0=[] ondisk+write+known_if_redirected e6862)",
"initiated_at": "2021-10-26 10:30:11.395260",
"age": 4.6390988130000004,
"duration": 0.73565706500000005,
"type_data": {
"flag_point": "started",
"client_info": {
"client": "client.2484118",
"client_addr": "192.168.159.102:0/2457947188",
"tid": 9490
},
"events": [
{
"time": "2021-10-26 10:30:11.395260",
"event": "initiated"
},
{
"time": "2021-10-26 10:30:11.395260",
"event": "header_read"
},
{
"time": "2021-10-26 10:30:11.395258",
"event": "throttled"
},
{
"time": "2021-10-26 10:30:11.395261",
"event": "all_read"
},
{
"time": "2021-10-26 10:30:11.395262",
"event": "dispatched"
},
{
"time": "2021-10-26 10:30:11.395265",
"event": "queued_for_pg"
},
{
"time": "2021-10-26 10:30:12.130877",
"event": "reached_pg"
},
{
"time": "2021-10-26 10:30:12.130899",
"event": "started"
},
{
"time": "2021-10-26 10:30:12.130917",
"event": "done"
}
]
}
}
...
...
]
}查看正在执行的op详情：
$ ceph daemon osd.<id> dump_ops_in_flight
[root@node-1 ~]# ceph daemon osd.0 dump_ops_in_flight
{
"ops": [],
"num_ops": 0
}参数介绍：
来自Messenger层的事件：
- header_read：消息传递器第一次开始从网络读取消息时。
- throttled：当信使试图获取内存时，限流空间将消息读入内存。
- all_read：当消息传递者从线路上读取完消息时。
- dispatched：当信使把消息告诉OSD的时候。
- initiated：等同于header_read。
来自OSD层的事件：
- queued_for_pg：op已经被放到队列中，即将由它的PG进行处理。
- reached_pg：PG开始处理op。
- waiting for \*：op等待其他工作完成后才能继续(例如，一个新的OSDMap；为其对象目标擦洗；PG完成扫描等)。
- started：OSD开始处理该op。
- waiting for subops from：op发送给副本OSD。
来自objectstore（如bluestore）层的事件：
- op_commit：操作已提交（写入wal日志）。
- op_applied：操作已完成（写入slow设备）。
- sub_op_applied：副本上的op_applied（副本上完成写入slow设备）。
- sub_op_committed：副本上的op_commit（副本上写入wal日志），仅支持EC池。
- sub_op_commit_rec/sub_op_apply_rec from ：当主本听到副本完成某个事件后，会做出此标记。
- commit_sent：向客户端或者主OSD发送回复。
OSD抖动
当OSD进行peer和心跳检查时，他们使用可用的集群后端网络。
一般，集群使用分离的公共（前端）网络和私有（后端、集群、副本）网络：
- 心跳、复制、恢复使用私有网络。客户端和MON和OSD的通信使用公共网络。
- 公共网络和私有网络有更多的吞吐量。
当常用的网络技术是100Mb/s和1Gb/s时，这种分离（公共网络和私有网络）通常是至关重要的。在今天的10Gb/s、40Gb/s和25/50/100Gb/s的网络中，上述容量问题经常被减少甚至消除。例如，如果您的OSD节点有两个网口，将一个网口专用于公网，另一个专用于私网，则没有路径冗余。这降低了您经受网络维护和故障的能力，而不会对集群或客户机造成重大影响。考虑只在公共网络中使用这两个链接:通过绑定(LACP)或等价路由(例如FRR)，您可以获得增加吞吐量、容错和减少OSD抖动的好处。
抖动：在使用公网和私网时，如果私网发生故障，OSD们会使用公网向MON报告其他OSD状态为down，它自己状态为up。MON使用公网把新的OSD map发出，这些OSD map中显示为down的OSD会向MON报告自己是up的，如此循环往复，在up和down中不断切换。
只使用一种网络可能会避免抖动产生。
如果发生抖动现象，可以使用下列命令冻结OSD状态：
$ ceph osd set noup # 阻止OSD标记为up
或者
$ ceph osd set nodown # 阻止OSD标记为down可以在osd详情中查看是否设置这些标记：
$ ceph osd dump | grep flags
flags no-up,no-down清除标记：
$ ceph osd unset noup
$ ceph osd unsest nodown还支持另外两个标志，noin和noout，它们可以防止启动时的osd被标记进(已分配的数据)，或者保护osd最终不被标记出(不管mon osd down out interval的当前值是多少)。
通过仔细调整mon_osd_down_out_subtree_limit、mon_osd_reporter_subtree_level和mon_osd_min_down_reporters，可以在一定程度上减轻震荡的原因和影响。优化设置的来源取决于集群大小、拓扑结构和使用的Ceph版本。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
