OpenShift Data Foundation 故障排除
有关 OpenShift Data Foundation 故障排除的说明
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。提供反馈:
关于特定内容的简单评论:
- 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
- 用鼠标指针高亮显示您想评论的文本部分。
- 点在高亮文本上弹出的 Add Feedback。
- 按照显示的步骤操作。
要提交更复杂的反馈,请创建一个 Bugzilla ticket:
- 进入 Bugzilla 网站。
- 在 Component 部分中,选择 文档。
- 在 Description 中输入您要提供的信息。包括文档相关部分的链接。
- 点 Submit Bug。
第 1 章 概述
OpenShift Data Foundation 故障排除旨在帮助管理员了解如何排除故障并修复其 Red Hat OpenShift Data Foundation 集群。
大多数故障排除任务都侧重于修复或临时解决方案。本文档根据管理员可能遇到的错误分为若干章节:
- 第 2 章 使用 must-gather 下载日志文件和诊断信息 如何在 OpenShift Data Foundation 中使用 must-gather 实用程序。
- 第 3 章 故障排除所需的常见日志 如何获取 OpenShift Data Foundation 所需的日志文件。
- 第 6 章 对 OpenShift Data Foundation 中的警报和错误进行故障排除 如何识别遇到的错误并执行所需的操作。
第 2 章 使用 must-gather 下载日志文件和诊断信息
如果 Red Hat OpenShift Data Foundation 无法自动解决问题,请使用 must-gather 工具收集日志文件和诊断信息,以便您或红帽支持可以审核问题并确定解决方案。
当将 Red Hat OpenShift Data Foundation 部署为外部模式时,must-gather 仅从 Red Hat OpenShift Data Foundation 集群收集日志,且不会从外部 Red Hat Ceph Storage 集群收集调试数据和日志。要从外部 Red Hat Ceph Storage 集群收集调试日志,请参阅 Red Hat Ceph Storage 故障排除指南并联系您的 Red Hat Ceph Storage 管理员。
先决条件
可选:如果 OpenShift Data Foundation 在断开连接的环境中部署,请确保将单独的 must-gather 镜像镜像到断开连接的环境中可用的镜像 registry 中。
$ oc image mirror registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.9 <local-registry>/odf4/ocs-must-gather-rhel8:v4.9 [--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 不安全时才添加此标志。
如需更多信息,请参阅红帽知识库解决方案:
流程
从连接到 Red Hat OpenShift Data Foundation 集群的客户端运行
must-gather
命令:$ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.9 --dest-dir=<directory-name>
<directory-name>
是要将数据写入的目录的名称。
重要对于断开连接的环境部署,将
--image
参数中的镜像替换为镜像的 must-gather 镜像。$ oc adm must-gather --image=<local-registry>/odf4/ocs-must-gather-rhel8:v4.9 --dest-dir=<directory-name>
<local-registry>
- 是本地镜像 registry 可用于断开连接的 OpenShift Container Platform 集群。
这会在指定目录中收集以下信息:
- 所有与 Red Hat OpenShift Data Foundation 集群相关的自定义资源(CR)及其命名空间。
- 所有 Red Hat OpenShift Data Foundation 相关 pod 的 Pod 日志。
- 某些标准 Ceph 命令的输出,如状态、集群运行状况等。
命令变体
如果一个或多个 master 节点没有处于 Ready 状态,请使用
--node-name
指定一个状态为 Ready 的 master 节点,以便可以安全地调度must-gather
pod。$ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.9 --dest-dir=<directory-name> --node-name=<node-name>
如果要从特定时间收集信息:
要为收集的日志指定相对时间段(例如在 5 秒内或在 2 天内),添加
/usr/bin/gather since=<duration>
:$ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.9 --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/ocs-must-gather-rhel8:v4.9 --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 日 4am UTC 开始)。
第 3 章 故障排除所需的常见日志
其中列出了一些用于对 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.9.2 NooBaa Operator 4.9.2 mcg-operator.v4.9.1 Succeeded ocs-operator.v4.9.2 OpenShift Container Storage 4.9.2 ocs-operator.v4.9.1 Succeeded odf-operator.v4.9.2 OpenShift Data Foundation 4.9.2 odf-operator.v4.9.1 Succeeded
# oc get subs -n openshift-storage
输出示例:
NAME PACKAGE SOURCE CHANNEL mcg-operator-stable-4.9-redhat-operators-openshift-marketplace mcg-operator redhat-operators stable-4.9 ocs-operator-stable-4.9-redhat-operators-openshift-marketplace ocs-operator redhat-operators stable-4.9 odf-operator odf-operator redhat-operators stable-4.9
确认已创建了安装计划。
# 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 章 部署后覆盖 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
第 5 章 加密令牌已删除或过期
如果密钥管理系统的加密令牌被删除或过期,请使用这个流程更新令牌。
先决条件
- 确保您有一个与已删除或过期令牌相同的策略的新令牌
流程
- 登录 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 已被删除后,才能删除令牌。
第 6 章 对 OpenShift Data Foundation 中的警报和错误进行故障排除
6.1. 解决警报和错误
Red Hat OpenShift Data Foundation 可以检测并自动解决许多常见的故障情形。但是,有些问题需要管理员介入。
要了解当前触发的错误,请查看以下位置之一:
- Observe → Alerting → Firing 选项
- Home → Overview → Cluster 标签页
- Storage → Openshift Data Foundation → Storage System → storage system link in the pop up → Overview → Block and File 标签页
- Storage → Openshift Data Foundation → Storage System → storage system link in the pop up → Overview → Object 标签页
复制显示的错误并在以下部分搜索它以了解其严重性和解决方案:
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 流程 :检查用户界面并记录,并验证更新是否正在进行。
|
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 流程 :检查用户界面并记录,并验证更新是否正在进行。
|
Name:
Message:
Description: 严重性 :Crtical 解决方案 :修复 流程 :删除不必要的数据或扩展集群。 |
Name:
修复 :
Description: 严重性 :警告 解决方案 :修复 流程 :删除不必要的数据或扩展集群。 |
Name:
Message:
Description: 严重性 :警告 解决方案 :临时解决方案 |
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 |
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 |
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 |
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 |
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 |
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 |
Name:
Message:
Description: 严重性 :警告 解决方案 :临时解决方案 |
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 |
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 |
Name:
Message:
Description: 严重性 :警告 解决方案 :修复 |
Name:
Message: Description: `Minimum required replicas for storage metadata service not available. 可能会影响存储集群的工作。 严重性 :警告 解决方案 :联系红帽支持 流程 :
|
Name:
Message:
Description: 严重性 :Critical 解决方案 :联系红帽支持 流程 :
|
Name:
Message:
Description: 严重性 :Critical 解决方案 :联系红帽支持 流程 :
|
Name:
Message:
Description: 严重性 :Critical 解决方案 :联系红帽支持 流程 :
|
Name:
Message:
Description: 严重性 :警告 解决方案 :联系红帽支持 流程 :
|
Name:
Message:
Description: 严重性 :警告 解决方案 :联系红帽支持 |
Name:
Message:
Description: 严重性 :Critical 解决方案 :联系红帽支持 |
Name:
Message:
Description: 严重性 :Critical 解决方案 :联系红帽支持 |
Name:
Message:
Description: 严重性 :警告 解决方案 :联系红帽支持 |
Name:
Message:
Description: 严重性 :警告 解决方案 :联系红帽支持 |
Name:
Message:
Description: 严重性 :Critical 解决方案 :联系红帽支持 |
Name:
Message:
Description: 严重性 :Critical 解决方案 :联系红帽支持 流程 :
|
Name:
Message:
Description: 严重性 :Critical 解决方案 :联系红帽支持 |
Name:
Message: Description:Disaster recovery is failing for one or a few applications. 严重性 :警告 解决方案 :联系红帽支持 |
Name:
Message: Description:Disaster recovery is failing for the entire cluster.Mirror daemon is in unhealthy status for more than 1m.Mirroring on this cluster is not working as expected. 严重性 :Critical 解决方案 :联系红帽支持 |
6.2. 解决集群健康问题
Red Hat Ceph Storage 可以在 OpenShift Data Foundation 用户界面中引发该显示的一系列有限健康消息。它们定义为具有唯一标识符的健康检查。标识符是一个制表伪可读字符串,旨在使工具能够理解健康检查,并以反应其含义的方式呈现它们。有关更多信息和故障排除,请单击下面的健康代码。
健康代码 | 描述 |
---|---|
一个或多个 Ceph 监控器在磁盘空间上较低。 |
6.2.1. MON_DISK_LOW
如果将 monitor 数据库存储为百分比的文件系统中的可用空间下降到 mon_data_avail_warn
下,则会触发此警报(默认:15%)。这可能表明系统上的某些其他进程或用户正在填满监控器使用的相同文件系统。也可能表明监控器的数据库比较大。
文件系统的路径因您的 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 的文件系统的路径。
6.3. 解决 NooBaa Bucket 错误状态
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 在 Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
- 单击 Object 选项卡。
- 在详细信息卡中,单系统名称字段下的链接。
- 在左侧窗格中,单击 Buckets 选项并搜索处于错误状态的存储桶。如果处于错误状态的存储桶是一个命名空间存储桶,请确定点 Namespace Buckets 窗格。
- 点它的 Bucket Name。此时会显示存储桶中遇到的错误。
根据存储桶的具体错误,执行以下操作之一或两者:
对于与空间相关的错误:
- 在左侧窗格中,点 Resources 选项。
- 单击处于错误状态的资源。
- 通过添加更多代理来缩放资源。
对于资源健康错误:
- 在左侧窗格中,点 Resources 选项。
- 单击处于错误状态的资源。
- 连接错误意味着后备服务不可用,需要恢复。
- 如需访问/权限错误,请更新连接的访问密钥和机密密钥。
6.4. 解决 NooBaa Bucket Exceeding Quota State 问题
要解决 A NooBaa Bucket Is In Exceeding Quota State 错误,请执行以下操作之一:
- 清理存储桶上的一些数据。
执行以下步骤增加存储桶配额:
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 在 Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
- 单击 Object 选项卡。
- 在详细信息卡中,单系统名称字段下的链接。
- 在左侧窗格中,单击 Buckets 选项并搜索处于错误状态的存储桶。
- 点其 Bucket Name。此时会显示存储桶中遇到的错误。
- 点 Bucket Policies → Edit Quota 并增加配额。
6.5. 解决 NooBaa Bucket Capacity 或 Quota State 问题
流程
- 在 OpenShift Web 控制台中,点 Storage → OpenShift Data Foundation。
- 在 Overview 选项卡的 Status 卡中,点 Storage System,然后点弹出框中的存储系统链接。
- 单击 Object 选项卡。
- 在详细信息卡中,单系统名称字段下的链接。
- 在左侧窗格中,点 Resources 选项,再搜索 PV 池资源。
- 对于容量低状态的 PV 池资源,请点其资源名称。
- 编辑池配置并增加代理数量。
6.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
6.7. 从 EBS 卷分离中恢复
当 OSD 磁盘所驻留的 OSD 或 MON 弹性块存储(EBS)卷与工作程序 Amazon EC2 实例分离时,该卷会在一两分钟内自动重新附加。但是,OSD 容器集进入 CrashLoopBackOff
状态。若要将 pod 恢复并恢复为 Running
状态,您必须重新启动 EC2 实例。
6.8. 为 rook-ceph-operator 启用和禁用 debug 日志
为 rook-ceph-operator 启用 debug 日志,以获取有助于对问题进行故障排除的失败信息。
流程
- 启用 debug 日志
编辑 rook-ceph-operator 的 configmap。
$ oc edit configmap rook-ceph-operator-config
添加
ROOK_LOG_LEVEL:DEBUG
(在rook-ceph-operator-config
yaml 文件中)为 rook-ceph-operator 启用 debug 日志。… 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_LOG_LEVEL:INFO
参数(在rook-ceph-operator-config
yaml 文件中)以禁用 rook-ceph-operator 的 debug 日志。… data: # The logging level for the operator: INFO | DEBUG ROOK_LOG_LEVEL: INFO
第 7 章 检查 Local Storage Operator 部署
使用本地存储 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
第 8 章 卸载过程中的故障排除和删除剩余的资源
有时,由 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
如果问题仍然存在,请联系红帽支持团队。
第 9 章 对外部模式的 CephFS PVC 创建进行故障排除
如果您已将红帽 Ceph 存储集群从低于 4.1.1 的版本更新为最新版本,且不是全新部署的集群,您必须在红帽 Ceph 存储集群中手动设置 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 [...]
检查
describe
输出,以查看相应 pvc 的事件。错误消息应为
cephfs_metadata/csi.volumes.default/csi.volume.pvc-xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:(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 [...]
第 10 章 在 OpenShift Data Foundation 中恢复 monitor 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
修补 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 secret 获取密钥后添加默认大写字母
。 - OSD 密钥环会在恢复后自动添加。
-
对于
进入 mon-a pod,验证
monstore
具有monmap
。进入到 mon-a 容器集。
# 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
重要如果缺少文件系统或者 MDS 服务,则需要恢复 CephFS。如需更多信息,请参阅 第 10.1 节 “恢复 CephFS”。
检查 Multicloud 对象网关(MCG)状态。它应该处于活跃状态,后备存储和 bucketclass 应为
Ready
状态。noobaa status -n openshift-storage
重要如果 MCG 不在活跃状态,且后备存储和存储桶类没有处于
Ready
状态,则需要重启所有 MCG 相关 pod。如需更多信息,请参阅 第 10.2 节 “恢复 Multicloud 对象网关”。
10.1. 恢复 CephFS
如果文件系统离线或者 MDS 服务丢失,则需要恢复 CephFS。
流程
缩减
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
修补 MDS 部署以移除
livenessProbe
参数,并使用命令参数运行该参数作为sleep
状态。# for i in $(oc get deployment -l app=rook-ceph-mds -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": "mds", "command": ["sleep", "infinity"], "args": []}]}}}}' ; done
恢复 CephFS.
# ceph fs reset ocs-storagecluster-cephfilesystem --yes-i-really-mean-it
如果
reset
命令失败,请强制使用数据和元数据池创建默认文件系统,然后重置它。注意如果
cephfilesystem
缺失,则reset
命令可能会失败。# ceph fs new ocs-storagecluster-cephfilesystem ocs-storagecluster-cephfilesystem-metadata ocs-storagecluster-cephfilesystem-data0 --force
# ceph fs reset ocs-storagecluster-cephfilesystem --yes-i-really-mean-it
替换 MDS 部署。
# oc replace --force -f oc_get_deployment.rook-ceph-mds-ocs-storagecluster-cephfilesystem-a.yaml
# oc replace --force -f oc_get_deployment.rook-ceph-mds-ocs-storagecluster-cephfilesystem-b.yaml
扩展
rook-ceph-operator
和ocs-operator
部署。# oc scale deployment ocs-operator --replicas=1 -n openshift-storage
检查 CephFS 状态。
# ceph fs status
状态应当为 active。
如果连接到使用 CephFS 持久性卷声明(PVC)的部署的应用容器集在恢复 CephFS 后处于
CreateContainerError
状态,请重启应用容器集。# oc -n <namespace> delete pods <cephfs-app-pod>
<namespace>
- 是项目的命名空间
<cephfs-app-pod>
- 是 CephFS 应用 pod 的名称
- 如果没有绑定新的 CephFS 或 RBD PVC,请重启与 Ceph CSI 相关的所有 pod。
10.2. 恢复 Multicloud 对象网关
如果 Multicloud Object Gateway(MCG)没有处于活跃状态,且后备store 和 bucketclass 不在 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 的名称
第 11 章 启用 Red Hat OpenShift Data Foundation 控制台插件
如果在安装 OpenShift Data Foundation Operator 后不自动启用 console 插件选项。console 插件提供一个包含在 Web 控制台中的自定义接口。您可以从图形用户界面(GUI)或命令行界面启用 console 插件选项。
先决条件
- 您有管理访问权限来访问 OpenShift Web 控制台。
-
OpenShift Data Foundation Operator 在
openshift-storage
命名空间上安装并运行。
流程
- 从用户界面
- 在 OpenShift Web 控制台中,点 Operators → Installed Operators 查看所有已安装的 Operator。
-
确保所选 项目 为
openshift-storage
。 - 单击 OpenShift Data Foundation operator。
启用 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 并验证 OpenShift Data Foundation 是否可用。