OpenShift Data Foundation 故障排除
有关 OpenShift Data Foundation 故障排除的说明
摘要
使开源包含更多
红帽承诺替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、list 和 whitelist。由于此努力的显著性,这些更改将在即将推出的几个版本中逐步实施。详情请查看 CTO Chris Wright 信息。
向红帽文档提供反馈
我们感谢您对文档的输入。请告诉我们如何使其更好。
要提供反馈,请创建一个 Bugzilla ticket:
- 进入 Bugzilla 网站。
- 在 Component 部分中,选择 文档。
- 在 Description 字段中填写您要改进的建议。包括文档相关部分的链接。
- 单击 Submit Bug。
第 1 章 概述
OpenShift Data Foundation 故障排除旨在帮助管理员了解如何排除故障并修复其 Red Hat OpenShift Data Foundation 集群。
大多数故障排除任务都侧重于修复或临时解决方案。本文档根据管理员可能遇到的错误分为多个章节:
- 第 2 章 使用 must-gather 下载日志文件和诊断信息 演示了如何在 OpenShift Data Foundation 中使用 must-gather 工具。
- 第 4 章 故障排除所需的常见日志 演示了如何获取 OpenShift Data Foundation 所需的日志文件。
- 第 7 章 对 OpenShift Data Foundation 中的警报和错误进行故障排除 演示了如何识别遇到的错误并执行必要的操作。
红帽不支持在 OpenShift Data Foundation 集群中运行 Ceph 命令(除非受红帽支持或红帽文档表示),因为如果您运行错误的命令,可能会导致数据丢失。在这种情况下,红帽支持团队只能提供合理的商业努力,可能无法在出现数据丢失时恢复所有数据。
第 2 章 使用 must-gather 下载日志文件和诊断信息
如果 Red Hat OpenShift Data Foundation 无法自动解决问题,请使用 must-gather
工具收集日志文件和诊断信息,以便您或红帽支持可以查看问题并确定解决方案。
当将 Red Hat OpenShift Data Foundation 部署为外部模式时,must-gather
仅从 OpenShift Data Foundation 集群收集日志,且不会从外部 Red Hat Ceph Storage 集群收集调试数据和日志。要从外部 Red Hat Ceph Storage 集群收集调试日志,请参阅 Red Hat Ceph Storage 故障排除指南 并联系您的 Red Hat Ceph Storage 管理员。
先决条件
可选: 如果 OpenShift Data Foundation 在断开连接的环境中部署,请确保将独立的
must-gather
镜像镜像(mirror)到断开连接的环境中可用的镜像 registry。$ oc image mirror registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15 <local-registry>/odf4/odf-must-gather-rhel9:v4.15 [--registry-config=<path-to-the-registry-config>] [--insecure=true]
<local-registry>
- 是本地镜像 registry 可用于断开连接的 OpenShift Container Platform 集群。
<path-to-the-registry-config>
-
是 registry 凭证的路径,默认为
~/.docker/config.json
。 --insecure
- 只有在镜像 registry 不安全时才添加此标志。
如需更多信息,请参阅红帽知识库解决方案:
流程
从连接到 OpenShift Data Foundation 集群的客户端运行
must-gather
命令:$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15 --dest-dir=<directory-name>
<directory-name>
是要将数据写入的目录的名称。
重要对于断开连接的环境部署,将镜像 in-
image 参数替换为
镜像的must-gather
镜像。$ oc adm must-gather --image=<local-registry>/odf4/odf-must-gather-rhel9:v4.15 --dest-dir=<directory-name>
<local-registry>
- 是本地镜像 registry 可用于断开连接的 OpenShift Container Platform 集群。
这会在指定目录中收集以下信息:
- 所有与 Red Hat OpenShift Data Foundation 集群相关的自定义资源(CR)及其命名空间。
- 所有 Red Hat OpenShift Data Foundation 相关 pod 的 Pod 日志。
- 某些标准 Ceph 命令的输出,如 Status、Cluster health 等。
2.1. must-gather 命令的变化
如果一个或多个 master 节点没有处于 Ready 状态,use
-node-name
提供一个状态为 Ready 的 master 节点,以便可以安全地调度must-gather
pod。$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15 --dest-dir=_<directory-name>_ --node-name=_<node-name>_
如果要从特定时间收集信息:
要为收集的日志指定相对时间段,比如在 5 秒或 2 天内,添加
/usr/bin/gather since=<duration>
:$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15 --dest-dir=_<directory-name>_ /usr/bin/gather since=<duration>
要指定收集日志的特定时间,请添加
/usr/bin/gather since-time=<rfc3339-timestamp>
:$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15 --dest-dir=_<directory-name>_ /usr/bin/gather since-time=<rfc3339-timestamp>
按如下方式替换这些命令中的示例值:
- <node-name>
-
如果一个或多个 master 节点没有处于 Ready 状态,请使用此参数提供仍然处于 Ready 状态的 master 节点的名称。这可避免调度错误,确保
must-gather
pod 没有调度到未就绪的 master 节点上。 - <directory-name>
-
must-gather
收集的信息的目录。 - <duration>
-
将收集信息的时间段指定为相对持续时间,例如
5h
(从 5 小时以前开始)。 - <rfc3339-timestamp>
-
指定收集信息的时间周期为 RFC 3339 时间戳,例如
2020-11-10T04:00:00+00:00
( 2020 年 11 月 11 日 4 am UTC)。
2.2. 在模块化模式下运行 must-gather
Red Hat OpenShift Data Foundation must-gather
在某些环境中运行需要很长时间。要避免这种情况,以模块化模式运行 must-gather
,只收集您需要的资源:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15 -- /usr/bin/gather <-arg>
将 < -arg
> 替换为以下参数的一个或多个参数,以指定需要 must-gather 日志的资源。
-o
,--odf
- ODF 日志(包括 Ceph 资源、命名空间资源、集群范围的资源和 Ceph 日志)
-d
,--dr
- DR 日志
-n
,--noobaa
- NooBaa logs
-c
,--ceph
- Ceph 命令和 pod 日志
-CL
,--ceph-logs
- Ceph 守护进程、内核、日志和崩溃报告
-ns
,--namespaced
-
命名空间
资源 -CS
,--clusterscoped
-
集群范围的资源
-pc
,--provider
-
openshift-storage-client
日志来自 provider/consumer 集群(包括 operator 命名空间、Pod、Deployment、secret、configmap 和其他资源下的所有日志) -h
,--help
- 打印帮助信息
如果没有包括 < -arg
>,must-gather
将收集所有日志。
第 3 章 使用 odf-cli
命令
odf-cli
命令及其子命令有助于减少重复性任务并提供更好的体验。您可以从客户门户网站下载 odf-cli
工具。
odf get
命令的子命令
- odf get recovery-profile
显示为 OSD 设置的 recovery-profile 值。默认情况下,如果没有使用
odf set recovery-profile
命令设置值,则会显示空值。设置值后,会显示适当的值。示例:
$ odf get recovery-profile # high_recovery_ops
- ODF 获取健康状况
检查 Ceph 集群的运行状况和常见配置问题。这个命令检查以下内容:
- 至少三个 mon pod 在不同的节点上运行
- mon quorum 和 Ceph 健康详情
- 至少三个 OSD pod 在不同的节点上运行
- 所有 pod 的"Running"状态
- 放置组状态
至少一个 MGR pod 正在运行
示例:
$ odf get health Info: Checking if at least three mon pods are running on different nodes rook-ceph-mon-a-7fb76597dc-98pxz Running openshift-storage ip-10-0-69-145.us-west-1.compute.internal rook-ceph-mon-b-885bdc59c-4vvcm Running openshift-storage ip-10-0-64-239.us-west-1.compute.internal rook-ceph-mon-c-5f59bb5dbc-8vvlg Running openshift-storage ip-10-0-30-197.us-west-1.compute.internal Info: Checking mon quorum and ceph health details Info: HEALTH_OK [...]
- ODF get dr-health
在启用了镜像的集群中,从另一个集群获取集群的连接状态。
cephblockpool
通过启用了镜像功能查询,如果未找到,则会退出相关日志。示例:
$ odf get dr-health Info: fetching the cephblockpools with mirroring enabled Info: found "ocs-storagecluster-cephblockpool" cephblockpool with mirroring enabled Info: running ceph status from peer cluster Info: cluster: id: 9a2e7e55-40e1-4a79-9bfa-c3e4750c6b0f health: HEALTH_OK [...]
- ODF 获取 dr-prereq
检查并获取所有先决条件的状态,以便在一对集群中启用灾难恢复。该命令取对等集群名称作为参数,并使用它来比较当前的集群配置与对等集群配置。根据比较结果,会显示先决条件的状态。
Example
$ odf get dr-prereq peer-cluster-1 Info: Submariner is installed. Info: Globalnet is required. Info: Globalnet is enabled. odf get mon-endpoints Displays the mon endpoints $ odf get dr-prereq peer-cluster-1 Info: Submariner is installed. Info: Globalnet is required. Info: Globalnet is enabled.
odf operator
命令的子命令
- ODF operator rook set
在 rook-ceph-operator config
configmap
中设置提供的属性值示例:
$ odf operator rook set ROOK_LOG_LEVEL DEBUG configmap/rook-ceph-operator-config patched
其中,
ROOK_LOG_LEVEL
可以是DEBUG
、INFO
或WARNING
- ODF operator rook restart
重启 Rook-Ceph operator
示例:
$ odf operator rook restart deployment.apps/rook-ceph-operator restarted
- ODF 恢复 mon-quorum
当大多数 mons 不在仲裁且集群停机时,恢复 mon 仲裁。当大多数 mons 永久丢失时,需要恢复到剩余的 mon 状态,以便再次启动 Ceph 集群。
示例:
$ odf restore mon-quorum c
- ODF restore 已删除 <crd>
当组件、CephClusters、CephFilesystems 和 CephBlockPools 仍然保留数据时,恢复已删除的 Rook CR。通常,当 Rook CR 被删除并保留数据时,Rook operator 不会删除 CR,以确保数据不会丢失,Operator 不会删除 CR 上的终结器。因此,CR 会一直处于 Deleting 状态,集群健康状况不会被保证。升级也会被阻断。此命令有助于在不停机集群的情况下修复 CR。
注意此时会出现一个需要确认进行恢复的警告信息。确认后,您需要输入
继续启动
操作符,然后再次扩展到完整的 mon-quorum。示例:
$ odf restore deleted cephclusters Info: Detecting which resources to restore for crd "cephclusters" Info: Restoring CR my-cluster Warning: The resource my-cluster was found deleted. Do you want to restore it? yes | no [...]
3.1. 配置 Ceph 组件的调试详细程度
您可以通过为 OpenShift Data Foundation 的特定 Ceph 子系统启用或增加日志调试来配置 Ceph 组件的详细程度。有关 Ceph 子系统和可更新的日志级别的信息,请参阅 Ceph 子系统默认日志记录级别值。
流程
为 Ceph 守护进程设置日志级别:
$ odf set ceph log-level <ceph-subsystem1> <ceph-subsystem2> <log-level>
其中
ceph-subsystem
可以是osd
、mds
或mon
。例如,
$ odf set ceph log-level osd crush 20
$ odf set ceph log-level mds crush 20
$ odf set ceph log-level mon crush 20
第 4 章 故障排除所需的常见日志
列出了一些用于对 OpenShift Data Foundation 进行故障排除的常用日志,以及用于生成它们的命令。
为特定 pod 生成日志:
$ oc logs <pod-name> -n <namespace>
为 Ceph 或 OpenShift Data Foundation 集群生成日志:
$ oc logs rook-ceph-operator-<ID> -n openshift-storage
重要目前,rook-ceph-operator 日志不会提供有关故障的任何信息,这在故障排除过程中充当一个限制,请参阅为 rook-ceph-operator 启用和禁用 debug 日志。
为 cephfs 或 rbd 等插件 pod 生成日志,以检测 app-pod 挂载中的任何问题:
$ oc logs csi-cephfsplugin-<ID> -n openshift-storage -c csi-cephfsplugin
$ oc logs csi-rbdplugin-<ID> -n openshift-storage -c csi-rbdplugin
为 CSI pod 中的所有容器生成日志:
$ oc logs csi-cephfsplugin-<ID> -n openshift-storage --all-containers
$ oc logs csi-rbdplugin-<ID> -n openshift-storage --all-containers
为 cephfs 或 rbd provisioner pod 生成日志,以检测 PVC 没有处于 BOUND 状态的问题:
$ oc logs csi-cephfsplugin-provisioner-<ID> -n openshift-storage -c csi-cephfsplugin
$ oc logs csi-rbdplugin-provisioner-<ID> -n openshift-storage -c csi-rbdplugin
为 CSI pod 中的所有容器生成日志:
$ oc logs csi-cephfsplugin-provisioner-<ID> -n openshift-storage --all-containers
$ oc logs csi-rbdplugin-provisioner-<ID> -n openshift-storage --all-containers
使用 cluster-info 命令生成 OpenShift Data Foundation 日志:
$ oc cluster-info dump -n openshift-storage --output-directory=<directory-name>
使用 Local Storage Operator 时,可以使用 cluster-info 命令生成日志:
$ oc cluster-info dump -n openshift-local-storage --output-directory=<directory-name>
检查 OpenShift Data Foundation 操作器日志和事件。
检查 Operator 日志:
# oc logs <ocs-operator> -n openshift-storage
- <ocs-operator>
# oc get pods -n openshift-storage | grep -i "ocs-operator" | awk '{print $1}'
检查 Operator 事件 :
# oc get events --sort-by=metadata.creationTimestamp -n openshift-storage
获取 OpenShift Data Foundation 操作器版本和频道。
# oc get csv -n openshift-storage
输出示例:
NAME DISPLAY VERSION REPLACES PHASE mcg-operator.v4.15.0 NooBaa Operator 4.15.0 Succeeded ocs-operator.v4.15.0 OpenShift Container Storage 4.15.0 Succeeded odf-csi-addons-operator.v4.15.0 CSI Addons 4.15.0 Succeeded odf-operator.v4.15.0 OpenShift Data Foundation 4.15.0 Succeeded
# oc get subs -n openshift-storage
输出示例:
NAME PACKAGE SOURCE CHANNEL mcg-operator-stable-4.15-redhat-operators-openshift-marketplace mcg-operator redhat-operators stable-4.15 ocs-operator-stable-4.15-redhat-operators-openshift-marketplace ocs-operator redhat-operators stable-4.15 odf-csi-addons-operator odf-csi-addons-operator redhat-operators stable-4.15 odf-operator odf-operator redhat-operators stable-4.15
确认已创建了
安装计划
。# oc get installplan -n openshift-storage
在更新 OpenShift Data Foundation 后,验证组件的镜像。
检查您要验证镜像运行的组件 pod 的节点。
# oc get pods -o wide | grep <component-name>
例如:
# oc get pods -o wide | grep rook-ceph-operator
输出示例:
rook-ceph-operator-566cc677fd-bjqnb 1/1 Running 20 4h6m 10.128.2.5 rook-ceph-operator-566cc677fd-bjqnb 1/1 Running 20 4h6m 10.128.2.5 dell-r440-12.gsslab.pnq2.redhat.com <none> <none> <none> <none>
Dell-r440-12.gsslab.pnq2.redhat.com
是 node-name。检查镜像 ID。
# oc debug node/<node name>
<node-name>
是您要验证镜像运行的组件 pod 的节点名称。
# chroot /host
# crictl images | grep <component>
例如:
# crictl images | grep rook-ceph
记录
IMAGEID
,并将其映射到 Rook Ceph Operator 页面中的 Digest ID。
其他资源
4.1. 调整日志的详细程度
调试日志消耗的空间量可能会成为严重的问题。Red Hat OpenShift Data Foundation 提供了一种调整方法,因此控制调试日志要使用的存储量。
要调整调试日志的详细程度,您可以调整负责容器存储接口(CSI)操作的容器的日志级别。在容器的 yaml 文件中,调整以下参数来设置日志级别:
-
CSI_LOG_LEVEL
- 默认为5
-
CSI_SIDECAR_LOG_LEVEL
- defaults to1
支持的值有 0
到 5
。0
用于常规使用的日志,5
用于追踪级别的详细程度。
第 5 章 部署后覆盖 OpenShift Data Foundation 的集群范围默认节点选择器
当将集群范围的默认节点选择器用于 OpenShift Data Foundation 时,由容器存储接口(CSI) daemonset 生成的 pod 只能在与选择器匹配的节点上启动。要能够从与选择器不匹配的节点使用 OpenShift Data Foundation,请在命令行界面中执行以下步骤来覆盖 集群范围的默认节点选择器
:
流程
为 openshift-storage 命名空间指定一个空白节点选择器。
$ oc annotate namespace openshift-storage openshift.io/node-selector=
删除 DaemonSet 生成的原始 pod。
oc delete pod -l app=csi-cephfsplugin -n openshift-storage oc delete pod -l app=csi-rbdplugin -n openshift-storage
第 6 章 加密令牌已删除或过期
如果您的密钥管理系统的加密令牌被删除或过期,请使用以下步骤更新令牌。
先决条件
- 确保您有一个与已删除或过期令牌相同的策略的新令牌
流程
- 登录 OpenShift Container Platform Web 控制台。
- 点 Workloads → Secrets
更新用于集群范围加密的 ocs-kms-token :
-
将 Project 设置为
openshift-storage
。 - 点 ocs-kms-token → Actions → Edit Secret。
- 在 Value 字段中拖放或上传您的加密令牌文件。令牌可以是可复制和粘贴的文件或文本。
- 点 Save。
-
将 Project 设置为
为带有加密持久性卷的给定项目或命名空间更新 ceph-csi-kms-token :
- 选择所需的 项目。
- 点 ceph-csi-kms-token → Actions → Edit Secret。
- 在 Value 字段中拖放或上传您的加密令牌文件。令牌可以是可复制和粘贴的文件或文本。
点 Save。
注意只有在所有使用
ceph-csi-kms-token
的加密 PVC 已被删除后,才能删除令牌。
第 7 章 对 OpenShift Data Foundation 中的警报和错误进行故障排除
7.1. 解决警报和错误
Red Hat OpenShift Data Foundation 可以检测并自动解决许多常见的故障情况。但是,有些问题需要管理员干预。
要了解当前触发的错误,请查看以下位置之一:
- observe → Alerting → Firing 选项
- Home → Overview → Cluster 标签页
- Storage → Data Foundation → Storage System → storage system link in the pop up → Overview → Block and File 标签页
- Storage → Data Foundation → Storage System → storage system link in the pop up → Overview → Object 标签页
复制显示的错误并在以下部分搜索它以了解其严重性和解决方案:
名称 :Ceph
Message
Description 严重性: 警告 解决方案 :修复 流程 :检查用户界面和日志,并验证更新是否正在进行中。
|
名称:
Message
Description 严重性: 警告 解决方案 :修复 流程 :检查用户界面和日志,并验证更新是否正在进行中。
|
名称 :
消息 :
描述 : 严重性: 关键 解决方案 :修复 流程 :删除不必要的数据或扩展集群。 |
名称 :
修复了:
描述 : 严重性: 警告 解决方案 :修复 流程 :删除不必要的数据或扩展集群。 |
Name:
Message
描述 严重性: 警告 解决方案 :临时解决方案 流程 :查找不健康的存储桶的错误代码 |
Name:
Message
Description 严重性: 警告 解决方案 :修复 |
Name:
Message:
描述 严重性: 警告 解决方案 :修复 流程 :查找不健康的存储桶的错误代码 |
Name:
Message 描述: 'Minimum required replicas for storage metadata service not available. 可能会影响存储集群的工作。 严重性: 警告 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
描述: 严重性级别: Critical 解决方案 :请联系红帽支持 流程 :
|
名称 :Ceph
Message:
描述: 严重性级别: Critical 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
描述: 严重性级别: Critical 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
Description: 严重性: 警告 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
描述 严重性: 警告 解决方案 :请联系红帽支持 |
名称 :
Message:
描述 严重性级别: Critical 解决方案 :请联系红帽支持 |
名称 :
Message:
描述 严重性级别: Critical 解决方案 :请联系红帽支持 |
名称 :
Message:
描述 : 严重性: 警告 解决方案 :请联系红帽支持 |
名称 :
Message:
描述: 严重性: 警告 解决方案 :请联系红帽支持 |
名称 :
消息 :
描述: 严重性级别: Critical 解决方案 :请联系红帽支持 |
名称 :
Message:
描述: 严重性级别: Critical 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
描述: 严重性级别: Critical 解决方案 :请联系红帽支持 |
名称 :
消息: 描述 :对一个或多个应用程序失败。 严重性: 警告 解决方案 :请联系红帽支持 |
名称 :
Message: 描述 :对整个集群进行灾难恢复失败。Mirror daemon is in unhealthy status for more than 1m.对这个集群进行镜像(mirror)无法正常工作。 严重性级别: Critical 解决方案 :请联系红帽支持 |
7.2. 解决集群健康问题
Red Hat Ceph Storage 集群可以引发在 OpenShift Data Foundation 用户界面中显示的一组有限健康消息。它们定义为具有唯一标识符的健康检查。标识符是一个伪可读字符串,旨在使工具能够了解健康检查,并以反应其含义的方式呈现它们。如需更多信息和故障排除,请单击下面的健康代码。
健康代码 | 描述 |
---|---|
一个或多个 Ceph 监控器在磁盘空间上较低。 |
7.2.1. MON_DISK_LOW
如果将 monitor 数据库存储为百分比的文件系统中的可用空间下降到 mon_data_avail_warn
下,则会触发此警报(默认值:15%)。这可能表示系统上的其他进程或用户正在填满监控器使用的相同文件系统。它还可能表明 monitor 的数据库比较大。
文件系统的路径因您的 mon 部署而异。您可以找到在 storagecluster.yaml
中部署 mon 的路径。
路径示例:
-
通过 PVC 路径部署的 mon:
/var/lib/ceph/mon
-
通过 hostpath 部署 mon:
/var/lib/rook/mon
要清除空间,请查看文件系统中高的使用文件,并选择要删除的文件。要查看文件,请运行:
# du -a <path-in-the-mon-node> |sort -n -r |head -n10
将 <path-in-the-mon-node
> 替换为部署 mons 的文件系统的路径。
7.3. 解决集群警报
Red Hat Ceph Storage 集群可以引发的一组有限健康警报,显示在 OpenShift Data Foundation 用户界面中。它们定义为具有唯一标识符的健康警报。标识符是一个伪可读字符串,旨在使工具能够了解健康检查,并以反应其含义的方式呈现它们。点健康警报以了解更多信息和故障排除。
健康警报 | 概述 |
---|---|
存储集群利用率已超过 80%。 | |
存储集群处于错误状态的时间超过 10 分钟。 | |
存储集群接近满容量。需要删除数据或集群扩展。 | |
存储集群现在是只读的,需要立即删除数据或集群扩展。 | |
存储集群处于警告状态超过 10 分钟。 | |
Data recovery has been active for too long. | |
MDS 守护进程的 Ceph 元数据服务(MDS)缓存使用情况已超过 | |
MDS 守护进程的 Ceph MDS CPU 使用量超过阈值以达到适当的性能。 | |
存储元数据服务不可用所需的最小副本。可能会影响存储集群的工作。 | |
Ceph Manager 已从 Prometheus 目标发现中消失。 | |
Ceph 管理器缺少副本。这会破坏健康状态报告,并将导致 | |
Ceph 监控领导正在改变异常次数。 | |
Storage cluster quorum is low. | |
监控存储集群中的 pod 数量不够。 | |
运行不同版本的 Ceph Mon 组件。 | |
存储节点关闭。立即检查节点。该警报应包含节点名称。 | |
后端对象存储设备(OSD)的利用率已超过 80%。立即释放一些空间或扩展存储集群或联系支持。 | |
磁盘设备在其中一个主机上没有响应。 | |
其中一个主机上无法访问磁盘设备。 | |
Ceph 存储 OSD 阻塞. | |
其中一个 OSD 存储设备接近满。 | |
OSD 请求用时过长才能处理。 | |
运行不同版本的 Ceph OSD 组件。 | |
自我修复操作用时过长。 | |
存储池配额使用量已超过 90%。 | |
存储池配额使用量已超过 70%。 | |
特定 pod 上的 OSD 容器中的 CPU 使用量超过 80%,可能会影响 OSD 的性能。 | |
持久性卷声明用量超过其容量的 85%。 | |
持久性卷声明用量超过 75% 的容量。 |
7.3.1. CephClusterCriticallyFull
含义 | 存储集群利用率已超过 80%,并将在 85% 时变得只读。当利用率超过 85% 后,Ceph 集群将变为只读。立即释放一些空间或立即扩展存储集群。在此警报之前,通常会看到与 Object Storage Device (OSD)已满或接近满相关的警报。 |
影响 | high |
诊断
- 扩展存储
- 根据集群的类型,您需要添加存储设备、节点或两者。如需更多信息,请参阅扩展存储指南。
缓解方案
- 删除信息
- 如果无法扩展集群,则需要删除信息以释放一些空间。
7.3.2. CephClusterErrorState
含义 |
此警报反映了存储集群在不可接受的时间内处于 |
影响 | critical |
诊断
- Pod 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要- 如果分配了节点,请检查节点上的 kubelet。
- 如果正在运行的 pod 的基本健康状况,验证节点上的节点关联性和资源可用性,请运行 Ceph 工具来获取存储组件的状态。
缓解方案
- 调试日志信息
此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.3. CephClusterNearFull
含义 | 存储集群利用率已超过 75%,并将在 85% 时变得只读。释放一些空间或扩展存储集群。 |
影响 | critical |
诊断
- 扩展存储
- 根据集群的类型,您需要添加存储设备、节点或两者。如需更多信息,请参阅扩展存储指南。
缓解方案
- 删除信息
- 如果无法扩展集群,则需要删除信息以释放一些空间。
7.3.4. CephClusterReadOnly
含义 | Storage cluster utilization has crossed 85%,现在将变为只读。立即释放一些空间或立即扩展存储集群。 |
影响 | critical |
诊断
- 扩展存储
- 根据集群的类型,您需要添加存储设备、节点或两者。如需更多信息,请参阅扩展存储指南。
缓解方案
- 删除信息
- 如果无法扩展集群,则需要删除信息以释放一些空间。
7.3.5. CephClusterWarningState
含义 | 此警报反映了存储集群在不可接受的时间处于警告状态。虽然存储操作将继续在这个状态下工作,但建议修复错误,以便集群不会处于错误状态。检查此之前可能触发的其他警报,并首先对这些警报进行故障排除。 |
影响 | high |
诊断
- Pod 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要如果分配了节点,请检查节点上的 kubelet。
缓解方案
- 调试日志信息
- 此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.6. CephDataRecoveryTakingTooLong
含义 | Data recovery is slow。检查所有对象存储设备(OSD)是否已启动并在运行。 |
影响 | high |
诊断
- Pod 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要如果分配了节点,请检查节点上的 kubelet。
缓解方案
- 调试日志信息
- 此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.7. CephMdsCacheUsageHigh
含义 |
当存储元数据服务(MDS)无法将其缓存使用量保留在 |
影响 | high |
诊断
MDS 会尝试在其缓存中修剪未使用的元数据并调用客户端缓存中缓存的项目,以保留 mds_cache_memory_limit
的保留。由于多个客户端通过处理文件,因此 MDS 可能会超出这个限制,因为客户端重新调用了这个限制。
缓解方案
确保为 MDS 缓存置备了足够的内存。MDS pod 的内存资源需要在 ocs-storageCluster
中更新,以增加 mds_cache_memory_limit
。运行以下命令来设置 MDS pod 的内存,如 16GB:
$ oc patch -n openshift-storage storagecluster ocs-storagecluster \ --type merge \ --patch '{"spec": {"resources": {"mds": {"limits": {"memory": "16Gi"},"requests": {"memory": "16Gi"}}}}}'
OpenShift Data Foundation 自动将 mds_cache_memory_limit
设置为 MDS pod 内存限值的一半。如果使用上一命令将内存设置为 8GB,则 operator 会将 MDS 缓存内存限值设置为 4GB。
7.3.8. CephMdsCpuUsageHigh
含义 | 存储元数据服务(MDS)提供文件系统元数据。MDS 对于任何文件创建、重命名、删除和更新操作至关重要。默认情况下,MDS 被分配两个或三个 CPU。只要没有太多元数据操作,这就不会造成问题。当元数据操作负载增加足以触发此警报时,这意味着默认的 CPU 分配无法与负载一起正常工作。您需要提高 CPU 分配或运行多个活跃 MDS 服务器。 |
影响 | high |
诊断
点 Workloads → Pods。选择对应的 MDS pod,再点 Metrics 选项卡。您将看到已分配和使用的 CPU。默认情况下,如果使用的 CPU 为 67% 的 CPU 为 6 小时,则会触发警报。如果是这种情况,请按照缓解方案部分中的步骤操作。
缓解方案
您需要增加分配的 CPU 或运行多个活跃 MDS。
使用以下命令为 MDS 设置分配的 CPU 数量,例如 8:
oc patch -n openshift-storage storagecluster ocs-storagecluster \ --type merge \ --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "8"}, "requests": {"cpu": "8"}}}}}'
要运行多个活跃 MDS 服务器,请使用以下命令:
oc patch -n openshift-storage storagecluster ocs-storagecluster\ --type merge \ --patch '{"spec": {"managedResources": {"cephFilesystems":{"activeMetadataServers": 2}}}}'
请确定您有足够的 CPU 为 MDS 置备,具体取决于负载。
始终通过 1
增加 activeMetadataServers
。只有在您有多个 PV 时,activeMetadataServers
的扩展才可以正常工作。如果只有一个 PV 导致 CPU 负载,请查看增加 CPU 资源,如上所述。
7.3.9. CephMdsMissingReplicas
含义 | 存储元数据服务(MDS)的最低要求副本不可用。MDS 负责归档元数据。MDS 服务降级可能会影响存储集群的工作方式(与 CephFS 存储类相关),应尽快修复。 |
影响 | high |
诊断
- Pod 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要如果分配了节点,请检查节点上的 kubelet。
缓解方案
- 调试日志信息
- 此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.10. CephMgrIsAbsent
含义 | 没有 Ceph 管理器运行集群的监控。持久性卷声明(PVC)创建和删除请求应尽快解决。 |
影响 | high |
诊断
验证
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 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要如果分配了节点,请检查节点上的 kubelet。
缓解方案
- 调试日志信息
- 此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.11. CephMgrIsMissingReplicas
含义 | 要解决此警报,您需要确定 Ceph 管理器消失的原因,并在需要时重启。 |
影响 | high |
诊断
- Pod 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要如果分配了节点,请检查节点上的 kubelet。
缓解方案
- 调试日志信息
- 此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.12. CephMonHighNumberOfLeaderChanges
含义 | 在 Ceph 集群中,有一组冗余监控 pod,它们存储了关于存储集群的重要信息。定期监控 pod 同步,以获取有关存储集群的信息。第一个监控 pod,以获取最新信息成为领导信息,其他监控 pod 将在请求领导后启动其同步过程。在一个或多个 monitor pod 中网络连接或其他类型的问题会造成领导异常更改。这种情况可能会对存储集群性能造成负面影响。 |
影响 | 中 |
检查是否存在网络问题。如果存在网络问题,则需要升级到 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 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
- 检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要如果分配了节点,请检查节点上的 kubelet。
缓解方案
- 调试日志信息
- 此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.13. CephMonQuorumAtRisk
含义 | 多个 MON 协同工作,以提供冗余。每个 MON 都保留元数据的副本。集群使用 3 个 MON 部署,需要启动并运行 2 个或更多 MON,以便运行存储操作。如果丢失仲裁,对数据的访问会面临风险。 |
影响 | high |
诊断
恢复 Ceph MON 仲裁。如需更多信息,请参阅故障排除指南中的 在 OpenShift Data Foundation 中恢复 ceph-monitor 仲裁。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/troubleshooting_openshift_data_foundation/index#restoring-ceph-monitor-quorum-in-openshift-data-foundation_rhodf如果 Ceph MON Quorum 恢复失败,请按照一般的 pod 故障排除来解决这个问题。
对常规 pod 故障排除执行以下操作:
- Pod 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
- 检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要如果分配了节点,请检查节点上的 kubelet。
缓解方案
- 调试日志信息
- 此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.14. CephMonQuorumLost
含义 | 在 Ceph 集群中,有一组冗余监控 pod,它们存储了关于存储集群的重要信息。定期监控 pod 同步,以获取有关存储集群的信息。第一个监控 pod,以获取最新信息成为领导信息,其他监控 pod 将在请求领导后启动其同步过程。在一个或多个 monitor pod 中网络连接或其他类型的问题会造成领导异常更改。这种情况可能会对存储集群性能造成负面影响。 |
影响 | high |
检查是否存在网络问题。如果存在网络问题,则需要升级到 OpenShift Data Foundation 团队,然后才能进行以下故障排除步骤。
诊断
恢复 Ceph MON 仲裁。如需更多信息,请参阅故障排除指南中的 在 OpenShift Data Foundation 中恢复 ceph-monitor 仲裁。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/troubleshooting_openshift_data_foundation/index#restoring-ceph-monitor-quorum-in-openshift-data-foundation_rhodf如果 Ceph MON Quorum 恢复失败,请按照一般的 pod 故障排除来解决这个问题。
或者,执行常规 pod 故障排除:
- Pod 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
- 检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要如果分配了节点,请检查节点上的 kubelet。
缓解方案
- 调试日志信息
- 此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.15. CephMonVersionMismatch
含义 | 通常,这个警报会在升级过程中触发,这需要很长时间。 |
影响 | 中 |
诊断
检查 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' 处于 progress 状态,请等待 5 分钟,此警报应该解析自己。如果您等待或看到不同的错误状态条件,请继续故障排除。
缓解方案
- 调试日志信息
此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.16. CephNodeDown
含义 | 运行 Ceph pod 的节点已停机。虽然存储操作将继续,因为 Ceph 旨在处理节点故障,但建议解决这个问题,以最大程度降低另一个节点停机并影响存储功能的风险。 |
影响 | 中 |
诊断
列出运行和失败的所有 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
确定是否有失败的节点。
获取 worker 节点列表,并检查节点状态:
oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'
描述处于
NotReady
状态的节点,以获取有关故障的更多信息:oc describe node <node_name>
缓解方案
- 调试日志信息
此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.17. CephOSDCriticallyFull
含义 | 一个对象存储设备(OSD)非常满。立即扩展集群。 |
影响 | high |
诊断
- 删除数据以释放存储空间
- 您可以删除数据,集群将通过自我修复进程解析警报。
这只适用于接近或满的 OpenShift Data Foundation 集群,但不适用于只读模式。只读模式可防止任何包括删除数据的更改,即删除持久性卷声明(PVC)、持久性卷(PV)或两者。
- 扩展存储容量
- 当前存储大小小于 1 TB
您必须首先评估扩展能力。对于每个添加 1 TB 的存储,集群需要有 3 个节点,每个节点至少有 2 个 vCPU 和 8 GiB 内存。
您可以通过附加组件将存储容量增加到 4 TB,集群将通过自我修复过程解析警报。如果没有满足最小 vCPU 和内存资源要求,则需要在集群中添加 3 个额外的 worker 节点。
缓解方案
- 如果您的当前存储大小等于 4 TB,请联系红帽支持。
可选: 运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.18. CephOSDDiskNotResponding
含义 | 磁盘设备没有响应。检查所有对象存储设备(OSD)是否已启动并在运行。 |
影响 | 中 |
诊断
- Pod 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要- 如果分配了节点,请检查节点上的 kubelet。
- 如果正在运行的 pod 的基本健康状况,验证节点上的节点关联性和资源可用性,请运行 Ceph 工具来获取存储组件的状态。
缓解方案
- 调试日志信息
此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.20. CephOSDFlapping
含义 | 存储守护进程在最后 5 分钟内重启 5 次。检查 pod 事件或 Ceph 状态以查找原因。 |
影响 | high |
诊断
按照 Red Hat Ceph Storage 故障排除指南中的 Flapping OSD 部分中的步骤进行操作。
或者,按照常规 pod 故障排除的步骤进行操作:
- Pod 状态:待处理
检查资源问题、待处理的 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 status: NOT pending, but not running
检查应用程序或镜像问题:
$ oc logs pod/${MYPOD}
重要- 如果分配了节点,请检查节点上的 kubelet。
- 如果正在运行的 pod 的基本健康状况,验证节点上的节点关联性和资源可用性,请运行 Ceph 工具来获取存储组件的状态。
缓解方案
- 调试日志信息
此步骤是可选的。运行以下命令为 Ceph 集群收集调试信息:
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
7.3.21. CephOSDNearFull
含义 | 在主机上,后端存储设备对象存储设备(OSD)的利用率已超过 75%。 |
影响 | high |
缓解方案
在集群中释放一些空间,扩展存储集群,或联系红帽支持。如需有关扩展存储的更多信息,请参阅扩展存储指南。
7.3.22. CephOSDSlowOps
含义 |
请求较慢的对象存储设备(OSD)是,每个 OSD 无法在 |
影响 | 中 |
诊断
如需有关较慢请求的更多信息,可以使用 Openshift 控制台获得。
访问 OSD pod 终端,并运行以下命令:
$ ceph daemon osd.<id> ops
$ ceph daemon osd.<id> dump_historic_ops
注意pod 名称中看到 OSD 的数量。例如,在
rook-ceph-osd-0-5d86d4d8d4-zlqkx
中,<0>
; 是 OSD。
缓解方案
OSD 请求缓慢的主要原因是:
- 底层硬件或基础架构的问题,如磁盘驱动器、主机、机架或网络交换机。使用 Openshift 监控控制台查找集群资源的警报或错误。这可让您了解 OSD 中缓慢操作的根本原因。
- 与网络相关的问题。这些问题通常与 flapping OSD 连接。请参阅 Red Hat Ceph Storage Troubleshooting Guide 中的 Flapping OSDs 部分
- 如果是网络问题,请升级到 OpenShift Data Foundation 团队
- 系统负载。使用 Openshift 控制台查看 OSD pod 的指标和运行 OSD 的节点。添加或分配更多资源可以是可能的解决方案。
7.3.23. CephOSDVersionMismatch
含义 | 通常,这个警报会在升级过程中触发,这需要很长时间。 |
影响 | 中 |
诊断
检查 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' 处于 progress 状态,请等待 5 分钟,此警报应该解析自己。如果您等待或看到不同的错误状态条件,请继续故障排除。
7.3.24. CephPGRepairTakingTooLong
含义 | 自我修复操作用时过长。 |
影响 | high |
诊断
检查放置组(PG)不一致,并修复它们。有关更多信息,请参阅 Ceph 中的红帽知识库解决方案 Handle Inconsistent Placement Groups。
7.3.25. CephPoolQuotaBytesCriticallyExhausted
含义 |
已达到一个或多个池,或者接近其配额。触发此错误条件的阈值由 |
影响 | high |
缓解方案
调整池配额。运行以下命令以完全删除或调整池配额:
ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>
将 quota 值设置为 0
将禁用配额。
7.3.26. CephPoolQuotaBytesNearExhaustion
含义 |
一个或多个池正在接近配置的全度阈值。触发此警告条件的一个阈值是 |
影响 | high |
缓解方案
调整池配额。运行以下命令以完全删除或调整池配额:
ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>
将 quota 值设置为 0
将禁用配额。
7.3.27. OSDCPULoadHigh
含义 | OSD 是 Ceph 存储中的一个关键组件,负责管理数据放置和恢复。OSD 容器中的高 CPU 使用量建议增加处理需求,这可能会降低存储性能。 |
影响 | high |
诊断
- 导航到 Kubernetes 仪表板或等同功能。
- 访问 Workloads 部分,再选择与 OSD 警报关联的相关 pod。
- 单击 Metrics 选项卡,以查看 OSD 容器的 CPU 指标。
- 验证 CPU 用量在一段时间内超过 80%(如警报配置中指定的情况)。
缓解方案
如果 OSD CPU 使用量始终高,请考虑执行以下步骤:
- 评估整个存储集群性能,并确定 OSD 为高 CPU 使用量做出贡献。
- 通过在现有节点上添加更多新存储设备或使用新存储设备添加新节点来增加集群中的 OSD 数量。查看 扩展存储4 以获得帮助分发负载并提高整体系统性能的说明。
7.3.28. PersistentVolumeUsageCritical
含义 | 持久性卷声明(PVC)接近其全部容量,如果未及时参加,则可能会导致数据丢失。 |
影响 | high |
缓解方案
扩展 PVC 大小以增加容量。
- 登录 OpenShift Web 控制台。
- 点 Storage → PersistentVolumeClaim。
-
从 Project 下拉列表中选择
openshift-storage
。 - 在您要展开的 PVC 中,点击 Action 菜单(&&) → Expand PVC。
- 将 总大小 更新为所需的大小。
- 单击 Expand。
或者,您可以删除可能会占用空间的不必要的数据。
7.3.29. PersistentVolumeUsageNearFull
含义 | 持久性卷声明(PVC)接近其全部容量,如果未及时参加,则可能会导致数据丢失。 |
影响 | high |
缓解方案
扩展 PVC 大小以增加容量。
- 登录 OpenShift Web 控制台。
- 点 Storage → PersistentVolumeClaim。
-
从 Project 下拉列表中选择
openshift-storage
。 - 在您要展开的 PVC 中,点击 Action 菜单(&&) → Expand PVC。
- 将 总大小 更新为所需的大小。
- 单击 Expand。
或者,您可以删除可能会占用空间的不必要的数据。
7.4. 查找不健康存储桶的错误代码
流程
- 在 OpenShift Web 控制台中,点 Storage → Object Storage。
- 点 Object Bucket Claims 选项卡。
-
查找没有处于
Bound
状态的对象存储桶声明(OBC),然后点它。 点击 Events 选项卡,然后执行以下操作之一:
- 查找可能会提示您有关存储桶当前状态的事件。
- 点 YAML 选项卡,并查找 YAML 的 status 和 mode 部分的相关错误。
如果 OBC 处于
Pending
状态,则错误可能会出现在产品日志中。然而,在这种情况下,建议验证提供的所有变量是否正确。
7.5. 查找不健康命名空间存储资源的错误代码
流程
- 在 OpenShift Web 控制台中,点 Storage → Object Storage。
- 点 Namespace Store 选项卡。
-
查找没有处于
Bound
状态的命名空间存储资源,然后点击它。 点击 Events 选项卡,然后执行以下操作之一:
- 查找可能会提示您资源当前状态的事件。
- 点 YAML 选项卡,并查找 YAML 的 status 和 mode 部分的相关错误。
7.6. 恢复 pod
当第一个节点(如 NODE1
)因为一些问题而变为 NotReady 状态时,使用 ReadWriteOnce (RWO)访问模式的 PVC 的托管 pod 会尝试移到第二个节点(如 NODE2),
但会因为 multi-attach 错误而卡住。在这种情况下,您可以使用以下步骤恢复 MON、OSD 和应用容器集。
流程
-
关闭
NODE1
(从 AWS 或 vSphere 端),并确保NODE1
完全关闭。 使用以下命令强制删除
NODE1
上的 pod:$ oc delete pod <pod-name> --grace-period=0 --force
7.7. 从 EBS 卷分离中恢复
当 OSD 磁盘所驻留的 OSD 或 MON 弹性块存储(EBS)卷与 worker Amazon EC2 实例分离时,该卷会在一两分钟内自动重新附加。但是,OSD 容器集进入 CrashLoopBackOff
状态。要恢复 pod 并将 pod 恢复到 Running
状态,您必须重启 EC2 实例。
7.8. 为 rook-ceph-operator 启用和禁用 debug 日志
为 rook-ceph-operator 启用调试日志,以获取有助于对问题进行故障排除的失败信息。
流程
- 启用调试日志
编辑 rook-ceph-operator 的 configmap。
$ oc edit configmap rook-ceph-operator-config
在
rook-ceph-operator-config
yaml 文件中添加ROOK_LOG_LEVEL: DEBUG
参数,以便为 rook-ceph-operator 启用调试日志。… data: # The logging level for the operator: INFO | DEBUG ROOK_LOG_LEVEL: DEBUG
现在,rook-ceph-operator 日志由 debug 信息组成。
- 禁用 debug 日志
编辑 rook-ceph-operator 的 configmap。
$ oc edit configmap rook-ceph-operator-config
在
rook-ceph-operator-config
yaml 文件中添加ROOK_LOG_LEVEL: INFO
参数,以禁用 rook-ceph-operator 的调试日志。… data: # The logging level for the operator: INFO | DEBUG ROOK_LOG_LEVEL: INFO
7.9. 解决低 Ceph 监控器计数警报
CephMonLowNumber 警报显示在 OpenShift Web 控制台的通知面板或 Alert Center 中,当您的内部模式部署有 5 个或更多节点、机架或房间,以及部署中有五或更多个故障域时。您可以增加 Ceph 监视器计数,以提高集群的可用性。
流程
- 在通知面板或 OpenShift Web 控制台的 Alert Center of the CephMonLowNumber 警报中,单击 Configure。
在 Configure Ceph Monitor 弹出窗口中,单击 Update count。
在弹出窗口中,根据失败区域的数量显示推荐的监控器计数。
- 在 Configure CephMon 弹出窗口中,根据推荐的值更新 monitor 数量值,然后单击 Save changes。
7.10. 不健康的块列出节点故障排除
7.10.1. ODFRBDClientBlocked
含义 |
此警报表示 RADOS 块设备(RBD)客户端可能会被 Kubernetes 集群内特定节点上的 Ceph 阻止。当 |
影响 | high |
诊断
RBD 客户端的阻塞列表可能会因为几个因素而发生,如网络或集群较慢。在某些情况下,三个contend 客户端(工作负载、镜像守护进程和 manager/scheduler)之间的专用锁定竞争可能会导致 blocklist。
缓解方案
- 污点列入黑名单的节点:在 Kubernetes 中,请考虑将阻止的节点污点,以将 pod 的驱除触发到另一节点。这个方法依赖于正常卸载/取消映射过程的假设。当 pod 成功被驱除后,会取消包含阻塞的节点,允许清除 blocklist。然后,可以将 pod 移到未包含的节点。
- 重启列入黑名单的节点:如果污点节点并驱除 pod 无法解决阻止列表的问题,可以尝试重启阻塞的节点。此步骤可帮助减少导致黑名单和恢复正常功能的底层问题。
及时调查和解决黑名单问题至关重要,以避免进一步对存储集群的影响。
第 8 章 检查 Local Storage Operator 部署
使用 Local Storage Operator 的 Red Hat OpenShift Data Foundation 集群使用本地存储设备进行部署。要查找您的 OpenShift Data Foundation 的现有集群是否使用本地存储设备进行了部署,请使用以下步骤:
先决条件
-
OpenShift Data Foundation 在
openshift-storage
命名空间中安装并运行。
流程
通过检查与 OpenShift Data Foundation 集群的持久性卷声明(PVC)关联的存储类,您可以确定您的集群是否使用本地存储设备部署。
使用以下命令,检查与 OpenShift Data Foundation 集群 PVC 关联的存储类:
$ oc get pvc -n openshift-storage
检查输出。对于具有 Local Storage Operator 的集群,与
ocs-deviceset
关联的 PVC 使用存储类localblock
。输出结果类似如下:NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-noobaa-db-0 Bound pvc-d96c747b-2ab5-47e2-b07e-1079623748d8 50Gi RWO ocs-storagecluster-ceph-rbd 114s ocs-deviceset-0-0-lzfrd Bound local-pv-7e70c77c 1769Gi RWO localblock 2m10s ocs-deviceset-1-0-7rggl Bound local-pv-b19b3d48 1769Gi RWO localblock 2m10s ocs-deviceset-2-0-znhk8 Bound local-pv-e9f22cdc 1769Gi RWO localblock 2m10s
第 9 章 删除失败或不需要的 Ceph Object Storage 设备
失败或不需要的 Ceph OSD (对象存储设备)会影响存储基础架构的性能。因此,为了提高存储集群的可靠性和弹性,您必须移除失败或不需要的 Ceph OSD。
如果您有任何失败或不需要的 Ceph OSD 来删除:
验证 Ceph 健康状态。
有关更多信息,请参阅: 验证 Ceph 集群处于健康状态。
根据 OSD 的调配,移除失败或不需要的 Ceph OSD。
请参阅:
如果使用本地磁盘,您可以在删除旧 OSD 后重复使用这些磁盘。
9.1. 验证 Ceph 集群是否健康
存储健康状况在 Block 和 File 和 Object 仪表板中可见。
流程
- 在 OpenShift Web 控制台中,点 Storage → Data Foundation。
- 在 Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出弹出窗口中的 storage 系统链接。
- 在 Block and File 选项卡的 Status 卡中,验证 Storage Cluster 是否具有绿色勾号。
- 在 Details 卡中,验证是否显示了集群信息。
9.2. 在动态置备的 Red Hat OpenShift Data Foundation 中删除失败或不需要的 Ceph OSD
按照以下步骤在动态置备的 Red Hat OpenShift Data Foundation 中删除失败或不需要的 Ceph 对象存储设备(OSD)。
只有在红帽支持团队的帮助中才支持缩减集群。
- 当 Ceph 组件没有处于健康状态时删除 OSD 可能会导致数据丢失。
- 同时删除两个或多个 OSD 会导致数据丢失。
先决条件
- 检查 Ceph 是否健康。如需更多信息,请参阅 验证 Ceph 集群处于健康状态。
- 确保没有触发警报或任何重建过程正在进行中。
流程
缩减 OSD 部署。
# oc scale deployment rook-ceph-osd-<osd-id> --replicas=0
获取要删除的 Ceph OSD 的
osd-prepare
pod。# oc get deployment rook-ceph-osd-<osd-id> -oyaml | grep ceph.rook.io/pvc
删除
osd-prepare
pod。# oc delete -n openshift-storage pod rook-ceph-osd-prepare-<pvc-from-above-command>-<pod-suffix>
从集群中移除失败的 OSD。
# failed_osd_id=<osd-id> # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=$<failed_osd_id> | oc create -f -
其中,
FAILED_OSD_ID
是 pod 名称中紧接在rook-ceph-osd
前缀后面的整数。通过检查日志来验证 OSD 是否已成功移除。
# oc logs -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
-
可选:如果您遇到错误
cephosd:osd.0 is not ok to destroy
from the ocs-osd-removal-job pod in OpenShift Container Platform,请参阅在 删除失败或不需要的 Ceph OSD 时对错误cephosd:osd.0
进行故障排除。 删除 OSD 部署。
# oc delete deployment rook-ceph-osd-<osd-id>
验证步骤
要检查 OSD 是否已成功删除,请运行:
# oc get pod -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
这个命令必须将状态返回为 Completed。
9.3. 使用本地存储设备删除置备失败或不需要的 Ceph OSD
您可以按照流程中的步骤,使用本地存储设备删除失败或不需要的 Ceph 置备的对象存储设备(OSD)。
只有在红帽支持团队的帮助中才支持缩减集群。
- 当 Ceph 组件没有处于健康状态时删除 OSD 可能会导致数据丢失。
- 同时删除两个或多个 OSD 会导致数据丢失。
先决条件
- 检查 Ceph 是否健康。如需更多信息,请参阅 验证 Ceph 集群处于健康状态。
- 确保没有触发警报或任何重建过程正在进行中。
流程
假如,通过将 OSD 部署中的副本扩展到 0 来标记 OSD 停机。如果 OSD 已因为失败而停机,您可以跳过这一步。
# oc scale deployment rook-ceph-osd-<osd-id> --replicas=0
从集群中移除失败的 OSD。
# failed_osd_id=<osd_id> # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=$<failed_osd_id> | oc create -f -
其中,
FAILED_OSD_ID
是 pod 名称中紧接在rook-ceph-osd
前缀后面的整数。通过检查日志来验证 OSD 是否已成功移除。
# oc logs -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
-
可选:如果您遇到错误
cephosd:osd.0 is not ok to destroy
from the ocs-osd-removal-job pod in OpenShift Container Platform,请参阅在 删除失败或不需要的 Ceph OSD 时对错误cephosd:osd.0
进行故障排除。 删除与故障 OSD 关联的持久性卷声明(PVC)资源。
获取与故障 OSD 关联的
PVC
。# oc get -n openshift-storage -o yaml deployment rook-ceph-osd-<osd-id> | grep ceph.rook.io/pvc
获取与
PVC 关联的持久性卷
(PV)。# oc get -n openshift-storage pvc <pvc-name>
获取失败的设备名称。
# oc get pv <pv-name-from-above-command> -oyaml | grep path
获取与故障 OSD 关联的
prepare-pod
。# oc describe -n openshift-storage pvc ocs-deviceset-0-0-nvs68 | grep Mounted
在删除关联的 PVC 前,删除
osd-prepare pod
。# oc delete -n openshift-storage pod <osd-prepare-pod-from-above-command>
删除与故障 OSD 关联的
PVC
。# oc delete -n openshift-storage pvc <pvc-name-from-step-a>
从
LocalVolume 自定义资源
(CR)中删除失败的设备条目。使用失败设备登录到节点。
# oc debug node/<node_with_failed_osd>
为失败的设备名称记录 /dev/disk/by-id/<id>。
# ls -alh /mnt/local-storage/localblock/
可选:在以下情况下,Local Storage Operator 用于置备 OSD,使用 {osd-id} 登录机器并删除设备符号链接。
# oc debug node/<node_with_failed_osd>
获取故障设备名称的 OSD 符号链接。
# ls -alh /mnt/local-storage/localblock
删除符号链接。
# rm /mnt/local-storage/localblock/<failed-device-name>
- 删除与 OSD 关联的 PV。
# oc delete pv <pv-name>
验证步骤
要检查 OSD 是否已成功删除,请运行:
#oc get pod -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
这个命令必须将状态返回为 Completed。
9.4. 在删除失败或不需要的 Ceph OSD 时,对错误 cephosd:osd.0
进行故障排除
如果遇到错误,cephosd:osd.0 is not ok to destroy
from the ocs-osd-removal-job pod in OpenShift Container Platform,使用 FORCE_OSD_REMOVAL 选项运行 Object Storage Device (OSD)删除作业,以将 OSD 移到 destroyed 状态。
# oc process -n openshift-storage ocs-osd-removal -p FORCE_OSD_REMOVAL=true -p FAILED_OSD_IDS=$<failed_osd_id> | oc create -f -
只有所有 PG 都处于 active 状态时,才必须使用 FORCE_OSD_REMOVAL 选项。如果没有,PG 必须完成回填或进一步调查,以确保它们处于活动状态。
第 10 章 卸载过程中的故障排除和删除剩余的资源
有时,由 Operator 管理的一些自定义资源可能会处于 "Terminating" 状态,等待终结器完成,尽管您执行了所有必要的清理任务。在这种情况下,您需要强制删除这些资源。如果没有这样做,即使执行了所有卸载步骤,资源也会处于 Terminating
状态。
检查 openshift-storage 命名空间在删除时是否处于
Terminating
状态。$ oc get project -n <namespace>
输出:
NAME DISPLAY NAME STATUS openshift-storage Terminating
检查命令输出的
STATUS
部分中的NamespaceFinalizersRemaining
和NamespaceContentRemaining
信息,并为列出的每个资源执行下一步。$ oc get project openshift-storage -o yaml
输出示例:
status: conditions: - lastTransitionTime: "2020-07-26T12:32:56Z" message: All resources successfully discovered reason: ResourcesDiscovered status: "False" type: NamespaceDeletionDiscoveryFailure - lastTransitionTime: "2020-07-26T12:32:56Z" message: All legacy kube types successfully parsed reason: ParsedGroupVersions status: "False" type: NamespaceDeletionGroupVersionParsingFailure - lastTransitionTime: "2020-07-26T12:32:56Z" message: All content successfully deleted, may be waiting on finalization reason: ContentDeleted status: "False" type: NamespaceDeletionContentFailure - lastTransitionTime: "2020-07-26T12:32:56Z" message: 'Some resources are remaining: cephobjectstoreusers.ceph.rook.io has 1 resource instances' reason: SomeResourcesRemain status: "True" type: NamespaceContentRemaining - lastTransitionTime: "2020-07-26T12:32:56Z" message: 'Some content in the namespace has finalizers remaining: cephobjectstoreuser.ceph.rook.io in 1 resource instances' reason: SomeFinalizersRemain status: "True" type: NamespaceFinalizersRemaining
删除上一步中列出的所有剩余资源。
对于要删除的每个资源,请执行以下操作:
获取需要删除的资源的对象类型。查看以上输出中的消息。
示例:
message: some content in the namespace has finalizers remaining: cephobjectstoreuser.ceph.rook.io
此处 cephobjectstoreuser.ceph.rook.io 是对象类型。
获取与对象类型对应的对象名称。
$ oc get <Object-kind> -n <project-name>
示例:
$ oc get cephobjectstoreusers.ceph.rook.io -n openshift-storage
输出示例:
NAME AGE noobaa-ceph-objectstore-user 26h
修补资源。
$ oc patch -n <project-name> <object-kind>/<object-name> --type=merge -p '{"metadata": {"finalizers":null}}'
示例:
$ oc patch -n openshift-storage cephobjectstoreusers.ceph.rook.io/noobaa-ceph-objectstore-user \ --type=merge -p '{"metadata": {"finalizers":null}}'
输出:
cephobjectstoreuser.ceph.rook.io/noobaa-ceph-objectstore-user patched
验证 openshift-storage 项目是否已删除。
$ oc get project openshift-storage
输出:
Error from server (NotFound): namespaces "openshift-storage" not found
如果问题仍然存在,请联系红帽支持团队。
第 11 章 对外部模式的 CephFS PVC 创建进行故障排除
如果您已将 Red Hat Ceph Storage 集群从低于 4.1.1 的版本更新为最新版本,且不是全新部署的集群,您必须在 Red Hat Ceph Storage 集群上为 CephFS 池手动设置应用类型,以便在外部模式下启用 CephFS 持久性卷声明(PVC)创建。
检查 CephFS pvc 处于
Pending
状态。# oc get pvc -n <namespace>
输出示例:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ngx-fs-pxknkcix20-pod Pending ocs-external-storagecluster-cephfs 28h [...]
检查
oc describe
命令的输出,以查看对应 pvc 的事件。预期的错误消息为
cephfs_metadata/csi.volumes.default/csi.volume.pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx: (1) Operation not permitted)
# oc describe pvc ngx-fs-pxknkcix20-pod -n nginx-file
输出示例:
Name: ngx-fs-pxknkcix20-pod Namespace: nginx-file StorageClass: ocs-external-storagecluster-cephfs Status: Pending Volume: Labels: <none> Annotations: volume.beta.kubernetes.io/storage-provisioner: openshift-storage.cephfs.csi.ceph.com Finalizers: [kubernetes.io/pvc-protection] Capacity: Access Modes: VolumeMode: Filesystem Mounted By: ngx-fs-oyoe047v2bn2ka42jfgg-pod-hqhzf Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 107m (x245 over 22h) openshift-storage.cephfs.csi.ceph.com_csi-cephfsplugin-provisioner-5f8b66cc96-hvcqp_6b7044af-c904-4795-9ce5-bf0cf63cc4a4 (combined from similar events): failed to provision volume with StorageClass "ocs-external-storagecluster-cephfs": rpc error: code = Internal desc = error (an error (exit status 1) occurred while running rados args: [-m 192.168.13.212:6789,192.168.13.211:6789,192.168.13.213:6789 --id csi-cephfs-provisioner --keyfile=stripped -c /etc/ceph/ceph.conf -p cephfs_metadata getomapval csi.volumes.default csi.volume.pvc-1ac0c6e6-9428-445d-bbd6-1284d54ddb47 /tmp/omap-get-186436239 --namespace=csi]) occurred, command output streams is ( error getting omap value cephfs_metadata/csi.volumes.default/csi.volume.pvc-1ac0c6e6-9428-445d-bbd6-1284d54ddb47: (1) Operation not permitted)
检查 <
cephfs metadata pool name
> (这里是cephfs_metadata
)和 <cephfs data pool name>
; (这里是cephfs_data
)。若要运行命令,您需要在 Red Hat Ceph Storage 客户端节点中预安装jq
。# ceph osd pool ls detail --format=json | jq '.[] | select(.pool_name| startswith("cephfs")) | .pool_name, .application_metadata' "cephfs_data" { "cephfs": {} } "cephfs_metadata" { "cephfs": {} }
设置 CephFS 池的应用类型。
在 Red Hat Ceph Storage 客户端节点上运行以下命令:
# ceph osd pool application set <cephfs metadata pool name> cephfs metadata cephfs
# ceph osd pool application set <cephfs data pool name> cephfs data cephfs
验证是否应用了设置。
# ceph osd pool ls detail --format=json | jq '.[] | select(.pool_name| startswith("cephfs")) | .pool_name, .application_metadata' "cephfs_data" { "cephfs": { "data": "cephfs" } } "cephfs_metadata" { "cephfs": { "metadata": "cephfs" } }
再次检查 CephFS PVC 状态。PVC 现在应处于
Bound
状态。# oc get pvc -n <namespace>
输出示例:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ngx-fs-pxknkcix20-pod Bound pvc-1ac0c6e6-9428-445d-bbd6-1284d54ddb47 1Mi RWO ocs-external-storagecluster-cephfs 29h [...]
第 12 章 在 OpenShift Data Foundation 中恢复监控 pod
如果所有三个 pod 都停机,并且 OpenShift Data Foundation 无法自动恢复 monitor pod,则恢复 monitor pod。
这是一个灾难恢复流程,必须在红帽支持团队的指导下执行。在 上联系红帽支持团队,请联系红帽支持团队。
流程
缩减
rook-ceph-operator
和ocs operator
部署。# oc scale deployment rook-ceph-operator --replicas=0 -n openshift-storage
# oc scale deployment ocs-operator --replicas=0 -n openshift-storage
为
openshift-storage
命名空间中的所有部署创建备份。# mkdir backup
# cd backup
# oc project openshift-storage
# for d in $(oc get deployment|awk -F' ' '{print $1}'|grep -v NAME); do echo $d;oc get deployment $d -o yaml > oc_get_deployment.${d}.yaml; done
修补 Object Storage Device (OSD)部署以删除
livenessProbe
参数,并使用命令参数作为sleep
运行它。# for i in $(oc get deployment -l app=rook-ceph-osd -oname);do oc patch ${i} -n openshift-storage --type='json' -p '[{"op":"remove", "path":"/spec/template/spec/containers/0/livenessProbe"}]' ; oc patch ${i} -n openshift-storage -p '{"spec": {"template": {"spec": {"containers": [{"name": "osd", "command": ["sleep", "infinity"], "args": []}]}}}}' ; done
从所有 OSD 检索
monstore
集群映射。创建
restore_mon.sh
脚本。#!/bin/bash ms=/tmp/monstore rm -rf $ms mkdir $ms for osd_pod in $(oc get po -l app=rook-ceph-osd -oname -n openshift-storage); do echo "Starting with pod: $osd_pod" podname=$(echo $osd_pod|sed 's/pod\///g') oc exec $osd_pod -- rm -rf $ms oc cp $ms $podname:$ms rm -rf $ms mkdir $ms echo "pod in loop: $osd_pod ; done deleting local dirs" oc exec $osd_pod -- ceph-objectstore-tool --type bluestore --data-path /var/lib/ceph/osd/ceph-$(oc get $osd_pod -ojsonpath='{ .metadata.labels.ceph_daemon_id }') --op update-mon-db --no-mon-config --mon-store-path $ms echo "Done with COT on pod: $osd_pod" oc cp $podname:$ms $ms echo "Finished pulling COT data from pod: $osd_pod" done
运行
restore_mon.sh
脚本。# chmod +x recover_mon.sh
# ./recover_mon.sh
修补 MON 部署,并使用命令参数作为
sleep
运行。编辑 MON 部署。
# for i in $(oc get deployment -l app=rook-ceph-mon -oname);do oc patch ${i} -n openshift-storage -p '{"spec": {"template": {"spec": {"containers": [{"name": "mon", "command": ["sleep", "infinity"], "args": []}]}}}}'; done
修补 MON 部署,以增加
initialDelaySeconds
。# oc get deployment rook-ceph-mon-a -o yaml | sed "s/initialDelaySeconds: 10/initialDelaySeconds: 2000/g" | oc replace -f -
# oc get deployment rook-ceph-mon-b -o yaml | sed "s/initialDelaySeconds: 10/initialDelaySeconds: 2000/g" | oc replace -f -
# oc get deployment rook-ceph-mon-c -o yaml | sed "s/initialDelaySeconds: 10/initialDelaySeconds: 2000/g" | oc replace -f -
将之前检索到的
monstore
复制到 mon-a pod。# oc cp /tmp/monstore/ $(oc get po -l app=rook-ceph-mon,mon=a -oname |sed 's/pod\///g'):/tmp/
导航到 MON 容器集,再更改检索到的
monstore
的所有权。# oc rsh $(oc get po -l app=rook-ceph-mon,mon=a -oname)
# chown -R ceph:ceph /tmp/monstore
在重新构建
mon db
之前,复制密钥环模板文件。# oc rsh $(oc get po -l app=rook-ceph-mon,mon=a -oname)
# cp /etc/ceph/keyring-store/keyring /tmp/keyring
# cat /tmp/keyring [mon.] key = AQCleqldWqm5IhAAgZQbEzoShkZV42RiQVffnA== caps mon = "allow *" [client.admin] key = AQCmAKld8J05KxAArOWeRAw63gAwwZO5o75ZNQ== auid = 0 caps mds = "allow *" caps mgr = "allow *" caps mon = "allow *" caps osd = "allow *”
从对应的机密中识别所有其他 Ceph 守护进程(MGR、MDS、RGW、Crash、CSI 和 CSI 置备程序)的密钥环。
# oc get secret rook-ceph-mds-ocs-storagecluster-cephfilesystem-a-keyring -ojson | jq .data.keyring | xargs echo | base64 -d [mds.ocs-storagecluster-cephfilesystem-a] key = AQB3r8VgAtr6OhAAVhhXpNKqRTuEVdRoxG4uRA== caps mon = "allow profile mds" caps osd = "allow *" caps mds = "allow"
keyring 文件示例:
/etc/ceph/ceph.client.admin.keyring
:[mon.] key = AQDxTF1hNgLTNxAAi51cCojs01b4I5E6v2H8Uw== caps mon = "allow " [client.admin] key = AQDxTF1hpzguOxAA0sS8nN4udoO35OEbt3bqMQ== caps mds = "allow " caps mgr = "allow *" caps mon = "allow *" caps osd = "allow *" [mds.ocs-storagecluster-cephfilesystem-a] key = AQCKTV1horgjARAA8aF/BDh/4+eG4RCNBCl+aw== caps mds = "allow" caps mon = "allow profile mds" caps osd = "allow *" [mds.ocs-storagecluster-cephfilesystem-b] key = AQCKTV1hN4gKLBAA5emIVq3ncV7AMEM1c1RmGA== caps mds = "allow" caps mon = "allow profile mds" caps osd = "allow *" [client.rgw.ocs.storagecluster.cephobjectstore.a] key = AQCOkdBixmpiAxAA4X7zjn6SGTI9c1MBflszYA== caps mon = "allow rw" caps osd = "allow rwx" [mgr.a] key = AQBOTV1hGYOEORAA87471+eIZLZtptfkcHvTRg== caps mds = "allow *" caps mon = "allow profile mgr" caps osd = "allow *" [client.crash] key = AQBOTV1htO1aGRAAe2MPYcGdiAT+Oo4CNPSF1g== caps mgr = "allow rw" caps mon = "allow profile crash" [client.csi-cephfs-node] key = AQBOTV1hiAtuBBAAaPPBVgh1AqZJlDeHWdoFLw== caps mds = "allow rw" caps mgr = "allow rw" caps mon = "allow r" caps osd = "allow rw tag cephfs *=" [client.csi-cephfs-provisioner] key = AQBNTV1hHu6wMBAAzNXZv36aZJuE1iz7S7GfeQ== caps mgr = "allow rw" caps mon = "allow r" caps osd = "allow rw tag cephfs metadata=" [client.csi-rbd-node] key = AQBNTV1h+LnkIRAAWnpIN9bUAmSHOvJ0EJXHRw== caps mgr = "allow rw" caps mon = "profile rbd" caps osd = "profile rbd" [client.csi-rbd-provisioner] key = AQBNTV1hMNcsExAAvA3gHB2qaY33LOdWCvHG/A== caps mgr = "allow rw" caps mon = "profile rbd" caps osd = "profile rbd"
重要-
对于
client.csi
相关的密钥环,请参考前面的密钥环文件输出,并在从其相应的 OpenShift Data Foundation 机密获取密钥后添加默认caps
。 - OSD 密钥环会在恢复后自动添加。
-
对于
导航到 mon-a pod,再验证
monstore
是否具有monmap
。进入 mon-a pod。
# oc rsh $(oc get po -l app=rook-ceph-mon,mon=a -oname)
验证
monstore
是否具有monmap
。# ceph-monstore-tool /tmp/monstore get monmap -- --out /tmp/monmap
# monmaptool /tmp/monmap --print
可选: 如果缺少
monmap
,则创建新的monmap
。# monmaptool --create --add <mon-a-id> <mon-a-ip> --add <mon-b-id> <mon-b-ip> --add <mon-c-id> <mon-c-ip> --enable-all-features --clobber /root/monmap --fsid <fsid>
<mon-a-id>
- 是 mon-a pod 的 ID。
<mon-a-ip>
- 是 mon-a pod 的 IP 地址。
<mon-b-id>
- 是 mon-b pod 的 ID。
<mon-b-ip>
- 是 mon-b pod 的 IP 地址。
<mon-c-id>
- 是 mon-c pod 的 ID。
<mon-c-ip>
- 是 mon-c pod 的 IP 地址。
<fsid>
- 是文件系统 ID。
验证
monmap
。# monmaptool /root/monmap --print
导入
monmap
。重要使用之前创建的 keyring 文件。
# ceph-monstore-tool /tmp/monstore rebuild -- --keyring /tmp/keyring --monmap /root/monmap
# chown -R ceph:ceph /tmp/monstore
创建旧
store.db
文件的备份。# mv /var/lib/ceph/mon/ceph-a/store.db /var/lib/ceph/mon/ceph-a/store.db.corrupted
# mv /var/lib/ceph/mon/ceph-b/store.db /var/lib/ceph/mon/ceph-b/store.db.corrupted
# mv /var/lib/ceph/mon/ceph-c/store.db /var/lib/ceph/mon/ceph-c/store.db.corrupted
将重建
store.db
文件复制到monstore
目录。# mv /tmp/monstore/store.db /var/lib/ceph/mon/ceph-a/store.db
# chown -R ceph:ceph /var/lib/ceph/mon/ceph-a/store.db
在重建了
monstore
目录后,将store.db
文件从本地复制到 MON 容器集的其余部分。# oc cp $(oc get po -l app=rook-ceph-mon,mon=a -oname | sed 's/pod\///g'):/var/lib/ceph/mon/ceph-a/store.db /tmp/store.db
# oc cp /tmp/store.db $(oc get po -l app=rook-ceph-mon,mon=<id> -oname | sed 's/pod\///g'):/var/lib/ceph/mon/ceph-<id>
<id>
- 是 MON pod 的 ID
导航到 MON 容器集的其余部分,再更改复制的
monstore
的所有权。# oc rsh $(oc get po -l app=rook-ceph-mon,mon=<id> -oname)
# chown -R ceph:ceph /var/lib/ceph/mon/ceph-<id>/store.db
<id>
- 是 MON pod 的 ID
恢复补丁的更改。
对于 MON 部署:
# oc replace --force -f <mon-deployment.yaml>
<mon-deployment.yaml>
- 是 MON 部署 yaml 文件
对于 OSD 部署:
# oc replace --force -f <osd-deployment.yaml>
<osd-deployment.yaml>
- 是 OSD 部署 yaml 文件
对于 MGR 部署:
# oc replace --force -f <mgr-deployment.yaml>
<mgr-deployment.yaml>
是 MGR 部署 yaml 文件
重要确保 MON、MGR 和 OSD 容器集已启动并在运行。
扩展
rook-ceph-operator
和ocs-operator
部署。# oc -n openshift-storage scale deployment ocs-operator --replicas=1
验证步骤
检查 Ceph 状态,以确认 CephFS 正在运行。
# ceph -s
输出示例:
cluster: id: f111402f-84d1-4e06-9fdb-c27607676e55 health: HEALTH_ERR 1 filesystem is offline 1 filesystem is online with fewer MDS than max_mds 3 daemons have recently crashed services: mon: 3 daemons, quorum b,c,a (age 15m) mgr: a(active, since 14m) mds: ocs-storagecluster-cephfilesystem:0 osd: 3 osds: 3 up (since 15m), 3 in (since 2h) data: pools: 3 pools, 96 pgs objects: 500 objects, 1.1 GiB usage: 5.5 GiB used, 295 GiB / 300 GiB avail pgs: 96 active+clean
检查 Multicloud Object Gateway (MCG)状态。它应当处于活动状态,并且后备存储和 bucket 类应处于
Ready
状态。noobaa status -n openshift-storage
重要如果 MCG 没有处于 active 状态,且后备存储和存储桶类没有处于
Ready
状态,则需要重启所有 MCG 相关的 pod。如需更多信息,请参阅 第 12.1 节 “恢复 Multicloud 对象网关”。
12.1. 恢复 Multicloud 对象网关
如果 Multicloud Object Gateway (MCG)没有处于 active 状态,且后备存储和存储桶类没有处于 Ready
状态,您需要重启所有 MCG 相关的 pod,并检查 MCG 状态以确认 MCG 已备份并在运行。
流程
重启与 MCG 相关的所有 pod。
# oc delete pods <noobaa-operator> -n openshift-storage
# oc delete pods <noobaa-core> -n openshift-storage
# oc delete pods <noobaa-endpoint> -n openshift-storage
# oc delete pods <noobaa-db> -n openshift-storage
<noobaa-operator>
- 是 MCG operator 的名称
<noobaa-core>
- 是 MCG 核心 pod 的名称
<noobaa-endpoint>
- 是 MCG 端点的名称
<noobaa-db>
- 是 MCG db pod 的名称
如果配置了 RADOS 对象网关(RGW),请重新启动容器集。
# oc delete pods <rgw-pod> -n openshift-storage
<rgw-pod>
- 是 RGW pod 的名称
在 OpenShift Container Platform 4.11 中,在恢复后,RBD PVC 无法挂载到应用程序 pod 上。因此,您需要重启托管应用容器集的节点。要获取托管应用程序 pod 的节点名称,请运行以下命令:
# oc get pods <application-pod> -n <namespace> -o yaml | grep nodeName nodeName: node_name
第 13 章 在 OpenShift Data Foundation 中恢复 ceph-monitor 仲裁
在某些情况下,ceph-mons
可能会丢失仲裁。如果 mons
无法再次形成仲裁,则需要一个手动过程来再次执行仲裁。唯一的要求是至少有一个 mon
必须健康。以下步骤从仲裁中删除不健康的 mons
,并可让您使用单个 mon
重新组成仲裁,然后将仲裁恢复为原始大小。
例如,如果您有三个 mons
并失去仲裁,您需要从仲裁中删除两个有问题的 mons
,通知良好 mon
它是仲裁中唯一的 mon
,然后重启这个可以正常工作的 mon
。
流程
停止
rook-ceph-operator
,以便在修改monmap
时不通过mons
失败。# oc -n openshift-storage scale deployment rook-ceph-operator --replicas=0
注入一个新的
monmap
。警告您必须非常仔细注入
monmap
。如果运行不正确,您的集群可以被永久销毁。Cephmonmap
来跟踪mon
仲裁。monmap
被更新为仅包含健康的 mon。在本例中,健康的 mon 是rook-ceph-mon-b
,而不健康的mons
为rook-ceph-mon-a
和rook-ceph-mon-c
。备份当前的
rook-ceph-mon-b
部署:# oc -n openshift-storage get deployment rook-ceph-mon-b -o yaml > rook-ceph-mon-b-deployment.yaml
打开 YAML 文件,并从
mon
容器复制 命令和参数 (请参阅以下示例中的容器列表)。这是monmap
更改所需要的。[...] containers: - args: - --fsid=41a537f2-f282-428e-989f-a9e07be32e47 - --keyring=/etc/ceph/keyring-store/keyring - --log-to-stderr=true - --err-to-stderr=true - --mon-cluster-log-to-stderr=true - '--log-stderr-prefix=debug ' - --default-log-to-file=false - --default-mon-cluster-log-to-file=false - --mon-host=$(ROOK_CEPH_MON_HOST) - --mon-initial-members=$(ROOK_CEPH_MON_INITIAL_MEMBERS) - --id=b - --setuser=ceph - --setgroup=ceph - --foreground - --public-addr=10.100.13.242 - --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db - --public-bind-addr=$(ROOK_POD_IP) command: - ceph-mon [...]
清理复制的
command
和args
字段,以形成过去的命令,如下所示:# ceph-mon \ --fsid=41a537f2-f282-428e-989f-a9e07be32e47 \ --keyring=/etc/ceph/keyring-store/keyring \ --log-to-stderr=true \ --err-to-stderr=true \ --mon-cluster-log-to-stderr=true \ --log-stderr-prefix=debug \ --default-log-to-file=false \ --default-mon-cluster-log-to-file=false \ --mon-host=$ROOK_CEPH_MON_HOST \ --mon-initial-members=$ROOK_CEPH_MON_INITIAL_MEMBERS \ --id=b \ --setuser=ceph \ --setgroup=ceph \ --foreground \ --public-addr=10.100.13.242 \ --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db \ --public-bind-addr=$ROOK_POD_IP
注意确保删除位于 the
-log-stderr-prefix
标记的单引号,以及有关正在传递ROOK_CEPH_MON_HOST
、ROOK_CEPH_MON_HOST、ROOK_CEPH_MON_INITIAL_MEMBERS
和ROOK_POD_IP
变量的父括号。修补
rook-ceph-mon-b
部署,在不删除mon
pod 的情况下停止这个mon
工作。# oc -n openshift-storage patch deployment rook-ceph-mon-b --type='json' -p '[{"op":"remove", "path":"/spec/template/spec/containers/0/livenessProbe"}]' # oc -n openshift-storage patch deployment rook-ceph-mon-b -p '{"spec": {"template": {"spec": {"containers": [{"name": "mon", "command": ["sleep", "infinity"], "args": []}]}}}}'
在
mon-b
pod 上执行以下步骤:连接到健康
mon
的 pod 并运行以下命令:# oc -n openshift-storage exec -it <mon-pod> bash
设置变量。
# monmap_path=/tmp/monmap
将
monmap
提取到文件,从良好mon
部署中粘贴 cephmon
命令并添加--extract-monmap=${monmap_path}
标志。# ceph-mon \ --fsid=41a537f2-f282-428e-989f-a9e07be32e47 \ --keyring=/etc/ceph/keyring-store/keyring \ --log-to-stderr=true \ --err-to-stderr=true \ --mon-cluster-log-to-stderr=true \ --log-stderr-prefix=debug \ --default-log-to-file=false \ --default-mon-cluster-log-to-file=false \ --mon-host=$ROOK_CEPH_MON_HOST \ --mon-initial-members=$ROOK_CEPH_MON_INITIAL_MEMBERS \ --id=b \ --setuser=ceph \ --setgroup=ceph \ --foreground \ --public-addr=10.100.13.242 \ --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db \ --public-bind-addr=$ROOK_POD_IP \ --extract-monmap=${monmap_path}
检查
monmap
的内容。# monmaptool --print /tmp/monmap
从
monmap
中删除错误的mons
。# monmaptool ${monmap_path} --rm <bad_mon>
在这个示例中,我们删除
mon0
和mon2
:# monmaptool ${monmap_path} --rm a # monmaptool ${monmap_path} --rm c
将修改后的
monmap
注入到正常的mon
中,粘贴 cephmon
命令并添加--inject-monmap=${monmap_path}
标志:# ceph-mon \ --fsid=41a537f2-f282-428e-989f-a9e07be32e47 \ --keyring=/etc/ceph/keyring-store/keyring \ --log-to-stderr=true \ --err-to-stderr=true \ --mon-cluster-log-to-stderr=true \ --log-stderr-prefix=debug \ --default-log-to-file=false \ --default-mon-cluster-log-to-file=false \ --mon-host=$ROOK_CEPH_MON_HOST \ --mon-initial-members=$ROOK_CEPH_MON_INITIAL_MEMBERS \ --id=b \ --setuser=ceph \ --setgroup=ceph \ --foreground \ --public-addr=10.100.13.242 \ --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db \ --public-bind-addr=$ROOK_POD_IP \ --inject-monmap=${monmap_path}
- 退出 shell 以继续。
编辑 Rook
configmaps
。编辑 operator 用来跟踪
mons
的configmap
。# oc -n openshift-storage edit configmap rook-ceph-mon-endpoints
验证在数据元素中,您可以看到如下三个 mon (或者根据您的
moncount
),如下所示:data: a=10.100.35.200:6789;b=10.100.13.242:6789;c=10.100.35.12:6789
从列表中选择错误的
mons
,以使用一个好的mon
结束。例如:data: b=10.100.13.242:6789
- 保存文件并退出。
现在,您需要调整用于
mons
和其他组件的Secret
。为变量
good_mon_id
设置一个值。例如:
# good_mon_id=b
您可以使用
oc patch
命令来修补rook-ceph-config
secret,并更新两个键/值对mon_host
和mon_initial_members
。# mon_host=$(oc -n openshift-storage get svc rook-ceph-mon-b -o jsonpath='{.spec.clusterIP}') # oc -n openshift-storage patch secret rook-ceph-config -p '{"stringData": {"mon_host": "[v2:'"${mon_host}"':3300,v1:'"${mon_host}"':6789]", "mon_initial_members": "'"${good_mon_id}"'"}}'
注意如果使用
hostNetwork: true
,则需要将mon_host
var 替换为mon
固定到的节点 IP (nodeSelector
)。这是因为在那个 "mode" 中没有创建rook-ceph-mon
Escalation 服务。
重新启动
mon
。您需要使用原始
ceph-
命令重启良好的 mon pod,以获取这些更改。mon
在
mon
部署 YAML 文件的备份中使用oc replace
命令:# oc replace --force -f rook-ceph-mon-b-deployment.yaml
注意option-force
删除部署并创建一个新部署。验证集群的状态。
状态应该在仲裁中显示
mon
。如果状态正常,您的集群应该再次处于健康状态。
删除不再预期在仲裁中的两个 mon 部署。
例如:
# oc delete deploy <rook-ceph-mon-1> # oc delete deploy <rook-ceph-mon-2>
在本例中,要删除的部署有
rook-ceph-mon-a
和rook-ceph-mon-c
。重启 Operator。
再次启动 rook 运算符,以恢复监控集群的健康状况。
注意忽略多个资源已存在的错误是安全的。
# oc -n openshift-storage scale deployment rook-ceph-operator --replicas=1
根据
mon
数量,Operator 会自动添加更多mons
来再次增加仲裁大小。
第 14 章 启用 Red Hat OpenShift Data Foundation 控制台插件
Data Foundation 控制台插件会被默认启用。如果 OpenShift Data Foundation Operator 安装过程中不选中这个选项,请使用以下说明在从图形用户界面(GUI)或命令行界面中启用 console 插件。
先决条件
- 您有管理访问权限来访问 OpenShift Web 控制台。
-
OpenShift Data Foundation Operator 在
openshift-storage
命名空间中安装并运行。
流程
- 从用户界面
- 在 OpenShift Web 控制台中,点 Operators → Installed Operators 查看所有已安装的 Operator。
-
确保所选 项目为
openshift-storage
。 - 单击 OpenShift Data Foundation 操作器。
启用 console 插件选项。
- 在 Details 选项卡中,单击 Console 插件 下 的铅笔图标。
- 选择 Enable,然后单击 Save。
- 使用命令行界面
执行以下命令启用 console 插件选项:
$ oc patch console.operator cluster -n openshift-storage --type json -p '[{"op": "add", "path": "/spec/plugins", "value": ["odf-console"]}]'
验证步骤
启用 console 插件选项后,带有消息的弹出窗口,
Web 控制台更新
会出现在 GUI 中。点此弹出窗口中的 Refresh web console 来反映控制台的更改。- 在 Web 控制台中,导航到 Storage 并验证 Data Foundation 是否可用。
第 15 章 更改 OpenShift Data Foundation 组件的资源
安装 OpenShift Data Foundation 时,它附带了 OpenShift Data Foundation Pod 可消耗的预定义资源。在某些情况下,可能需要提高 I/O 负载。
- 要更改 rook-ceph pod 上的 CPU 和内存资源,请参阅 第 15.1 节 “更改 rook-ceph pod 上的 CPU 和内存资源”。
- 要调整 Multicloud 对象网关(MCG)的资源,请参阅 第 15.2 节 “为 MCG 调整资源”。
15.1. 更改 rook-ceph pod 上的 CPU 和内存资源
安装 OpenShift Data Foundation 时,它附带了 rook-ceph Pod 的预定义 CPU 和内存资源。您可以根据要求手动增加这些值。
您可以更改以下 pod 上的 CPU 和内存资源:
-
mgr
-
mds
-
rgw
以下示例演示了如何更改 rook-ceph pod 上的 CPU 和内存资源。在本例中,cpu
和 memory
的现有 MDS pod 值会分别从 1
和 4Gi
增加到 2
和 8Gi
。
编辑存储集群:
# oc edit storagecluster -n openshift-storage <storagecluster_name>
<storagecluster_name>
指定存储集群的名称。
例如:
# oc edit storagecluster -n openshift-storage ocs-storagecluster
将以下行添加到存储集群自定义资源(CR)中:
spec: resources: mds: limits: cpu: 2 memory: 8Gi requests: cpu: 2 memory: 8Gi
- 保存更改并退出编辑器。
或者,运行
oc patch
命令更改mds
pod 的 CPU 和内存值:# oc patch -n openshift-storage storagecluster <storagecluster_name> --type merge \ --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "2","memory": "8Gi"},"requests": {"cpu": "2","memory": "8Gi"}}}}}'
<storagecluster_name>
指定存储集群的名称。
例如:
# oc patch -n openshift-storage storagecluster ocs-storagecluster \ --type merge \ --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "2","memory": "8Gi"},"requests": {"cpu": "2","memory": "8Gi"}}}}}'
15.2. 为 MCG 调整资源
Multicloud 对象网关(MCG)的默认配置针对低资源消耗和不性能进行了优化。有关如何调整 MCG 资源的更多信息,请参阅 多云对象网关(NooBaa)的红帽知识库解决方案性能调整指南。
第 16 章 部署 OpenShift Data Foundation 后禁用多云对象网关外部服务
部署 OpenShift Data Foundation 时,即使 OpenShift 作为私有集群安装,也会创建公共 IP。但是,您可以使用 storagecluster CRD 中的 disableLoadBalancerService
变量禁用 Multicloud Object Gateway (MCG)负载均衡器的使用。这会限制 MCG 为私有集群创建任何公共资源,并帮助禁用 NooBaa 服务 EXTERNAL-IP
。
流程
运行以下命令,并在 storagecluster YAML 中添加
disableLoadBalancerService
变量,将服务设置为 ClusterIP:$ oc edit storagecluster -n openshift-storage <storagecluster_name> [...] spec: arbiter: {} encryption: kms: {} externalStorage: {} managedResources: cephBlockPools: {} cephCluster: {} cephConfig: {} cephDashboard: {} cephFilesystems: {} cephNonResilientPools: {} cephObjectStoreUsers: {} cephObjectStores: {} cephRBDMirror: {} cephToolbox: {} mirroring: {} multiCloudGateway: disableLoadBalancerService: true <--------------- Add this endpoints: [...]
注意要撤消更改并将服务设置为 LoadBalancer,请将
disableLoadBalancerService
变量设置为false
,或者完全删除该行。
第 17 章 通过手动启用全局 pod 网络来访问带有 ovs-multitenant
插件的 odf-console
在 OpenShift Container Platform 中,当 ovs-multitenant
插件用于软件定义型网络(SDN)时,来自不同项目的 Pod 无法向或接收来自不同项目的 pod 和服务的数据包。默认情况下,pod 无法在命名空间或项目之间进行通信,因为项目的 pod 网络不是全局的。
要访问 odf-console,openshift-console
命名空间中的 OpenShift 控制台 pod 需要与 openshift-storage
命名空间中的 OpenShift Data Foundation odf-console 连接。这只有在您手动启用全局 pod 网络时才可能。
问题
当 OpenShift Container Platform 中使用ovs-multitenant' 插件时,odf-console 插件会失败,并显示以下信息:
GET request for "odf-console" plugin failed: Get "https://odf-console-service.openshift-storage.svc.cluster.local:9001/locales/en/plugin__odf-console.json": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
解决方案
使 OpenShift Data Foundation 项目的 pod 网络设置为全局 :
$ oc adm pod-network make-projects-global openshift-storage
第 18 章 注解加密的 RBD 存储类
从 OpenShift Data Foundation 4.14 开始,当 OpenShift 控制台创建一个启用了加密的 RADOS 块设备(RBD)存储类时,会自动设置注解。但是,您需要为之前在升级到 OpenShift Data Foundation 版本 4.14 之前创建的任何加密 RBD 存储类中添加注解 cdi.kubevirt.io/clone-strategy=copy
。这可让客户数据集成(CDI)使用主机辅助克隆而不是默认的智能克隆。
用于访问加密卷的密钥与创建卷的命名空间相关联。将加密卷克隆到新命名空间时,比如置备新的 OpenShift Virtualization 虚拟机,必须创建一个新卷,源卷的内容必须复制到新卷中。如果存储类被正确注解,会自动触发此行为。
第 19 章 对供应商模式中的问题进行故障排除
19.1. 强制删除供应商集群中的存储
当在不执行注册流程的情况下删除客户端集群时,从对应的供应商集群中删除所有资源,您需要强制从供应商集群中删除对应的存储消费者。这有助于释放客户端声明的存储空间。
建议您仅在不可避免的情况下使用此方法,如意外删除存储客户端集群。
先决条件
- 在供应商模式中访问 OpenShift Data Foundation 存储集群。
流程
- 从 OpenShift 控制台点 Storage → Storage Clients。
点列出的存储客户端集群最右侧的删除图标。
删除图标仅在集群最后一次心跳 5 分钟后启用。
- 单击 Confirm。