6.3. 解决集群警报

Red Hat Ceph Storage 集群可以引发的一组有限健康警报，显示在 OpenShift Data Foundation 用户界面中。它们定义为具有唯一标识符的健康警报。标识符是一个制表伪可读字符串，旨在使工具能够理解健康检查，并以反应其含义的方式呈现它们。点健康警报以了解更多信息和故障排除。

表 6.1. 集群健康警报的类型
健康警报	概述
CephClusterCriticallyFull	存储集群利用率已超过 80%。
CephClusterErrorState	存储集群处于错误状态的时间已超过 10 分钟。
CephClusterNearFull	存储集群接近满容量。需要删除数据或集群扩展。
CephClusterReadOnly	存储集群现在是只读的，需要立即删除数据或集群扩展。
CephClusterWarningState	存储集群处于警告状态超过 10 分钟。
CephDataRecoveryTakingTooLong	Data recovery has been active for too long.
CephMdsMissingReplicas	存储元数据服务不可用所需的最小副本。可能会影响存储集群的工作。
CephMgrIsAbsent	Ceph Manager has disappeared from Prometheus target discovery.
CephMgrIsMissingReplicas	Ceph 管理器缺少副本。这会破坏健康状态报告，并将导致 `ceph status` 命令报告的一些信息缺失或过时。此外，Ceph 管理器负责一个管理器框架，旨在扩展 Ceph 的现有功能。
CephMonHighNumberOfLeaderChanges	Ceph 监控领导正在改变异常次数。
CephMonQuorumAtRisk	Storage cluster quorum is low.
CephMonQuorumLost	存储集群中的监控 pod 数量不够。
CephMonVersionMismatch	运行 Ceph Mon 组件的不同版本。
CephNodeDown	存储节点停机。立即检查节点。该警报应包含节点名称。
CephOSDCriticallyFull	后端对象存储设备(OSD)的利用率已超过 80%。立即释放一些空间或扩展存储集群或联系支持。
CephOSDDiskNotResponding	磁盘设备没有在其中一个主机上响应。
CephOSDDiskUnavailable	一个主机上无法访问磁盘设备。
CephOSDFlapping	Ceph 存储 OSD 阻塞。
CephOSDNearFull	其中一个 OSD 存储设备接近满。
CephOSDSlowOps	OSD 请求需要很长时间才能进行处理。
CephOSDVersionMismatch	运行 Ceph OSD 组件的不同版本。
CephPGRepairTakingTooLong	自我修复操作用时过长。
CephPoolQuotaBytesCriticallyExhausted	存储池配额使用量已超过 90%。
CephPoolQuotaBytesNearExhaustion	存储池配额使用量已超过 70。
PersistentVolumeUsageCritical	持久性卷声明使用量已超过 85% 的容量。
PersistentVolumeUsageNearFull	持久性卷声明使用量已超过 75% 的容量。

6.3.1. CephClusterCriticallyFull

含义	存储集群利用率已超过 80%，并将在 85% 时变得只读。超过 85% 的利用率后，您的 Ceph 集群将变得只读。释放一些空间或立即扩展存储集群。在此警报之前，会看到与 Object Storage Device (OSD)设备满或接近满的警报。
影响	高

诊断

扩展存储: 根据集群的类型，您需要添加存储设备、节点或两者。如需更多信息，请参阅扩展存储指南。

缓解方案

删除信息: 如果无法扩展集群，则需要删除信息来释放一些空间。

6.3.2. CephClusterErrorState

含义	此警报反映了存储集群在不可接受的时间处于 ERROR 状态，这会破坏存储的可用性。检查之前触发的其他警报，并首先对这些警报进行故障排除。
影响	Critical

