OpenShift Container Storage 故障排除
如何排除 OpenShift Container Storage 中的错误和问题
摘要
使开源包含更多
红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。如需了解更多详细信息,请参阅 CTO Chris Wright 信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。提供反馈:
关于特定内容的简单评论:
- 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
- 用鼠标指针高亮显示您想评论的文本部分。
- 点在高亮文本上弹出的 Add Feedback。
- 按照显示的步骤操作。
要提交更复杂的反馈,请创建一个 Bugzilla ticket:
- 进入 Bugzilla 网站。
- 在 Component 部分中,选择 文档。
- 在 Description 中输入您要提供的信息。包括文档相关部分的链接。
- 点 Submit Bug。
第 1 章 概述
OpenShift Container Storage 故障排除旨在帮助管理员了解如何排除故障并修复其 Red Hat OpenShift Container Storage 集群。
大多数故障排除任务都侧重于修复或临时解决方案。本文档根据管理员可能遇到的错误分为若干章节:
- 第 2 章 使用 must-gather 下载日志文件和诊断信息 演示了如何在 OpenShift Container Storage 中使用 must-gather 工具。
- 第 3 章 故障排除所需的常见日志 演示了如何获取 OpenShift Container Storage 所需的日志文件。
- 第 6 章 对 OpenShift Container Storage 中的警报和错误进行故障排除 如何识别遇到的错误并执行所需的操作。
第 2 章 使用 must-gather 下载日志文件和诊断信息
如果 Red Hat OpenShift Container Storage 无法自动解决问题,请使用 must-gather 工具收集日志文件和诊断信息,以便您或红帽支持可以查看问题并确定解决方案。
当 OpenShift Container Storage 部署为外部模式时,must-gather 仅从 Red Hat OpenShift Container Storage 集群收集日志,且不会从外部 Red Hat Ceph Storage 集群收集调试数据和日志。要从外部 Red Hat Ceph Storage 集群收集调试日志,请参阅 Red Hat Ceph Storage 故障排除指南并联系您的 Red Hat Ceph Storage 管理员。
流程
从连接到 OpenShift Container Storage 集群的客户端运行
must-gather
命令:$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.8 --dest-dir=<directory-name>
这会在指定目录中收集以下信息:
- 所有与 OpenShift Container Storage 集群相关的自定义资源(CR)及其命名空间。
- 与 OpenShift Container Storage 相关的所有 Pod 的 Pod 日志。
- 某些标准 Ceph 命令的输出,如状态、集群运行状况等。
命令变体
如果一个或多个 master 节点没有处于 Ready 状态,请使用
--node-name
指定一个状态为 Ready 的 master 节点,以便可以安全地调度must-gather
pod。$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.8 --dest-dir=<directory-name> --node-name=<node-name>
如果要从特定时间收集信息:
要为收集的日志指定相对时间段(例如在 5 秒内或在 2 天内),添加
/usr/bin/gather since=<duration>
:$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.8 --dest-dir=<directory-name> /usr/bin/gather since=<duration>
要指定在以后的一个特定时间收集日志,添加
/usr/bin/gather since-time=<rfc3339-timestamp>
:$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.8 --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 Container Storage 故障排除的常用日志,以及生成这些日志的命令。
为特定 pod 生成日志:
$ oc logs <pod-name> -n <namespace>
为 Ceph 或 OpenShift Container Storage 集群生成日志:
$ 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 Container Storage 日志:
$ oc cluster-info dump -n openshift-storage --output-directory=<directory-name>
检查 OpenShift Container Storage operator 日志和事件。
检查 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 Container Storage operator 版本和频道。
# oc get csv -n openshift-storage
输出示例:
NAME DISPLAY VERSION REPLACES PHASE ocs-operator.v4.7.2 OpenShift Container Storage 4.7.2 Succeeded
# oc get subs -n openshift-storage
输出示例:
NAME PACKAGE SOURCE CHANNEL ocs-operator ocs-operator redhat-operators stable-4.8
确认已创建了安装计划。
# oc get installplan -n openshift-storage
在更新 OpenShift Container Storage 后验证组件的镜像。
检查您要在其上验证镜像运行的组件 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
输出示例:
IMAGE TAG IMAGEID SIZE registry.redhat.io/ocs4/rook-ceph-rhel8-operator@sha256 <none> 5600a36370df4 1.55GB
记录
IMAGEID
,并将其映射到 Rook Ceph Operator 页面中的 Digest ID。
其他资源
第 4 章 部署后覆盖 OpenShift Container Storage 的集群范围默认节点选择器
当将集群范围的默认节点选择器用于 Openshift Container Storage 时,CSI daemonset 生成的 pod 只能在与选择器匹配的节点上启动。要能够从与选择器不匹配的节点中使用 Openshift Container Storage,请在命令行界面中执行以下步骤来覆盖集群范围的默认节点选择器
:
流程
为 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 Container Storage 中的警报和错误进行故障排除
6.1. 解决警报和错误
Red Hat OpenShift Container Storage 可以检测并自动解决很多常见的故障情况。但是,有些问题需要管理员介入。
要了解当前触发的错误,请查看以下位置之一:
- Monitoring → Alerting → Firing 选项
- Home → Overview → Cluster 标签页
- Storage → Overview → Block and File 标签页
- Storage → Overview → Object 标签页
复制显示的错误并在以下部分搜索它以了解其严重性和解决方案:
Name:
Message:
Description: 严重性: 警告 解决方案 :修复 流程 :检查用户界面和日志,并验证更新是否进行中。
|
名称:
Message:
Description: 严重性: 警告 解决方案 :修复 流程 :检查用户界面和日志,并验证更新是否进行中。
|
名称 :
消息 :
描述 : 严重性: 关键 解决方案 :修复 流程 :删除不必要的数据或扩展集群。 |
名称 :
修复了:
描述 : 严重性: 警告 解决方案 :修复 流程 :删除不必要的数据或扩展集群。 |
Name:
Message:
Description 严重性: 警告 解决方案 :临时解决方案 |
名称:
Message:
描述 严重性: 警告 解决方案 :修复 |
Name:
Message:
Description 严重性: 警告 解决方案 :修复 |
名称:
Message
Description 严重性: 警告 解决方案 :修复 |
Name:
Message
Description 严重性: 警告 解决方案 :修复 |
Name:
Message
描述 严重性: 警告 解决方案 :修复 |
Name:
消息 :
Description 严重性: 警告 解决方案 :修复 |
Name:
Message:
描述 严重性: 警告 解决方案 :临时解决方案 |
Name:
消息 :
描述 : 严重性: 警告 解决方案 :修复 |
Name:
Message
描述 : 严重性: 警告 解决方案 :修复 |
名称 :
Message
描述 : 严重性: 警告 解决方案 :修复 |
Name:
Message Description: `Minimum required replicas for storage metadata service not available. 可能会影响存储集群的工作。 严重性: 警告 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
描述 严重级别: Critical 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
描述: 严重级别: Critical 解决方案 :请联系红帽支持 流程 :
|
名称 :
消息:
Description : 严重级别: Critical 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
描述: 严重性: 警告 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
描述 : 严重性: 警告 解决方案 :请联系红帽支持 |
名称 :
Message:
描述 严重级别: Critical 解决方案 :请联系红帽支持 |
名称 :
Message:
描述: 严重级别: Critical 解决方案 :请联系红帽支持 |
名称 :
Message:
描述 : 严重性: 警告 解决方案 :请联系红帽支持 |
Name:
Message:
描述: 严重性: 警告 解决方案 :请联系红帽支持 |
名称 :
消息 :
描述 : 严重级别: Critical 解决方案 :请联系红帽支持 |
名称 :
Message:
描述: 严重级别: Critical 解决方案 :请联系红帽支持 流程 :
|
名称 :
Message:
描述 : 严重级别: Critical 解决方案 :请联系红帽支持 |
6.2. 解决 NooBaa Bucket 错误状态
流程
- 登录到 OpenShift Web 控制台并点 Storage → Overview → Object。
- 在 详细信息 卡中,点 系统名称 字段下的链接。
- 在左侧窗格中,点 Buckets 选项并搜索处于错误状态的存储桶。如果处于错误状态的存储桶是一个命名空间存储桶,请确定点 Namespace Buckets 窗格。
- 点它的 Bucket Name。此时会显示存储桶中遇到的错误。
根据存储桶的具体错误,执行以下操作之一或两者:
对于与空间相关的错误:
- 在左侧窗格中,点 Resources 选项。
- 单击处于错误状态的资源。
- 通过添加更多代理来缩放资源。
对于资源健康错误:
- 在左侧窗格中,点 Resources 选项。
- 单击处于错误状态的资源。
- 连接错误意味着后备服务不可用,需要恢复。
- 如需访问/权限错误,请更新连接的访问密钥和机密密钥。
6.3. 解决 NooBaa Bucket Exceeding Quota State 问题
要解决 A NooBaa Bucket Is In Exceeding Quota State 错误,请执行以下操作之一:
- 清理存储桶上的一些数据。
执行以下步骤增加存储桶配额:
- 登录到 OpenShift Web 控制台并点 Storage → Overview → Object。
- 在 详细信息 卡中,点 系统名称 字段下的链接。
- 在左侧窗格中,点 Buckets 选项并搜索处于错误状态的存储桶。
- 点它的 Bucket Name。此时会显示存储桶中遇到的错误。
- 点 Bucket Policies → Edit Quota 并增加配额。
6.4. 解决 NooBaa Bucket Capacity 或 Quota State 问题
流程
- 登录到 OpenShift Web 控制台并点 Storage → Overview → Object。
- 在 详细信息 卡中,点 系统名称 字段下的链接。
- 在左侧窗格中,点 Resources 选项,再搜索 PV 池资源。
- 对于容量低状态的 PV 池资源,请点其资源名称。
- 编辑池配置并增加代理数量。
6.5. 恢复 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.6. 从 EBS 卷分离中恢复
当 OSD 磁盘所驻留的 OSD 或 MON 弹性块存储(EBS)卷与工作程序 Amazon EC2 实例分离时,该卷会在一两分钟内自动重新附加。但是,OSD 容器集进入 CrashLoopBackOff
状态。若要将 pod 恢复并恢复为 Running
状态,您必须重新启动 EC2 实例。
6.7. 为 rook-ceph-operator 启用和禁用 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: 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 章 检查 Local Storage Operator 部署
带有 Local Storage Operator 的 OpenShift Container Storage 集群使用本地存储设备进行部署。要查找您的 OpenShift Container Storage 现有集群是否使用本地存储设备进行了部署,请使用以下步骤:
先决条件
-
OpenShift Container Storage 在
openshift-storage
命名空间内安装并运行。
流程
通过检查与 OpenShift Container Storage 集群的持久性卷声明(PVC)关联的存储类,您可以确定集群是否使用本地存储设备部署。
使用以下命令,检查与 OpenShift Container Storage 集群 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-xxxxxxx:(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 Container Storage 中恢复监控 pod
如果所有三个容器集都停止,以及 OpenShift Container Storage 无法自动恢复监控 pod,则恢复监控 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 Container Storage 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 章 更改 OpenShift Container Storage 组件的资源
安装 OpenShift Container Storage 时,它附带了 OpenShift Container Storage Pod 可消耗的预定义资源。在某些情况下,可能需要提高 I/O 负载。
- 要更改 rook-ceph pod 上的 CPU 和内存资源,请参阅 第 11.1 节 “更改 rook-ceph pod 上的 CPU 和内存资源”。
- 要调整 Multicloud 对象网关(MCG)的资源,请参阅 第 11.2 节 “为 MCG 调整资源”。
11.1. 更改 rook-ceph pod 上的 CPU 和内存资源
安装 OpenShift Container Storage 时,它附带了 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>
- 指定存储集群的名称。
例 11.1. 示例
# 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>
- 指定存储集群的名称。
例 11.2. 示例
# oc patch -n openshift-storage storagecluster ocs-storagecluster \ --type merge \ --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "2","memory": "8Gi"},"requests": {"cpu": "2","memory": "8Gi"}}}}}'
11.2. 为 MCG 调整资源
Multicloud 对象网关(MCG)的默认配置针对低资源消耗和不性能进行了优化。有关如何调整 MCG 资源的更多信息,请参阅用于多云对象网关(NooBaa)的红帽知识库解决方案性能调整指南。