注意
本文档适用于 Ceph 的开发版本。
OSD故障排除
在对集群的OSD进行故障排除之前，请检查监视器和网络。
首先，确定监视器是否具有仲裁。运行 ceph health 命令或 ceph -s 命令，如果Ceph显示 HEALTH_OK，则存在监视器仲裁。
如果监视器没有仲裁，或者监视器状态有错误，请在继续之前通过查阅 监视器故障排除 中的材料来解决监视器问题。
接下来，检查您的网络以确保它们正常运行。网络对OSD的操作和性能有重大影响。在主机端查找丢弃的数据包，在交换机端查找CRC错误。
获取OSD数据
在对OSD进行故障排除时，收集有关OSD的各种信息非常有用。一些信息来自 监视OSD 的实践（例如，通过运行 ceph osd tree 命令）。其他信息涉及集群的拓扑结构，将在以下部分中讨论。
Ceph日志
Ceph日志文件存储在 /var/log/ceph 下。除非路径已更改（或者您处于将日志存储在不同位置的容器化环境中），否则可以通过运行以下命令列出日志文件
ls /var/log/ceph
如果日志细节不够，请更改日志级别。要确保Ceph在高日志量下仍能充分运行，请参阅 日志和调试。
Admin Socket
使用admin socket工具检索运行时信息。首先，通过运行以下命令列出Ceph守护程序的socket
ls /var/run/ceph
接下来，运行以下形式的命令（将 {daemon-name} 替换为特定守护程序的名称：例如，osd.0）
ceph daemon {daemon-name} help
或者，运行指定了 {socket-file} 的命令（“socket file”是 /var/run/ceph 中的特定文件）
ceph daemon {socket-file} help
admin socket可以实现许多任务，包括
列出运行时的Ceph配置
转储历史操作
转储操作优先级队列状态
转储进行中的操作
转储性能计数器
显示可用空间
可能会出现文件系统问题。要显示文件系统的可用空间，请运行以下命令
df -h
要查看此命令支持的语法和选项，请运行 df --help。
I/O统计信息
iostat 工具可用于识别与I/O相关的问题。运行以下命令
iostat -x
诊断消息
要从内核检索诊断消息，请运行 dmesg 命令并使用 less、more、grep 或 tail 指定输出。例如
dmesg | grep scsi
不进行重新平衡的情况下停止
有时可能需要对集群的一部分执行维护，或者解决影响故障域（例如，一个机架）的问题。但是，当您停止OSD进行维护时，您可能希望防止CRUSH自动重新平衡集群。为了避免这种重新平衡行为，通过运行以下命令将集群设置为 noout
ceph osd set noout
警告
这更多的是为了让读者了解故障域和CRUSH行为而提供的思考练习，而不是建议Luminous之后的任何人运行 ceph osd set noout。当OSD返回到 up 状态时，重新平衡将恢复，并且 ceph osd set noout 命令引入的更改将被还原。
然而，在Luminous及更高版本中，更安全的方法是仅标记受影响的OSD。要向特定OSD添加或删除 noout 标志，请运行如下命令
ceph osd add-noout osd.0
ceph osd rm-noout osd.0
也可以标记整个CRUSH bucket。例如，如果您计划关闭 prod-ceph-data1701 以添加RAM，您可能运行以下命令
ceph osd set-group noout prod-ceph-data1701
设置标志后，停止OSD和需要维护工作的故障域内的任何其他共存Ceph服务
systemctl stop ceph\*.service ceph\*.target
注意
当OSD停止时，OSD内的任何放置组都被标记为 degraded。
维护完成后，需要重新启动OSD和任何已停止的其他守护程序。但是，如果主机作为维护的一部分重新启动，则无需重新启动它们，它们将自动启动。要重新启动OSD或其他守护程序，请使用以下形式的命令
sudo systemctl start ceph.target
最后，根据需要通过运行如下命令取消设置 noout 标志
ceph osd unset noout
ceph osd unset-group noout prod-ceph-data1701
许多当代Linux发行版使用 systemd 进行服务管理。但是，对于某些操作系统（尤其是较旧的操作系统），可能需要发出等效的 service 或 start/stop 命令。
OSD未运行
在正常情况下，重新启动 ceph-osd 守护程序将允许它重新加入集群并恢复。
OSD无法启动
如果集群已启动但OSD未启动，请检查以下内容
配置文件： 如果您无法从新安装中使OSD运行，请检查您的配置文件以确保它符合标准（例如，确保它说
host而不是hostname，等等）。检查路径： 确保配置文件中指定的路径与实际存在的数据和元数据路径相对应（例如，日志、WAL和DB的路径）。将OSD数据与元数据分开，以查看配置文件和实际挂载中是否存在错误。如果是这样，这些错误可能解释了为什么OSD没有启动。要将元数据存储在单独的块设备上，请对驱动器进行分区或LVM，并为每个OSD分配一个分区。
检查最大线程数： 如果集群中的节点有特别多的OSD，它可能达到了默认的最大线程数（通常为32,000）。这在恢复期间尤其可能发生。将最大线程数增加到允许的最大可能线程数（4194303）可能有助于解决此问题。要将线程数增加到最大值，请运行以下命令
sysctl -w kernel.pid_max=4194303如果此增加解决了问题，您必须通过在
/etc/sysctl.d下的文件中或在主/etc/sysctl.conf文件中包含kernel.pid_max设置来使增加永久生效。例如kernel.pid_max = 4194303
检查 ``nf_conntrack``： 这个连接跟踪和连接限制系统给许多生产Ceph集群带来了问题。问题通常出现缓慢且微妙。随着集群拓扑和客户端工作负载的增长，神秘且间歇性的连接失败和性能故障会越来越多地发生，尤其是在一天的某些时候。要开始衡量您的问题，请检查
syslog历史记录中的“table full”事件。解决此类问题的一种方法如下：首先，使用sysctl实用程序为nf_conntrack_max分配一个更高的值。接下来，提高nf_conntrack_buckets的值，使得nf_conntrack_buckets× 8 =nf_conntrack_max；此操作可能需要运行sysctl之外的命令（例如，"echo 131072 > /sys/module/nf_conntrack/parameters/hashsize）。解决问题的另一种方法是列入黑名单相关的内核模块以完全禁用处理。这种方法功能强大，但很脆弱。模块以及必须列出模块的顺序可能因内核版本而异。即使被列入黑名单，iptables和docker有时也可能无论如何都会激活连接跟踪，因此我们建议对可调参数采用“设置后即忘”策略。在现代系统上，这种方法不会消耗可观的资源。内核版本： 确定正在使用的内核版本和发行版。默认情况下，Ceph使用第三方工具，这些工具可能存在错误或与某些发行版或内核版本发生冲突（例如，Google的
gperftools和TCMalloc）。检查 操作系统建议 和每个Ceph版本的发行说明，以确保您已解决与内核相关的任何问题。分段故障： 如果发生分段故障，请增加日志级别并重新启动有问题的守护程序。如果分段故障再次发生，请搜索Ceph错误跟踪器 https://tracker.ceph/com/projects/ceph 和
dev和ceph-users邮件列表档案 https://ceph.net.cn/resources，查看其他人是否遇到并报告了这些问题。如果这确实是一个新的独特的故障，请发布到dev电子邮件列表并提供以下信息：正在运行的特定Ceph版本、ceph.conf（将密钥XXX'd出）、您的监视器状态输出以及您的日志文件摘录。
OSD失败
当OSD失败时，这意味着 ceph-osd 进程无响应或已死亡，并且相应的OSD已被标记为 down。幸存的 ceph-osd 守护程序将向监视器报告OSD似乎已关闭，并且新状态将在 ceph health 命令的输出中可见，如以下示例所示
ceph health
HEALTH_WARN 1/3 in osds are down
只要有一个或多个OSD被标记为 in 和 down，就会引发此健康警报。要查看哪些OSD已 down，请在命令中添加 detail，如以下示例所示
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
如果存在驱动器故障或其他阻止给定 ceph-osd 守护程序正常运行或重新启动的故障，则其日志文件 /var/log/ceph 下应存在错误消息。
如果 ceph-osd 守护程序因心跳失败或 suicide timeout 错误而停止，则底层驱动器或文件系统可能无响应。检查 dmesg 输出和 syslog 输出以查找驱动器错误或内核错误。可能需要指定某些标志（例如，dmesg -T 以查看人类可读的时间戳）以避免将旧错误误认为新错误。
如果整个主机的OSD都已 down，请检查主机是否存在网络错误或硬件问题。
如果OSD问题是由于软件错误（例如，断言失败或另一个意外错误）导致的，请在 错误跟踪器、开发邮件列表档案 和 ceph-users邮件列表档案 中搜索该问题的报告。如果没有明确的修复或现有错误，请 向ceph-devel电子邮件列表报告问题。
没有可用驱动器空间
如果OSD已满，Ceph会通过确保没有新数据写入OSD来防止数据丢失。在正常运行的集群中，当集群的OSD和池接近某些“满”比率时，会引发健康检查。 mon_osd_full_ratio 阈值默认为 0.95（或容量的95%）：这是阻止客户端写入数据的点。 mon_osd_backfillfull_ratio 阈值默认为 0.90（或容量的90%）：这是反向填充不会开始的点。 mon_osd_nearfull_ratio 阈值默认为 0.85（或容量的85%）：这是引发 OSD_NEARFULL 健康检查的点。
集群中的OSD将因Ceph分配给它们的数据量而异。要通过显示每个OSD的数据利用率来检查“满”程度，请运行以下命令
ceph osd df
要通过显示集群的总体数据使用情况和池之间的数据分布来检查“满”程度，请运行以下命令
ceph df
在检查 ceph df 命令的输出时，请特别注意最满的OSD，而不是使用的原始空间百分比。如果单个异常OSD变满，则对该OSD的池的所有写入可能会因此失败。当 ceph df 报告池的可用空间时，它会考虑与池中最满的OSD相关的比率设置。要使分布变平，有两种方法可用：(1) 使用 reweight-by-utilization 命令逐步将数据从过度满的OSD移走或将数据移动到不足满的OSD，以及 (2) 在Luminous的后续版本中，利用 ceph-mgr balancer 模块自动执行相同的任务。
要调整“满”比率，请运行以下形式的一个或多个命令
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]>
有时，由于OSD失败，会出现集群已满的问题。这可能是由于测试或集群很小、非常满或不平衡而发生的。当OSD或节点占集群数据比例过高时，组件故障或自然增长可能导致 nearfull 和 full 比率被超出。在测试Ceph对小型集群上OSD故障的弹性时，建议留下充足的可用磁盘空间，并考虑暂时降低OSD full ratio、OSD backfillfull ratio 和 OSD nearfull ratio。
OSD的“满”状态在 ceph health 命令的输出中可见，如以下示例所示
ceph health
HEALTH_WARN 1 nearfull osd(s)
有关详细信息，请添加 detail 命令，如以下示例所示
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%
要解决集群已满的问题，建议通过添加OSD来增加容量。添加新的OSD允许集群将数据重新分发到新可用的存储。搜索浪费空间的 rados bench 孤儿。
如果由于已满而无法启动旧版Filestore OSD，则可以通过删除满OSD中的少量放置组目录来回收空间。
重要
如果您选择删除满OSD上的放置组目录，请勿删除另一个满OSD上的同一放置组目录。否则您将丢失数据。您必须在至少一个OSD上保留至少一个数据副本。删除放置组目录是一种罕见且极端的干预措施。不能掉以轻心。
有关详细信息，请参阅 监视器配置参考。
OSD变慢/无响应
OSD有时会变慢或无响应。在对这个常见问题进行故障排除时，建议在调查OSD性能问题之前排除其他可能性。例如，请务必确认您的网络正常工作，验证您的OSD正在运行，并检查OSD是否正在限制恢复流量。
提示
在Ceph的Luminous之前版本中，up 和 in OSD有时不可用或速度较慢，因为正在恢复的OSD正在消耗系统资源。新版本通过防止这种现象提供更好的恢复处理。
网络问题
作为一个分布式存储系统，Ceph依赖网络进行OSD对等和复制、从故障中恢复以及周期性心跳。网络问题可能导致OSD延迟和OSD flapping。有关详细信息，请参阅 Flapping OSDs。
要确保Ceph进程和依赖Ceph的进程已连接并正在侦听，请运行以下命令
netstat -a | grep ceph
netstat -l | grep ceph
sudo netstat -p | grep ceph
要检查网络统计信息，请运行以下命令
netstat -s
驱动器配置
SAS或SATA存储驱动器应只容纳一个OSD，但NVMe驱动器可以轻松容纳两个或更多。但是，如果其他进程共享驱动器，则读写吞吐量可能会成为瓶颈。此类进程包括：日志/元数据、操作系统、Ceph监视器、syslog 日志、其他OSD和非Ceph进程。
因为Ceph在日志记录之后确认写入，所以快速SSD是加速响应时间的有吸引力的选择——特别是当对旧版FileStore OSD使用 XFS 或 ext4 文件系统时。相比之下，Btrfs 文件系统可以同时写入和日志记录。（但是，不建议在生产部署中使用 Btrfs。）
注意
对驱动器进行分区不会改变其总吞吐量或顺序读/写限制。通过在单独的分区中运行日志，吞吐量可能会有所改善，但在单独的物理驱动器中运行此类日志更好。
警告
Reef不支持FileStore。Reef之后的版本不支持FileStore。任何提及FileStore的信息仅与Ceph的Quincy版本和Quincy之前的版本相关。
坏扇区/碎片磁盘
检查驱动器是否有坏块、碎片和其他可能导致性能显著下降的错误。检查驱动器错误的有用工具包括 dmesg、syslog 日志和 smartctl（在 smartmontools 包中找到）。
注意
smartmontools 7.0及更高版本提供NVMe stat passthrough和JSON输出。
监视器/OSD共存
尽管监视器是相对轻量级的进程，但当监视器与OSD在同一台主机上运行时，可能会导致性能问题。监视器发出许多 fsync() 调用，这可能会干扰其他工作负载。当监视器与OSD共存于同一存储驱动器上时，性能问题的风险尤其严重。此外，如果监视器正在运行较旧的内核（早于3.0）或没有 syncfs(2) syscall的内核，则在同一主机上运行的多个OSD可能会进行如此多的提交以至于损害彼此的性能。这个问题有时会导致所谓的“突发写入”。
共存进程
将数据写入Ceph的进程（例如，基于云的解决方案和虚拟机）在与OSD相同的硬件上运行时，可能会导致显著的OSD延迟。因此，通常不建议使此类进程与OSD共存。相反，推荐的做法是优化某些主机以与Ceph一起使用，并使用其他主机进行其他进程。将Ceph操作与其他应用程序分开的这种做法可能有助于提高性能，也可能简化故障排除和维护。
在同一硬件上运行共存进程有时被称为“融合”。使用Ceph时，仅在具备专业知识并经过考虑后才进行融合。
日志级别
高日志级别可能会导致性能问题。操作员有时会提高日志级别以跟踪问题，然后忘记事后将其降低。在这种情况下，OSD可能会消耗宝贵的系统资源，将不必要的冗长日志写入磁盘。建议任何想要使用高日志级别的人考虑将驱动器挂载到日志记录的默认路径（例如，/var/log/ceph/$cluster-$name.log）。
恢复限制
根据您的配置，Ceph可能会降低恢复速率以保持客户端或OSD性能，或者可能会将恢复速率提高到恢复影响客户端或OSD性能的程度。检查客户端或OSD是否正在恢复。
内核版本
检查您正在运行的内核版本。较旧的内核可能缺少提高Ceph性能的更新。
SyncFS的内核问题
如果您有SyncFS的内核问题，请尝试每个主机运行一个OSD，看看性能是否有所改善。旧内核可能没有足够新版本的 glibc 来支持 syncfs(2)。
文件系统问题
在Luminous之后的版本中，我们建议使用BlueStore后端部署集群。在运行Luminous之前的版本时，或者如果您有特定原因要使用以前的Filestore后端部署OSD，我们建议使用 XFS。
我们不建议使用 Btrfs 或 ext4。Btrfs 文件系统有许多吸引人的功能，但错误可能导致性能问题和虚假的ENOSPC错误。我们不建议对Filestore OSD使用 ext4，因为 xattr 限制破坏了对长对象名称的支持，而RBG需要长对象名称。
RAM不足
我们建议每个OSD守护程序最少 4GB RAM，并建议从6GB向上取整到8GB。在正常操作期间，您可能会注意到 ceph-osd 进程仅使用该数量的一小部分。您可能想将多余的RAM用于共存应用程序或节省每个节点的内存容量。但是，当OSD经历恢复时，它们的内存利用率会激增。如果在恢复期间没有足够的RAM可用，OSD性能将显着变慢，守护程序甚至可能崩溃或被Linux OOM Killer 杀死。
阻塞的请求或慢速请求
当 ceph-osd 守护程序响应请求缓慢时，集群日志会收到报告操作耗时过长的消息。警告阈值默认为30秒，可通过 osd_op_complaint_time 设置配置。
旧版Ceph会抱怨 old requests
osd.0 192.168.106.220:6800/18813 312 : [WRN] old request osd_op(client.5099.0:790 fatty_26485_object789 [write 0~4096] 2.5e54f643) v4 received at 2012-03-06 15:42:56.054801 currently waiting for sub ops
新版Ceph会抱怨 slow requests
{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]
可能的原因包括
驱动器故障（检查
dmesg输出）内核文件系统中的错误（检查
dmesg输出）集群过载（检查系统负载、iostat等）
ceph-osd守护程序中的错误。OSD分片配置不理想（在具有mClock调度程序的HDD集群上）
可能的解决方案
从Ceph主机中删除VM
升级内核
升级Ceph
重新启动OSD
更换失败或故障的组件
- 覆盖OSD分片配置（在具有mClock调度程序的HDD集群上）
有关分辨率，请参阅 使用mClock调度程序时慢速请求或慢速恢复
调试慢速请求
如果您运行 ceph daemon osd.<id> dump_historic_ops 或 ceph daemon osd.<id> dump_ops_in_flight，您将看到一组操作以及每个操作所经历的事件列表。下面简要描述了这些事件。
来自Messenger层的事件
header_read: 信使首次开始读取线上的消息的时间。throttled: 信使尝试获取内存节流空间以将消息读入内存的时间。all_read: 信使完成读取线上的消息的时间。dispatched: 信使将消息交给OSD的时间。initiated: 这与header_read相同。两者的存在是历史遗留问题。
OSD处理操作时的事件
queued_for_pg: 操作已放入其PG的队列中进行处理。reached_pg: PG已开始执行操作。waiting for \*: 操作正在等待某些其他工作完成才能继续（例如，新的OSDMap；其对象目标的擦洗；PG对等完成；所有这些都在消息中指定）。started: 操作已被接受为OSD应该做的事情，并且现在正在执行。waiting for subops from: 操作已发送到副本OSD。
来自 Filestore 的事件
commit_queued_for_journal_write: 操作已交给FileStore。write_thread_in_journal_buffer: 操作位于日志的缓冲区中，正在等待持久化（作为下一次磁盘写入）。journaled_completion_queued: 操作已日志记录到磁盘，其回调已排队等待调用。
数据已交给底层存储后来自OSD的事件
op_commit: 操作已由主OSD提交（即写入日志）。op_applied: 操作已 写入write() 到后端FS（即在内存中应用但未刷新到磁盘）在主OSD上。sub_op_applied:op_applied，但用于副本的“subop”。sub_op_committed:op_commit，但用于副本的subop（仅适用于EC池）。sub_op_commit_rec/sub_op_apply_rec from <X>: 当主OSD听说上述情况时（即<X>），它会标记此内容。commit_sent: 我们向客户端（或主OSD，对于subops）发送了回复。
尽管其中一些事件可能看起来是多余的，但它们跨越了内部代码中的重要边界（例如，将数据跨锁传递到新线程）。
使用mClock调度程序时慢速请求或慢速恢复
注意
此故障排除仅适用于运行mClock调度程序且具有以下OSD分片配置的基于HDD的集群：osd_op_num_shards_hdd = 5 和 osd_op_num_threads_per_shard_hdd = 1。另请参阅 使用mClock的基于HDD的集群的OSD分片配置，了解有关mClock的默认OSD HDD分片配置更改原因的详细信息。
在启用mClock调度程序且在多个OSD节点故障条件下缩放的基于HDD的集群上，可能会报告或观察到以下情况
慢速请求：这也表现为客户端I/O性能下降。
慢速后台恢复：恢复吞吐量低于预期。
故障排除步骤
从OSD事件中验证慢速请求是否主要是
queued_for_pg类型。验证报告的恢复率是否明显低于考虑到后台恢复服务的QoS分配的预期速率。
如果上述任何一个步骤属实，则可以应用以下解决方案。请注意，这具有破坏性，因为它涉及OSD重新启动。运行以下命令更改HDD的默认OSD分片配置
ceph config set osd osd_op_num_shards_hdd 1
ceph config set osd osd_op_num_threads_per_shard_hdd 5
上述配置不会立即生效，需要重新启动环境中的OSD。为了使此过程的破坏性最小，可以以仔细交错的方式重新启动OSD。
Flapping OSDs
“Flapping”是指OSD在短时间内重复被标记为 up，然后又被标记为 down 的现象。本节解释如何识别 flapping 以及如何缓解它。
当OSD对等和检查心跳时，如果集群（后端）网络可用，它们会使用它。有关详细信息，请参阅 监视器/OSD交互。
上游Ceph社区传统上推荐单独的公共（前端）和私有（集群/后端/复制）网络。这提供了以下好处
将 (1) 心跳流量和复制/恢复流量（私有）与 (2) 来自客户端以及OSD和监视器之间的流量（公共）分离。这有助于防止一股流量对另一股流量进行DoS攻击，从而可能导致级联故障。
公共和私有流量的额外吞吐量。
过去，当常见的网络技术以100Mb/s和1Gb/s的范围衡量时，这种分离通常至关重要。但是随着当今的10Gb/s、40Gb/s和25/50/100Gb/s网络，上述容量问题通常会减少甚至消除。例如，如果您的OSD节点有两个网络端口，将一个端口专用于公共网络而另一个端口专用于私有网络意味着您没有路径冗余。这会降低您在没有显著集群或客户端影响的情况下承受网络维护和网络故障的能力。在这种情况下，请考虑将两个链路仅用于公共网络：通过绑定（LACP）或等成本路由（例如，FRR），您可以获得增加的吞吐量余量、容错性和减少OSD flapping的好处。
当私有网络（甚至单个主机链路）失败或降级而公共网络继续正常运行时，OSD可能无法很好地处理这种情况。在这种情况下，OSD使用公共网络向监视器报告彼此 down，同时将自己标记为 up。然后，监视器再次通过公共网络发送更新的集群图，其中受影响的OSD标记为 down。这些OSD回复监视器“我还没死！”，循环重复。我们称这种情况为“flapping”，可能难以隔离和修复。如果没有私有网络，则避免了这种烦人的动态：OSD通常要么 up，要么 down，没有 flapping。
如果有什么原因导致OSD“flap”（重复被标记为 down 然后再次 up），您可以通过暂时冻结它们的状态来强制监视器停止 flapping
ceph osd set noup # prevent OSDs from getting marked up
ceph osd set nodown # prevent OSDs from getting marked down
这些标志记录在osdmap中
ceph osd dump | grep flags
flags no-up,no-down
您可以使用以下命令清除这些标志
ceph osd unset noup
ceph osd unset nodown
还有另外两个标志可用，noin 和 noout，它们分别防止启动OSD被标记为 in（分配数据）或保护OSD最终不被标记为 out（无论 mon_osd_down_out_interval 的当前值如何）。
注意
noup、noout 和 nodown 是暂时的，因为清除标志后，它们所阻止的操作应该很快就可以执行。但是 noin 标志会阻止OSD在启动时被标记为 in，并且在设置标志时启动的任何守护程序都将保持这种状态。
注意
Flapping的原因和影响可以通过仔细调整 mon_osd_down_out_subtree_limit、mon_osd_reporter_subtree_level 和 mon_osd_min_down_reporters 来缓解。最佳设置的推导取决于集群大小、拓扑结构和正在使用的Ceph版本。所有这些因素的相互作用是微妙的，超出了本文档的范围。