Red Hat OpenShift Container Storage のトラブルシューティング
OpenShift Container Storage のエラーおよび問題のトラブルシューティング方法
概要
第1章 概要
OpenShift Container Storage のトラブルシューティングは、管理者が Red Hat OpenShift Container Storage クラスターのトラブルシューティングおよび修正を行う方法を理解するのに役立ちます。
ほとんどのトラブルシューティングタスクは、修正または回避策のいずれかに重点を置いています。本書は、管理者が直面する可能性のあるエラーに基づいていくつかの章に分類されています。
- 2章must-gather を使用したログファイルおよび診断情報のダウンロード では、OpenShift Container Storage で must-gather ユーティリティーを使用する方法を示します。
- 3章トラブルシューティングに共通して必要になるログ では、OpenShift Container Storage に共通して必要になるログファイルを取得する方法について説明します。
- 5章OpenShift Container Storage のアラートおよびエラーのトラブルシューティング では、発生したエラーを特定し、必要なアクションを実行する方法を示します。
第2章 must-gather を使用したログファイルおよび診断情報のダウンロード
Red Hat OpenShift Container Storage が問題を自動的に解決できない場合、must-gather ツールを使用してログファイルと診断情報を収集し、お客様または Red Hat サポートが問題を確認し、解決策を判別できるようにします。
手順
Openshift Container Storage クラスターに接続されているクライアントから
must-gatherコマンドを実行します。$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.5 --dest-dir=<directory-name> --node-name=<node-name>
ここで、<node-name> は Ready 状態のマスターノードです。
注記--node-nameはオプションで、1 つまたは複数のワーカーノードが Ready 状態にない場合にとくに使用する必要があります。重要OpenShift Container Storage が外部モードでデプロイされる場合、must-gather は Redhat Openshift Container Storage クラスターからのみログを収集し、外部 Red Hat Ceph Storage クラスターからデバッグデータおよびログを収集しません。外部の Red Hat Ceph Storage クラスターからデバッグログを収集するには、Red Hat Ceph Storage の トラブルシューティングガイドを参照するか、または Red Hat Ceph Storage の管理者にお問い合わせください。
これにより、指定されたディレクトリーに以下の情報が収集されます。
- すべての OpenShift Container Storage クラスター関連のカスタムリソース (CR) をそれらの namespace と共に収集します。
- すべての OpenShift Container Storage 関連の Pod の Pod ログを収集します。
- ステータス、クラスターの正常性などの一部の標準的な Ceph コマンドの出力を収集します。
第3章 トラブルシューティングに共通して必要になるログ
OpenShift Container Storage のトラブルシューティングに共通して使用されるログの一部と、それらを生成するコマンドが一覧表示されます。
特定 Pod のログを生成します。
$ oc logs <pod-name> -n <namespace>
Ceph または OpenShift Container Storage クラスターのログを生成します。
$ oc logs rook-ceph-operator-<ID> -n openshift-storage
cephfs または rbd などのプラグイン Pod のログを生成し、app-pod の PVC マウントで問題を検出します。
$ 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
PVC が BOUND 状態にない場合に問題を検出するために、cephfs または rbd プロビジョナー Pod のログを生成します。
$ 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.5.2 OpenShift Container Storage 4.5.2 Succeeded
# oc get subs -n openshift-storage
出力例:
NAME PACKAGE SOURCE CHANNEL ocs-operator ocs-operator redhat-operators stable-4.5
installplan が作成されていることを確認します。
# 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.55GBIMAGEIDを書き留め、これを Rook Ceph Operator ページの Digest ID にマップします。
関連情報
第4章 OpenShift Container Storage デプロイメント後のクラスター全体のデフォルトノードセレクターの上書き
クラスター全体でのデフォルトノードセレクターが Openshift Container Storage に使用される場合、CSI daemonset によって生成される Pod はセレクターに一致するノードでのみ起動できます。セレクターに一致しないノードから Openshift Container Storage を使用できるようにするには、コマンドラインインターフェースで以下の手順を実行して cluster-wide default node selector を上書きします。
手順
openshift-storage namespace の空のノードセレクターを指定します。
$ oc annotate namespace openshift-storage openshift.io/node-selector=
DaemonSets によって生成される元の Pod を削除します。
oc delete pod -l app=csi-cephfsplugin -n openshift-storage oc delete pod -l app=csi-rbdplugin -n openshift-storage
第5章 OpenShift Container Storage のアラートおよびエラーのトラブルシューティング
5.1. アラートとエラーの解決
Red Hat OpenShift Container Storage は、多くの共通する障害シナリオを検出し、これらを自動的に解決できます。ただし、一部の問題には管理者の介入が必要です。
現在発生しているエラーを確認するには、以下のいずれかの場所を確認します。
- Monitoring → Alerting → Firing オプション
- Home → Overview → Overview タブ
- Home → Overview → Persistent Storage タブ
- Home → Overview → Object Service タブ
表示されるエラーをコピーして、これを以下のセクションで検索し、その重大度と解決策を確認します。
|
Name:
Message:
Description: Severity: Warning Resolution: Fix Procedure: Inspect the user interface and log, and verify if an update is in progress.
|
|
Name:
Message:
Description: Severity: Warning Resolution: Fix Procedure: Inspect the user interface and log, and verify if an update is in progress.
|
|
Name:
Message:
Description: Severity: Crtical Resolution: Fix Procedure: Remove unnecessary data or expand the cluster. |
|
Name:
Fixed:
Description: Severity: Warning Resolution: Fix Procedure: Remove unnecessary data or expand the cluster. |
|
Name:
Message:
Description: Severity: Warning Resolution: Workaround Procedure: Resolving NooBaa Bucket Error State |
|
Name:
Message:
Description: Severity: Warning Resolution: Fix |
|
Name:
Message:
Description: Severity: Warning Resolution: Fix |
|
Name:
Message:
Description: Severity: Warning Resolution: Fix |
|
Name:
Message:
Description: Severity: Warning Resolution: Fix |
|
Name:
Message:
Description: Severity: Warning Resolution: Workaround Procedure: Resolving NooBaa Bucket Error State |
|
Name:
Message:
Description: Severity: Warning Resolution: Fix |
|
Name:
Message:
Description: Severity: Warning Resolution: Fix |
|
Name:
Message:
Description: Severity: Warning Resolution: Fix |
|
Name:
Message: Description: `Minimum required replicas for storage metadata service not available. Might affect the working of storage cluster.` Severity: Warning Resolution: Contact Red Hat support Procedure:
|
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
|
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support Procedure:
|
|
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support |
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
|
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support |
|
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support |
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
5.2. NooBaa Bucket エラー状態の解決
手順
- OpenShift Web コンソールにログインし、Object Service をクリックします。
- Details カードの System Name フィールドにあるリンクをクリックします。
- 左側のペインで、Buckets オプションをクリックし、エラー状態のバケットを検索します。
- その Bucket Name をクリックします。バケットで発生しているエラーが表示されます。
バケットの特定のエラーに応じて、以下のいずれかまたは両方を実行します。
領域に関連するエラーの場合:
- 左側のペインで Resources オプションをクリックします。
- エラー状態のリソースをクリックします。
- エージェントを追加してリソースをスケーリングします。
リソースの正常性エラーの場合:
- 左側のペインで Resources オプションをクリックします。
- エラー状態のリソースをクリックします。
- 接続エラーは、バッキングサービスが利用できないため、復元する必要があることを示します。
- アクセス/パーミッションのエラーについては、接続の Access Key および Secret Key を更新します。
5.3. クォータを超過した状態の NooBaa Bucket の解決
A NooBaa Bucket Is In Exceeding Quota State エラーを解決するには、以下のいずれかを実行します。
- バケットの一部のデータをクリーンアップします。
以下の手順に従って、バケットクォータを増やします。
- OpenShift Web コンソールにログインし、Object Service をクリックします。
- Details カードの System Name フィールドにあるリンクをクリックします。
- 左側のペインで、Buckets オプションをクリックし、エラー状態のバケットを検索します。
- その Bucket Name をクリックします。バケットで発生しているエラーが表示されます。
- Bucket Policies → Edit Quota をクリックし、クォータを増やします。
5.4. NooBaa バケット容量またはクォータの状態の解決
手順
- OpenShift Web コンソールにログインし、Object Service をクリックします。
- Details カードの System Name フィールドにあるリンクをクリックします。
- 左側のペインで Resources オプションをクリックし、PV プールリソースを検索します。
- 容量が低いステータスの PV プールリソースについては、そのResource Name をクリックします。
- プール設定を編集し、エージェントの数を増やします。
5.5. Pod のリカバリー
一部の問題により最初のノード（例: NODE1）が NotReady 状態になると、ReadWriteOnce (RWO) アクセスモードで PVC を使用するホストされた Pod は、2 つ目のノード（例: NODE2) に移行しようとしますが、multi-attach エラーにより停止します。このような場合には、以下の手順に従って MON、OSD、およびアプリケーション Pod を回復できます。
手順
-
（AWS または vSphere 側から）
NODE1の電源をオフにし、NODE1が完全に停止していることを確認します。 以下のコマンドを使用して
NODE1で Pod を強制的に削除します。$ oc delete pod <pod-name> --grace-period=0 --force
5.6. EBS ボリュームの割り当て解除からのリカバリー
OSD ディスクがある OSD または MON Elastic Block Storage (EBS) ボリュームがワーカー Amazon EC2 インスタンスからアタッチ解除すると、ボリュームは 1 分または 2 分以内に自動的に再度アタッチされます。ただし、OSD Pod は CrashLoopBackOff 状態になります。Pod を回復して Running 状態に戻すには、EC2 インスタンスを再起動する必要があります。
第6章 ローカルストレージ Operator デプロイメントの確認
ローカルストレージ Operator を使用する OpenShift Container Storage クラスターはローカルストレージデバイスを使用してデプロイされます。ローカルストレージデバイスを使用して既存のクラスターが OpenShift Container Storage と共にデプロイされているかどうかを確認するには、以下の手順に従います。
前提条件
-
OpenShift Container Storage が
openshift-storagenamespace にインストールされ、実行されている。
手順
OpenShift Container Storage クラスターの Persistent Volume Claim（永続ボリューム要求、PVC）に関連付けられたストレージクラスをチェックすることにより、ローカルストレージデバイスを使用してクラスターがデプロイされているかどうかを確認できます。
以下のコマンドを使用して、OpenShift Container Storage クラスターの PVC に関連付けられたストレージクラスを確認します。
$ oc get pvc -n openshift-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
第7章 トラブルシューティングおよびアンインストール時の残りのリソースの削除
Operator によって管理されるカスタムリソースの一部は、必要なすべてのクリーンアップタスクを実行しても、ファイナライザーで「Terminating」ステータスのままになり、完了まで待機する必要がある場合があります。このような場合には、このようなリソースを強制的に削除する必要があります。これを実行しないと、すべてのアンインストール手順を実行しても、リソースは「Terminating」状態のままになります。
openshift-storage namespace が削除時に「Terminating」状態のままであるかどうかを確認します。
$ oc get project openshift-storage
出力:
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
問題が解決しない場合は、Red Hat サポートにご連絡ください。
第8章 外部モードでの CephFS PVC 作成のトラブルシューティング
Red Hat Ceph Storage クラスターを以前のリリースからバージョン 4.1.1 以降に更新し、これが新規にデプロイされたクラスターではない場合、Red Hat Ceph Storage クラスターで CephFS プールのアプリケーションタイプを手動で設定し、外部モードで CephFS PVC の作成を有効にする必要があります。
CephFS pvc が
Pendingステータスで停止しているかどうかを確認します。$ oc get pvc
出力例:
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-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx: (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) の設定を確認します。コマンドを実行するには、jqを Red Hat Ceph Storage クライアントノードに事前にインストールする必要があります。# 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
出力例:
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 [...]