诊断

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
$ oc get pod | grep rook-ceph
```
将 MYPOD 设置为标识为问题 pod 的 pod 的变量：
```
# Examine the output for a rook-ceph that is in the pending state, not running or not ready
MYPOD=<pod_name>
```
<pod_name>
指定识别为问题 pod 的 pod 的名称。
查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：
```
$ oc describe pod/${MYPOD}
```

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：
```
$ oc logs pod/${MYPOD}
```
重要
- 如果分配了节点，请检查节点上的 kubelet。
- 如果正在运行的 pod 的基本健康状况，则验证节点上的节点关联性和资源可用性，请运行 Ceph 工具来获取存储组件的状态。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：
```
$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6
```

6.3.3. CephClusterNearFull

含义	存储集群利用率已超过 75%，并将在 85% 时变得只读。释放一些空间或扩展存储集群。
影响	Critical

诊断

扩展存储: 根据集群的类型，您需要添加存储设备、节点或两者。如需更多信息，请参阅扩展存储指南。

缓解方案

删除信息: 如果无法扩展集群，则需要删除信息来释放一些空间。

6.3.4. CephClusterReadOnly

含义	存储集群利用率已超过 85%，现在将变为只读。释放一些空间或立即扩展存储集群。
影响	Critical

诊断

扩展存储: 根据集群的类型，您需要添加存储设备、节点或两者。如需更多信息，请参阅扩展存储指南。

缓解方案

删除信息: 如果无法扩展集群，则需要删除信息来释放一些空间。

6.3.5. CephClusterWarningState

含义	此警报反映了存储集群在不可接受的时间处于警告状态。虽然存储操作将继续处于此状态，但建议修复这个错误，以便集群不会遇到错误状态影响操作。检查之前可能触发的其他警报，并首先对这些警报进行故障排除。
影响	高

诊断

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
oc get pod | grep {ceph-component}
```

将 MYPOD 设置为标识为问题 pod 的 pod 的变量：

# Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
MYPOD=<pod_name>

<pod_name>: 指定识别为问题 pod 的 pod 的名称。

查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：
```
$ oc describe pod/${MYPOD}
```

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：
```
$ oc logs pod/${MYPOD}
```
重要
如果分配了节点，请检查节点上的 kubelet。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：

$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.6. CephDataRecoveryTakingTooLong

含义	数据恢复速度较慢。检查所有对象存储设备(OSD)是否已启动并运行。
影响	高

诊断

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
oc get pod | grep rook-ceph-osd
```

将 MYPOD 设置为标识为问题 pod 的 pod 的变量：

# Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
MYPOD=<pod_name>

<pod_name>: 指定识别为问题 pod 的 pod 的名称。

查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：
```
$ oc describe pod/${MYPOD}
```

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：
```
$ oc logs pod/${MYPOD}
```
重要
如果分配了节点，请检查节点上的 kubelet。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：

$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.7. CephMdsMissingReplicas

含义	存储元数据服务(MDS)的最低副本不可用。MDS 负责填充元数据。MDS 服务的降级可能会影响存储集群的工作方式（与 CephFS 存储类相关），并应尽快修复。
影响	高

诊断

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
oc get pod | grep rook-ceph-mds
```

将 MYPOD 设置为标识为问题 pod 的 pod 的变量：

# Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
MYPOD=<pod_name>

<pod_name>: 指定识别为问题 pod 的 pod 的名称。

查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：
```
$ oc describe pod/${MYPOD}
```

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：
```
$ oc logs pod/${MYPOD}
```
重要
如果分配了节点，请检查节点上的 kubelet。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：

$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.8. CephMgrIsAbsent

含义	没有 Ceph 管理器运行对集群的监控。创建和删除请求应尽快解决持久性卷声明(PVC)创建和删除请求。
影响	高

诊断

验证 rook-ceph-mgr pod 失败，并在需要时重启。如果 Ceph mgr pod 重启失败，请遵循常规 pod 故障排除来解决这个问题。
- 验证 Ceph mgr pod 失败：
```
$ oc get pods | grep mgr
```
- 描述 Ceph mgr pod 以获取更多详细信息：
```
$ oc describe pods/<pod_name>
```
  <pod_name>
  指定上一步中的 rook-ceph-mgr pod 名称。
  分析与资源问题相关的错误。
