Red Hat OpenShift Container Storage のトラブルシューティング

Red Hat OpenShift Container Storage 4.4

OpenShift Container Storage のエラーおよび問題のトラブルシューティング方法

概要

Red Hat OpenShift Container Storage のトラブルシューティングについては、本書を参照してください。

第1章 概要

OpenShift Container Storage のトラブルシューティングは、管理者が Red Hat 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.4 --dest-dir=<directory-name> --node-name=<node-name>

    ここで、<node-name> は Ready 状態のマスターノードです。

    注記

    --node-name はオプションで、1 つまたは複数のワーカーノードが Ready 状態にない場合にとくに使用する必要があります。

    これにより、指定されたディレクトリーに以下の情報が収集されます。

  • すべての 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>

関連情報

第4章 OpenShift Container Storage デプロイメント後のクラスター全体のデフォルトノードセレクターの上書き

クラスター全体でのデフォルトノードセレクターが Openshift Container Storage に使用される場合、CSI daemonset によって生成される Pod はセレクターに一致するノードでのみ起動できます。セレクターに一致しないノードから Openshift Container Storage を使用できるようにするには、コマンドラインインターフェースで以下の手順を実行して cluster-wide default node selector を上書きします。

手順

  1. openshift-storage namespace の空のノードセレクターを指定します。

    $ oc annotate namespace openshift-storage openshift.io/node-selector=
  2. 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 は、多くの共通する障害シナリオを検出し、これらを自動的に解決できます。ただし、一部の問題には管理者の介入が必要です。

現在発生しているエラーを確認するには、以下のいずれかの場所を確認します。

  • MonitoringAlertingFiring オプション
  • HomeOverviewCluster タブ
  • HomeOverviewPersistent Storage タブ
  • HomeOverviewObject Service タブ

表示されるエラーをコピーして、これを以下のセクションで検索し、その重大度と解決策を確認します。

Name: CephMonVersionMismatch

Message: There are multiple versions of storage services running.

Description: There are {{ $value }} different versions of Ceph Mon components running.

Severity: Warning

Resolution: Fix

Procedure: Inspect the user interface and log, and verify if an update is in progress.

  • If an update in progress, this alert is temporary.
  • If an update is not in progress, restart the upgrade process.

Name: CephOSDVersionMismatch

Message: There are multiple versions of storage services running.

Description: There are {{ $value }} different versions of Ceph OSD components running.

Severity: Warning

Resolution: Fix

Procedure: Inspect the user interface and log, and verify if an update is in progress.

  • If an update in progress, this alert is temporary.
  • If an update is not in progress, restart the upgrade process.

Name: CephClusterCriticallyFull

Message: Storage cluster is critically full and needs immediate expansion

Description: Storage cluster utilization has crossed 85%.

Severity: Crtical

Resolution: Fix

Procedure: Remove unnecessary data or expand the cluster.

Name: CephClusterNearFull

Fixed: Storage cluster is nearing full.Expansion is required.

Description: Storage cluster utilization has crossed 75%.

Severity: Warning

Resolution: Fix

Procedure: Remove unnecessary data or expand the cluster.

Name: NooBaaBucketErrorState

Message: A NooBaa Bucket Is In Error State

Description: A NooBaa bucket {{ $labels.bucket_name }} is in error state for more than 6m

Severity: Warning

Resolution: Workaround

Procedure: Resolving NooBaa Bucket Error State

Name: NooBaaBucketExceedingQuotaState

Message: A NooBaa Bucket Is In Exceeding Quota State

Description: A NooBaa bucket {{ $labels.bucket_name }} is exceeding its quota - {{ printf "%0.0f" $value }}% used message: A NooBaa Bucket Is In Exceeding Quota State

Severity: Warning

Resolution: Fix

Procedure: Resolving NooBaa Bucket Exceeding Quota State

Name: NooBaaBucketLowCapacityState

Message: A NooBaa Bucket Is In Low Capacity State

Description: A NooBaa bucket {{ $labels.bucket_name }} is using {{ printf "%0.0f" $value }}% of its capacity

Severity: Warning

Resolution: Fix

Procedure: Resolving NooBaa Bucket Capacity or Quota State