- 删除 pod，并等待 pod 重启：
```
$ oc get pods | grep mgr
```

按照以下步骤进行常规 pod 故障排除：

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
oc get pod | grep rook-ceph-mgr
```

将 MYPOD 设置为标识为问题 pod 的 pod 的变量：

# Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
MYPOD=<pod_name>

<pod_name>: 指定识别为问题 pod 的 pod 的名称。

查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：
```
$ oc describe pod/${MYPOD}
```

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：
```
$ oc logs pod/${MYPOD}
```
重要
如果分配了节点，请检查节点上的 kubelet。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：

$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.9. CephMgrIsMissingReplicas

含义	要解决此警报，您需要确定 Ceph 管理器消失的原因，并在需要时重新启动。
影响	高

诊断

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
oc get pod | grep rook-ceph-mgr
```

将 MYPOD 设置为标识为问题 pod 的 pod 的变量：

# Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
MYPOD=<pod_name>

<pod_name>: 指定识别为问题 pod 的 pod 的名称。

查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：
```
$ oc describe pod/${MYPOD}
```

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：
```
$ oc logs pod/${MYPOD}
```
重要
如果分配了节点，请检查节点上的 kubelet。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：

$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.10. CephMonHighNumberOfLeaderChanges

含义

在 Ceph 集群中，有一组冗余的 monitor pod，用于存储有关存储集群的重要信息。定期监控 pod 同步，以获取有关存储集群的信息。第一个监控 pod 获取最新更新的信息成为领导信息，其他监控容器集将在询问领导后启动其同步过程。在一个或多个 monitor pod 中网络连接或其他类型问题会造成不必要的变化。这种情形可能会对存储集群性能造成负面影响。

影响

Medium

重要

检查是否有网络问题。如果存在网络问题，则需要在进行以下任何故障排除步骤前升级到 OpenShift Data Foundation 团队。

诊断

输出受影响监控 pod 的日志，以收集有关此问题的更多信息：
```
$ oc logs <rook-ceph-mon-X-yyyy> -n openshift-storage
```
<rook-ceph-mon-X-yyyy>
指定受影响的 monitor pod 的名称。
或者，使用 Openshift Web 控制台打开受影响的监控 pod 的日志。有关可能原因的更多信息，会在日志中反映。
执行常规 pod 故障排除步骤：
Pod 状态：Pending
检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
oc get pod | grep {ceph-component}
```

将 MYPOD 设置为标识为问题 pod 的 pod 的变量：

# Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
MYPOD=<pod_name>

<pod_name>: 指定识别为问题 pod 的 pod 的名称。

查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```
Pod 状态： NOT pending, running, but not ready
检查就绪度探测：
```
$ oc describe pod/${MYPOD}
```
Pod 状态：非待处理，但没有运行
检查应用程序或镜像问题：
```
$ oc logs pod/${MYPOD}
```
重要
如果分配了节点，请检查节点上的 kubelet。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：

$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.11. CephMonQuorumAtRisk

含义	多个 MON 协同工作以提供冗余性。每个 MON 都会保留元数据的副本。集群使用 3 MON 部署，并且需要 2 个或更多 MON 上线并运行仲裁，以及运行存储操作。如果 quorum 丢失，对数据的访问面临风险。
影响	高

诊断

恢复 Ceph MON Quorum。如需更多信息，请参阅故障排除指南中的在 OpenShift Data Foundation 中恢复 ceph-monitor 仲裁。如果恢复 Ceph MON Quorum 失败，请遵循常规 pod 故障排除来解决这个问题。