Name: NooBaaBucketNoCapacityState

Message: A NooBaa Bucket Is In No Capacity State

Description: A NooBaa bucket {{ $labels.bucket_name }} is using all of its capacity

Severity: Warning

Resolution: Fix

Procedure: Resolving NooBaa Bucket Capacity or Quota State

Name: NooBaaBucketReachingQuotaState

Message: A NooBaa Bucket Is In Reaching Quota State

Description: A NooBaa bucket {{ $labels.bucket_name }} is using {{ printf "%0.0f" $value }}% of its quota

Severity: Warning

Resolution: Fix

Procedure: Resolving NooBaa Bucket Capacity or Quota State

Name: NooBaaResourceErrorState

Message: A NooBaa Resource Is In Error State

Description: A NooBaa resource {{ $labels.resource_name }} is in error state for more than 6m

Severity: Warning

Resolution: Workaround

Procedure: Resolving NooBaa Bucket Error State

Name: NooBaaSystemCapacityWarning100

Message: A NooBaa System Approached Its Capacity

Description: A NooBaa system approached its capacity, usage is at 100%

Severity: Warning

Resolution: Fix

Procedure: Resolving NooBaa Bucket Capacity or Quota State

Name: NooBaaSystemCapacityWarning85

Message: A NooBaa System Is Approaching Its Capacity

Description: A NooBaa system is approaching its capacity, usage is more than 85%

Severity: Warning

Resolution: Fix

Procedure: Resolving NooBaa Bucket Capacity or Quota State

Name: NooBaaSystemCapacityWarning95

Message: A NooBaa System Is Approaching Its Capacity

Description: A NooBaa system is approaching its capacity, usage is more than 95%

Severity: Warning

Resolution: Fix

Procedure: Resolving NooBaa Bucket Capacity or Quota State

Name: CephMdsMissingReplicas

Message: Insufficient replicas for storage metadata service.

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:

  1. Check for alerts and operator status.
  2. If the issue cannot be identified, contact Red Hat support.

Name: CephMgrIsAbsent

Message: Storage metrics collector service not available anymore.

Description: Ceph Manager has disappeared from Prometheus target discovery.

Severity: Critical

Resolution: Contact Red Hat support

Procedure:

  1. ユーザーインターフェイスとログを調べて、更新が進行中であるかどうかを確認します。

    • If an update in progress, this alert is temporary.
    • If an update is not in progress, restart the upgrade process.
  2. Once the upgrade is complete, check for alerts and operator status.
  3. If the issue persistents or cannot be identified, contact Red Hat support.

Name: CephNodeDown

Message: Storage node {{ $labels.node }} went down

Description: Storage node {{ $labels.node }} went down.Please check the node immediately.

Severity: Critical

Resolution: Contact Red Hat support

Procedure:

  1. Check which node stopped functioning and its cause.
  2. Take appropriate actions to recover the node.If node cannot be recovered:

Name: CephClusterErrorState

Message: Storage cluster is in error state

Description: Storage cluster is in error state for more than 10m.

Severity: Critical

Resolution: Contact Red Hat support

Procedure:

  1. Check for alerts and operator status.
  2. If the issue cannot be identified, download log files and diagnostic information using must-gather.
  3. Open a Support Ticket with Red Hat Support with an attachment of the output of must-gather.

Name: CephClusterWarningState

Message: Storage cluster is in degraded state

Description: Storage cluster is in warning state for more than 10m.

Severity: Warning

Resolution: Contact Red Hat support

Procedure:

  1. Check for alerts and operator status.
  2. If the issue cannot be identified, download log files and diagnostic information using must-gather.
  3. Open a Support Ticket with Red Hat Support with an attachment of the output of must-gather.

Name: CephDataRecoveryTakingTooLong

Message: Data recovery is slow

Description: Data recovery has been active for too long.

Severity: Warning

Resolution: Contact Red Hat support

Name: CephOSDDiskNotResponding

Message: Disk not responding

Description: Disk device {{ $labels.device }} not responding, on host {{ $labels.host }}.

Severity: Critical

Resolution: Contact Red Hat support

Name: CephOSDDiskUnavailable