对常规 pod 故障排除执行以下操作：

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
oc get pod | grep rook-ceph-mon
```

将 MYPOD 设置为标识为问题 pod 的 pod 的变量：

# Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
MYPOD=<pod_name>

<pod_name>: 指定识别为问题 pod 的 pod 的名称。

查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：

$ oc describe pod/${MYPOD}

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：

$ oc logs pod/${MYPOD}

重要

如果分配了节点，请检查节点上的 kubelet。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：

$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.12. CephMonQuorumLost

含义

影响

高

重要

检查是否有网络问题。如果存在网络问题，则需要在进行以下任何故障排除步骤前升级到 OpenShift Data Foundation 团队。

诊断

或者，执行常规 pod 故障排除：

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
oc get pod | grep {ceph-component}
```

将 MYPOD 设置为标识为问题 pod 的 pod 的变量：

# Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
MYPOD=<pod_name>

<pod_name>: 指定识别为问题 pod 的 pod 的名称。

查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：

$ oc describe pod/${MYPOD}

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：

$ oc logs pod/${MYPOD}

重要

如果分配了节点，请检查节点上的 kubelet。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：

$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.13. CephMonVersionMismatch

含义	通常，这个警报会在升级过程中触发，这需要很长时间。
影响	Medium

诊断

检查 ocs-operator 订阅状态和 Operator pod 健康状况，以检查 Operator 升级是否正在进行。

检查 ocs-operator 订阅健康状况。

$ oc get sub $(oc get pods -n openshift-storage | grep -v ocs-operator) -n openshift-storage -o json | jq .status.conditions

状态条件类型是 CatalogSourcesUnhealthy,InstallPlanMissing,InstallPlanPending, 和 InstallPlanFailed。每种类型的状态应当是 False。

输出示例：

[
  {
    "lastTransitionTime": "2021-01-26T19:21:37Z",
    "message": "all available catalogsources are healthy",
    "reason": "AllCatalogSourcesHealthy",
    "status": "False",
    "type": "CatalogSourcesUnhealthy"
  }
]

示例输出显示 CatalogSourcesUnHealthly 类型的 False 状态，这意味着目录源处于健康状态。

检查 OCS operator pod 状态，以查看正在进行中的 OCS operator 是否升级。
```
$ oc get pod -n openshift-storage | grep ocs-operator OCSOP=$(oc get pod -n openshift-storage -o custom-columns=POD:.metadata.name --no-headers | grep ocs-operator) echo $OCSOP oc get pod/${OCSOP} -n openshift-storage oc describe pod/${OCSOP} -n openshift-storage
```
如果您确定"ocs-operator"正在进行中，请等待 5 分钟，并且此警报应自行解决。如果您等待或看到不同的错误状态条件，请继续故障排除。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：
```
$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6
```

6.3.14. CephNodeDown

含义	运行 Ceph pod 的节点已停机。虽然存储操作将继续工作，因为 Ceph 旨在处理节点故障，但建议解决这个问题，以最大程度降低另一个节点停机并影响存储功能的风险。
影响	Medium

诊断

列出运行和失败的所有 pod：
```
oc -n openshift-storage get pods
```
重要
确保您满足 OpenShift Data Foundation 资源要求，以便将对象存储设备(OSD) pod 调度到新节点上。这可能需要几分钟时间，因为 Ceph 集群恢复故障的数据，但现在恢复 OSD。要监视此恢复，请确保 OSD pod 正确放置到新的 worker 节点上。
检查之前失败的 OSD pod 是否现在是否正在运行：
```
oc -n openshift-storage get pods
```
如果之前出现故障的 OSD pod 没有调度，请使用 describe 命令并检查事件，因为 pod 无法重新调度的原因。

描述故障 OSD pod 的事件：

oc -n openshift-storage get pods | grep osd