Message: Disk not accessible

Description: Disk device {{ $labels.device }} not accessible on host {{ $labels.host }}.

Severity: Critical

Resolution: Contact Red Hat support

Name: CephPGRepairTakingTooLong

Message: Self heal problems detected

Description: Self heal operations taking too long.

Severity: Warning

Resolution: Contact Red Hat support

Name: CephMonHighNumberOfLeaderChanges

Message: Storage Cluster has seen many leader changes recently.

Description: 'Ceph Monitor "{{ $labels.job }}": instance {{ $labels.instance }} has seen {{ $value printf "%.2f" }} leader changes per minute recently.'

Severity: Warning

Resolution: Contact Red Hat support

Name: CephMonQuorumAtRisk

Message: Storage quorum at risk

Description: Storage cluster quorum is low.

Severity: Critical

Resolution: Contact Red Hat support

5.2. NooBaa Bucket エラー状態の解決

手順

  1. OpenShift Web コンソールにログインし、Object Service をクリックします。
  2. Details カードの System Name フィールドにあるリンクをクリックします。
  3. 左側のペインで、Buckets オプションをクリックし、エラー状態のバケットを検索します。
  4. その Bucket Name をクリックします。バケットで発生しているエラーが表示されます。
  5. バケットの特定のエラーに応じて、以下のいずれかまたは両方を実行します。

    1. 領域に関連するエラーの場合:

      1. 左側のペインで Resources オプションをクリックします。
      2. エラー状態のリソースをクリックします。
      3. エージェントを追加してリソースをスケーリングします。
    2. リソースの正常性エラーの場合:

      1. 左側のペインで Resources オプションをクリックします。
      2. エラー状態のリソースをクリックします。
      3. 接続エラーは、バッキングサービスが利用できないため、復元する必要があることを示します。
      4. アクセス/パーミッションのエラーについては、接続の Access Key および Secret Key を更新します。

5.3. クォータを超過した状態の NooBaa Bucket の解決

A NooBaa Bucket Is In Exceeding Quota State エラーを解決するには、以下のいずれかを実行します。

  • バケットの一部のデータをクリーンアップします。
  • 以下の手順に従って、バケットクォータを増やします。

    1. OpenShift Web コンソールにログインし、Object Service をクリックします。
    2. Details カードの System Name フィールドにあるリンクをクリックします。
    3. 左側のペインで、Buckets オプションをクリックし、エラー状態のバケットを検索します。
    4. その Bucket Name をクリックします。バケットで発生しているエラーが表示されます。
    5. Bucket PoliciesEdit Quota をクリックし、クォータを増やします。

5.4. NooBaa バケット容量またはクォータの状態の解決

手順

  1. OpenShift Web コンソールにログインし、Object Service をクリックします。
  2. Details カードの System Name フィールドにあるリンクをクリックします。
  3. 左側のペインで Resources オプションをクリックし、PV プールリソースを検索します。
  4. 容量が低いステータスの PV プールリソースについては、そのResource Name をクリックします。
  5. プール設定を編集し、エージェントの数を増やします。

5.5. Pod のリカバリー

一部の問題により最初のノード(例: NODE1)が NotReady 状態になると、ReadWriteOnce (RWO) アクセスモードで PVC を使用するホストされた Pod は、2 つ目のノード(例: NODE2) に移行しようとしますが、multi-attach エラーにより停止します。このような場合には、以下の手順に従って MON、OSD、およびアプリケーション Pod を回復できます。

手順

  1. (AWS または vSphere 側から) NODE1 の電源をオフにし、NODE1 が完全に停止していることを確認します。
  2. 以下のコマンドを使用して 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-storage namespace にインストールされ、実行されている。

手順

OpenShift Container Storage クラスターの Persistent Volume Claim(永続ボリューム要求、PVC)に関連付けられたストレージクラスをチェックすることにより、ローカルストレージデバイスを使用してクラスターがデプロイされているかどうかを確認できます。

  1. 以下のコマンドを使用して、OpenShift Container Storage クラスターの PVC に関連付けられたストレージクラスを確認します。

    $ oc get pvc -n openshift-storage
  2. 出力を確認します。ローカルストレージ 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