查找一个或多个失败的 OSD pod：
```
oc -n openshift-storage describe pods/<osd_podname_ from_the_ previous step>
```
在 events 部分中，查找失败的原因，如不满足资源。
另外，您可以使用 rook-ceph-toolbox 来监控恢复。此步骤是可选的，但对大型 Ceph 集群非常有用。要访问 toolbox，请运行以下命令：
```
TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc rsh -n openshift-storage $TOOLS_POD
```
在 rsh 命令提示符中运行以下命令，并在 io 部分监视 "recovery"：
```
ceph status
```
确定是否有失败的节点。
1. 获取 worker 节点列表，并检查节点状态：
```
oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'
```
2. 描述处于 NotReady 状态的节点以获取有关故障的更多信息：
```
oc describe node <node_name>
```

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：
```
$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6
```

6.3.15. CephOSDCriticallyFull

含义	一个对象存储设备(OSD)是完全的。立即扩展集群。
影响	高

诊断

删除数据以释放存储空间: 您可以删除数据，集群将通过自我修复过程来解析警报。

重要

这仅适用于接近或完全完全的 OpenShift Data Foundation 集群，它们不适用于只读模式。只读模式可防止任何包含删除数据的更改，即删除持久性卷声明(PVC)、持久性卷(PV)或两者。

扩展存储容量: 当前存储大小小于 1 TB

您必须首先评估扩展的功能。对于添加的每个 1TB 存储，集群需要有 3 个节点，每个节点都有最少可用 2 个 vCPU 和 8 GiB 内存。

您可以通过附加组件将存储容量增加到 4 TB，集群将通过自我修复过程解决警报。如果没有满足最低 vCPU 和内存资源要求，则需要在集群中添加 3 个额外的 worker 节点。

缓解方案

如果您的当前存储大小等于 4 TB，请联系红帽支持。

可选：运行以下命令来收集 Ceph 集群的调试信息：

$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6

6.3.16. CephOSDDiskNotResponding

含义	磁盘设备没有响应。检查所有对象存储设备(OSD)是否已启动并运行。
影响	Medium

诊断

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
$ oc get pod | grep rook-ceph
```
将 MYPOD 设置为标识为问题 pod 的 pod 的变量：
```
# Examine the output for a rook-ceph that is in the pending state, not running or not ready
MYPOD=<pod_name>
```
<pod_name>
指定识别为问题 pod 的 pod 的名称。
查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：
```
$ oc describe pod/${MYPOD}
```

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：
```
$ oc logs pod/${MYPOD}
```
重要
- 如果分配了节点，请检查节点上的 kubelet。
- 如果正在运行的 pod 的基本健康状况，则验证节点上的节点关联性和资源可用性，请运行 Ceph 工具来获取存储组件的状态。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：
```
$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6
```

6.3.17. CephOSDDiskUnavailable

含义	一个主机上无法访问磁盘设备，其对应的对象存储设备(OSD)被 Ceph 集群标记为 out。当 Ceph 节点无法在 10 分钟内恢复时，会引发此警报。
影响	高

诊断

确定失败的节点

获取 worker 节点列表，并检查节点状态：

oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'

描述处于 NotReady 状态的节点以获取有关故障的更多信息：
```
oc describe node <node_name>
```

6.3.18. CephOSDFlapping

含义	在最后 5 分钟内，存储守护进程已重启 5 次。检查 pod 事件或 Ceph 状态，以查找原因。
影响	高

诊断

按照 Red Hat Ceph Storage 故障排除指南中的 Flapping OSD 部分的步骤进行操作。

或者，请按照常规 podtroublshooting 的步骤操作：

Pod 状态：Pending

检查资源问题、待处理持久性卷声明(PVC)、节点分配和 kubelet 问题：
```
$ oc project openshift-storage
```
```
$ oc get pod | grep rook-ceph
```
将 MYPOD 设置为标识为问题 pod 的 pod 的变量：
```
# Examine the output for a rook-ceph that is in the pending state, not running or not ready
MYPOD=<pod_name>
```
<pod_name>
指定识别为问题 pod 的 pod 的名称。
查找资源限制或待处理的 PVC。否则，检查节点分配：
```
$ oc get pod/${MYPOD} -o wide
```

Pod 状态： NOT pending, running, but not ready

检查就绪度探测：
```
$ oc describe pod/${MYPOD}
```

Pod 状态：非待处理，但没有运行

检查应用程序或镜像问题：
```
$ oc logs pod/${MYPOD}
```
重要
- 如果分配了节点，请检查节点上的 kubelet。
- 如果正在运行的 pod 的基本健康状况，则验证节点上的节点关联性和资源可用性，请运行 Ceph 工具来获取存储组件的状态。

缓解方案

调试日志信息

此步骤是可选的。运行以下命令来收集 Ceph 集群的调试信息：
```
$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6
```

6.3.19. CephOSDNearFull

含义	后端存储设备对象存储设备(OSD)的利用率在主机上已超过 75%。
影响	高

缓解方案

释放集群中的一些空间、扩展存储集群或联系红帽支持。有关扩展存储的更多信息，请参阅扩展存储指南。

6.3.20. CephOSDSlowOps

含义	请求较慢的对象存储设备(OSD)是每个无法在 `osd_op_complaint_time` 参数定义的时间内每秒 I/O 操作(IOPS)提供服务。默认情况下，此参数被设置为 30 秒。
影响	Medium

诊断

有关使用 Openshift 控制台获取有关较慢请求的更多信息。

访问 OSD pod 终端，并运行以下命令：
```
$ ceph daemon osd.<id> ops
```
```
$ ceph daemon osd.<id> dump_historic_ops
```
注意
OSD 的数量在容器集名称中看到。例如，在 rook-ceph-osd-0-5d86d4d8d4-zlqkx 中，&lt;0&gt; 是 OSD。

缓解方案

OSD 请求速度较慢的主要原因是：与底层硬件或基础架构相关的问题，如磁盘驱动器、主机、机架或网络交换机。使用 Openshift 监控控制台查找集群资源的警报或错误。这可让您了解 OSD 中缓慢操作的根本原因。与网络相关的问题。这些问题通常与 flapping OSD 相关。请参阅 Red Hat Ceph Storage 故障排除指南中的 Flapping OSD 部分（如果是一个网络问题，请升级到 OpenShift Data Foundation 团队负载）。使用 Openshift 控制台查看 OSD pod 的指标以及运行 OSD 的节点。添加或分配更多资源可以是可能的解决方案。

6.3.21. CephOSDVersionMismatch

含义	通常，这个警报会在升级过程中触发，这需要很长时间。
影响	Medium

诊断

检查 ocs-operator 订阅状态和 Operator pod 健康状况，以检查 Operator 升级是否正在进行。

检查 ocs-operator 订阅健康状况。

$ oc get sub $(oc get pods -n openshift-storage | grep -v ocs-operator) -n openshift-storage -o json | jq .status.conditions

状态条件类型是 CatalogSourcesUnhealthy,InstallPlanMissing,InstallPlanPending, 和 InstallPlanFailed。每种类型的状态应当是 False。

输出示例：

[
  {
    "lastTransitionTime": "2021-01-26T19:21:37Z",
    "message": "all available catalogsources are healthy",
    "reason": "AllCatalogSourcesHealthy",
    "status": "False",
    "type": "CatalogSourcesUnhealthy"
  }
]

示例输出显示 CatalogSourcesUnHealthly 类型的 False 状态，这意味着目录源处于健康状态。

检查 OCS operator pod 状态，以查看正在进行中的 OCS operator 是否升级。
```
$ oc get pod -n openshift-storage | grep ocs-operator OCSOP=$(oc get pod -n openshift-storage -o custom-columns=POD:.metadata.name --no-headers | grep ocs-operator) echo $OCSOP oc get pod/${OCSOP} -n openshift-storage oc describe pod/${OCSOP} -n openshift-storage
```
如果您确定"ocs-operator"正在进行中，请等待 5 分钟，并且此警报应自行解决。如果您等待或看到不同的错误状态条件，请继续故障排除。

6.3.22. CephPGRepairTakingTooLong

含义	自我修复操作用时过长。
影响	高

诊断

检查放置组(PG)是否不一致，并修复它们。有关更多信息，请参阅 Ceph 中的红帽知识库解决方案 Handle Inconsistent Placement groups。

6.3.23. CephPoolQuotaBytesCriticallyExhausted

含义	已达到一个或多个池，或者非常接近到达其配额。触发此错误条件的阈值由 `mon_pool_quota_crit_threshold` 配置选项控制。
影响	高

缓解方案

调整池配额。运行以下命令以完全删除或调整池配额：

ceph osd pool set-quota <pool> max_bytes <bytes>

ceph osd pool set-quota <pool> max_objects <objects>

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

6.3.24. CephPoolQuotaBytesNearExhaustion

含义	一个或多个池正在接近配置的全度阈值。触发此警告条件的一个阈值是 `mon_pool_quota_warn_threshold` 配置选项。
影响	高

缓解方案

调整池配额。运行以下命令以完全删除或调整池配额：

ceph osd pool set-quota <pool> max_bytes <bytes>

ceph osd pool set-quota <pool> max_objects <objects>

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

6.3.25. PersistentVolumeUsageCritical

含义	持久性卷声明(PVC)接近其完整容量，如果未及时处理，可能会导致数据丢失。
影响	高

缓解方案

扩展 PVC 大小以增加容量。

登录 OpenShift Web 控制台。
点 Storage PersistentVolumeClaim。
从 Project 下拉列表中选择 openshift-storage。
在您要扩展的 PVC 中，点击 Action 菜单，点 Action Expand PVC。
将 总大小 更新为所需大小。
单击 Expand。

或者，您可以删除可能会占用空间的不必要的数据。

6.3.26. PersistentVolumeUsageNearFull

含义	持久性卷声明(PVC)接近其完整容量，如果未及时处理，可能会导致数据丢失。
影响	高

缓解方案

扩展 PVC 大小以增加容量。

登录 OpenShift Web 控制台。
点 Storage PersistentVolumeClaim。
从 Project 下拉列表中选择 openshift-storage。
在您要扩展的 PVC 中，点击 Action 菜单，点 Action Expand PVC。
将 总大小 更新为所需大小。
单击 Expand。

或者，您可以删除可能会占用空间的不必要的数据。

6.3. 解决集群警报

6.3.1. CephClusterCriticallyFull

6.3.2. CephClusterErrorState

6.3.3. CephClusterNearFull

6.3.4. CephClusterReadOnly

6.3.5. CephClusterWarningState

6.3.6. CephDataRecoveryTakingTooLong

6.3.7. CephMdsMissingReplicas

6.3.8. CephMgrIsAbsent

6.3.9. CephMgrIsMissingReplicas

6.3.10. CephMonHighNumberOfLeaderChanges

6.3.11. CephMonQuorumAtRisk

6.3.12. CephMonQuorumLost

6.3.13. CephMonVersionMismatch

6.3.14. CephNodeDown

6.3.15. CephOSDCriticallyFull

6.3.16. CephOSDDiskNotResponding

6.3.17. CephOSDDiskUnavailable

6.3.18. CephOSDFlapping

6.3.19. CephOSDNearFull

6.3.20. CephOSDSlowOps

6.3.21. CephOSDVersionMismatch

6.3.22. CephPGRepairTakingTooLong

6.3.23. CephPoolQuotaBytesCriticallyExhausted

6.3.24. CephPoolQuotaBytesNearExhaustion

6.3.25. PersistentVolumeUsageCritical

6.3.26. PersistentVolumeUsageNearFull

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links