6.3. クラスターアラートの解決

PDF

OpenShift Data Foundation ユーザーインターフェイスに表示される Red Hat Ceph Storage クラスターが出力する可能性のある正常性アラートには限りがあります。これらは、固有の識別子を持つ正常性アラートとして定義されています。識別子は、ツールが正常性チェックを理解し、その意味を反映する方法でそれらを提示できるようにすることを目的とした、簡潔な疑似人間可読文字列です。詳細の確認とトラブルシューティングを行うには、正常性アラートをクリックしてください。

表6.1 クラスターの正常性アラートの種類
正常性アラート	概要
CephClusterCriticallyFull	ストレージクラスターの使用率が 80% を超えました。
CephClusterErrorState	ストレージクラスターが 10 分以上エラー状態になっています。
CephClusterNearFull	ストレージクラスターが最大容量に近づいています。データの削除またはクラスターの拡張が必要です。
CephClusterReadOnly	ストレージクラスターは現在読み取り専用であり、すぐにデータを削除するか、クラスターを拡張する必要があります。
CephClusterWarningState	ストレージクラスターが 10 分以上警告状態になっています。
CephDataRecoveryTakingTooLong	データ復旧が長期間アクティブになっています。
CephMdsCacheUsageHigh	MDS デーモンの Ceph メタデータサービス (MDS) のキャッシュ使用量が、`mds_cache_memory_limit` の 95% を超えました。
CephMdsCpuUsageHigh	MDS デーモンの Ceph MDS の CPU 使用率が、適切なパフォーマンスのしきい値を超えました。
CephMdsMissingReplicas	ストレージメタデータサービスに最低限必要なレプリカが利用できません。ストレージクラスターの動作に影響を与える可能性があります。
CephMgrIsAbsent	Alertmanager が Prometheus のターゲット検出に表示されません。
CephMgrIsMissingReplicas	Ceph マネージャーにレプリカがありません。これにより、正常性ステータスのレポートが作成され、`ceph status` コマンドによってレポートされる情報の一部が失われるか、古くなります。さらに、Ceph マネージャーは、Ceph の既存の機能を拡張することを目的としたマネージャーフレームワークを担当します。
CephMonHighNumberOfLeaderChanges	Ceph モニターのリーダーの変更回数が異常です。
CephMonQuorumAtRisk	ストレージクラスターのクォーラムが不足しています。
CephMonQuorumLost	ストレージクラスター内のモニター Pod の数が十分ではありません。
CephMonVersionMismatch	複数の異なるバージョンの Ceph Mon コンポーネントが実行されています。
CephNodeDown	ストレージノードがダウンしました。すぐにノードを確認してください。アラートにノード名が含まれています。
CephOSDCriticallyFull	バックエンドオブジェクトストレージデバイス (OSD) の使用率が 80% を超えました。すぐにスペースを解放するか、ストレージクラスターを拡張するか、サポートにお問い合わせください。
CephOSDDiskNotResponding	いずれかのホストでディスクデバイスが応答していません。
CephOSDDiskUnavailable	いずれかのホストでディスクデバイスにアクセスできません。
CephOSDFlapping	Ceph Storage OSD のフラッピング。
CephOSDNearFull	OSD ストレージデバイスの 1 つが満杯に近づいています。
CephOSDSlowOps	OSD リクエストの処理に時間がかかりすぎています。
CephOSDVersionMismatch	複数の異なるバージョンの Ceph OSD コンポーネントが実行されています。
CephPGRepairTakingTooLong	自己修復操作に時間がかかりすぎています。
CephPoolQuotaBytesCriticallyExhausted	ストレージプールクォータの使用率が 90% を超えました。
CephPoolQuotaBytesNearExhaustion	ストレージプールクォータの使用率が 70% を超えました。
OSDCPULoadHigh	特定 Pod 上の OSD コンテナーの CPU 使用率が 80% を超えており、OSD のパフォーマンスに影響する可能性があります。
PersistentVolumeUsageCritical	永続ボリューム要求の使用率が容量の 85% を超えました。
PersistentVolumeUsageNearFull	永続ボリューム要求の使用量が容量の 75% を超えました。

6.3.1. CephClusterCriticallyFull

意味

ストレージクラスターの使用率が 80% を超えました。85% で読み取り専用になります。使用率が 85% を超えると、Ceph クラスターは読み取り専用になります。すぐにスペースを解放するか、ストレージクラスターを拡張してください。通常、このアラートの前に、オブジェクトストレージデバイス (OSD) デバイスが満杯または満杯に近いことに関連するアラートが表示されます。

影響

High

診断

ストレージのスケーリング: クラスターのタイプに応じて、ストレージデバイス、ノード、またはその両方を追加する必要があります。詳細は、ストレージのスケーリングガイドを参照してください。

軽減策

情報の削除: クラスターをスケールアップできない場合は、情報を削除して領域を解放する必要があります。

6.3.2. CephClusterErrorState

意味	このアラートは、ストレージクラスターが許容できない時間にわたって `ERROR` 状態にあり、ストレージの可用性が低下していることを示しています。このアラートの前にトリガーされた他のアラートを確認し、先にそれらのアラートのトラブルシューティングを行ってください。
影響	Critical

診断

Pod ステータス: 保留

リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
$ oc get pod | grep rook-ceph
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。
```
$ oc describe pod/${MYPOD}
```

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。
```
$ oc logs pod/${MYPOD}
```
重要
- ノードが割り当てられている場合は、ノードの kubelet を確認します。
- 実行中の Pod の基本的な正常性、ノードアフィニティー、およびノードでのリソースの可用性が確認されたら、Ceph ツールを実行してストレージコンポーネントのステータスを取得します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。
```
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
```

6.3.3. CephClusterNearFull

意味	ストレージクラスターの使用率が 75% を超えました。85% で読み取り専用になります。スペースを解放するか、ストレージクラスターを拡張してください。
影響	Critical

診断

ストレージのスケーリング: クラスターのタイプに応じて、ストレージデバイス、ノード、またはその両方を追加する必要があります。詳細は、ストレージのスケーリングガイドを参照してください。

軽減策

情報の削除: クラスターをスケールアップできない場合は、スペースを解放するために情報を削除する必要があります。

6.3.4. CephClusterReadOnly

意味	ストレージクラスターの使用率が 85% を超えたため、読み取り専用になります。すぐにスペースを解放するか、ストレージクラスターを拡張してください。
影響	Critical

診断

ストレージのスケーリング: クラスターのタイプに応じて、ストレージデバイス、ノード、またはその両方を追加する必要があります。詳細は、ストレージのスケーリングガイドを参照してください。

軽減策

情報の削除: クラスターをスケールアップできない場合は、スペースを解放するために情報を削除する必要があります。

6.3.5. CephClusterWarningState

意味

このアラートは、ストレージクラスターが許容できない期間にわたって警告状態にあったことを示しています。この状態でもストレージ操作は機能しますが、クラスターが操作を試みてエラー状態にならないように、エラーを修正することを推奨します。このアラートの前にトリガーされた他のアラートを確認し、先にそれらのアラートのトラブルシューティングを行ってください。

影響

High

診断

Pod ステータス: 保留

リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
oc get pod | grep {ceph-component}
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。
```
$ oc describe pod/${MYPOD}
```

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。
```
$ oc logs pod/${MYPOD}
```
重要
ノードが割り当てられている場合は、ノードの kubelet を確認します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。

$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.6. CephDataRecoveryTakingTooLong

意味	データ復旧に時間がかかっています。すべてのオブジェクトストレージデバイス (OSD) が稼働しているかどうかを確認します。
影響	High

診断

Pod ステータス: 保留

リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
oc get pod | grep rook-ceph-osd
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。
```
$ oc describe pod/${MYPOD}
```

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。
```
$ oc logs pod/${MYPOD}
```
重要
ノードが割り当てられている場合は、ノードの kubelet を確認します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。

$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.7. CephMdsCacheUsageHigh

意味

ストレージメタデータサービス (MDS) がキャッシュ使用量を mds_health_cache_threshold で指定されたターゲットしきい値、または mds_cache_memory_limit で設定されたキャッシュ制限の 150% 以下に維持できない場合、MDS は、キャッシュが大きすぎることを示す正常性アラートをモニターに送信します。その結果、MDS 関連の操作が遅くなります。

影響

High

診断

MDS は、キャッシュ内の未使用のメタデータをトリムし、クライアントキャッシュ内のキャッシュされたアイテムを呼び出すことによって、mds_cache_memory_limit の予約値内に収めようとします。複数のクライアントがファイルにアクセスした結果、クライアントからの呼び出しが遅くなり、MDS がこの制限を超える可能性があります。

軽減策

MDS キャッシュに十分なメモリーがプロビジョニングされていることを確認します。mds_cache_memory_limit を増やすには、ocs-storageCluster で MDS Pod のメモリーリソースを更新する必要があります。次のコマンドを実行して、MDS Pod のメモリーを 16 GB などに設定します。

$ 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 のメモリー制限の半分に自動的に設定します。前のコマンドを使用してメモリーを 8 GB に設定した場合、Operator によって MDS キャッシュメモリーの制限が 4 GB に設定されます。

6.3.8. CephMdsCpuUsageHigh

意味

ストレージメタデータサービス (MDS) は、ファイルシステムのメタデータを提供します。MDS は、ファイルの作成、名前変更、削除、および更新操作に不可欠です。MDS にはデフォルトで 2 つまたは 3 つの CPU が割り当てられます。メタデータ操作が多すぎない限り、問題は発生しません。このアラートがトリガーされるほどメタデータ操作の負荷が増加した場合、デフォルトの CPU 割り当てでは負荷に対応できません。CPU 割り当てを増やす必要があります。

影響

High

診断

Workloads Pods をクリックします。対応する MDS Pod を選択し、Metrics タブをクリックします。使用中の割り当てられている CPU が表示されます。デフォルトでは、使用中の CPU が、6 時間にわたって、割り当てられている CPU の 67% を占めている場合に、アラートが発せられます。その場合は、軽減策セクションの手順に従ってください。

軽減策

割り当てられた CPU を増やす必要があります。

次のコマンドを使用して、MDS に割り当てる CPU の数 (例: 8) を設定します。

$ oc patch -n openshift-storage storagecluster ocs-storagecluster \
    --type merge \
    --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "8"},
    "requests": {"cpu": "8"}}}}}'

6.3.9. CephMdsMissingReplicas

意味	ストレージメタデータサービス (MDS) に最低限必要なレプリカが利用できません。MDS は、メタデータのファイリングを担当します。MDS サービスの低下は、ストレージクラスターの動作 (CephFS ストレージクラスに関連) に影響を与える可能性があるため、できるだけ早く修正する必要があります。
影響	High

診断

Pod ステータス: 保留

リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
oc get pod | grep rook-ceph-mds
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。
```
$ oc describe pod/${MYPOD}
```

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。
```
$ oc logs pod/${MYPOD}
```
重要
ノードが割り当てられている場合は、ノードの kubelet を確認します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。

$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.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
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。
```
$ oc describe pod/${MYPOD}
```

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。
```
$ oc logs pod/${MYPOD}
```
重要
ノードが割り当てられている場合は、ノードの kubelet を確認します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。

$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.11. CephMgrIsMissingReplicas

意味	このアラートを解決するには、Ceph マネージャーが消えた原因を特定し、必要に応じて再起動する必要があります。
影響	High

診断

Pod ステータス: 保留

リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
oc get pod | grep rook-ceph-mgr
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。
```
$ oc describe pod/${MYPOD}
```

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。
```
$ oc logs pod/${MYPOD}
```
重要
ノードが割り当てられている場合は、ノードの kubelet を確認します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。

$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.12. CephMonHighNumberOfLeaderChanges

意味

Ceph クラスターには、ストレージクラスターに関する重要な情報を格納するモニター Pod の冗長セットがあります。モニター Pod は定期的に同期して、ストレージクラスターに関する情報を取得します。最新の情報を取得した最初のモニター Pod は、リーダーになります。その他のモニター Pod は、リーダーに問い合わせてから同期プロセスを開始します。ネットワーク接続の問題や、1 つ以上のモニター Pod で別の種類の問題が生じると、リーダーの異常な変更が発生します。この状況は、ストレージクラスターのパフォーマンスに悪影響を及ぼす可能性があります。

影響

Medium

重要

ネットワークの問題を確認します。ネットワークに問題がある場合は、以下のトラブルシューティング手順に進む前に、OpenShift Data Foundation チームにエスカレートする必要があります。

診断

影響を受けるモニター Pod のログを出力して、問題に関する詳細情報を収集します。
```
$ oc logs <rook-ceph-mon-X-yyyy> -n openshift-storage
```
<rook-ceph-mon-X-yyyy>
影響を受けるモニター Pod の名前を指定します。
または、Openshift Web コンソールを使用して、影響を受けるモニター Pod のログを開きます。考えられる原因に関する詳細情報がログに反映されます。
Pod の一般的なトラブルシューティング手順を実行します。
Pod ステータス: 保留
リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
oc get pod | grep {ceph-component}
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない
readiness プローブを確認します。
```
$ oc describe pod/${MYPOD}
```
Pod ステータス: 保留中ではないが、実行中でもない
アプリケーションまたはイメージの問題を確認します。
```
$ oc logs pod/${MYPOD}
```
重要
ノードが割り当てられている場合は、ノードの kubelet を確認します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。

$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.13. CephMonQuorumAtRisk

意味

複数の MON が連携して冗長性を提供します。各 MON は、メタデータのコピーを保持します。クラスターは 3 つの MON でデプロイされます。クォーラムとストレージ操作を実行するためには、2 つ以上の MON が稼働している必要があります。クォーラムが失われると、データへのアクセスが危険にさらされます。

影響

High

診断

Ceph MON クォーラムを復元します。詳細は、トラブルシューティングガイドの OpenShift Data Foundation での ceph-monitor クォーラムの復元 を参照してください。Ceph MON クォーラムの復元が失敗した場合は、Pod の一般的なトラブルシューティングに従って問題を解決してください。

Pod の一般的なトラブルシューティングでは、次の手順を実行します。

Pod ステータス: 保留

リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
oc get pod | grep rook-ceph-mon
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。

$ oc describe pod/${MYPOD}

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。

$ oc logs pod/${MYPOD}

重要

ノードが割り当てられている場合は、ノードの kubelet を確認します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。

$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.14. CephMonQuorumLost

意味

影響

High

重要

診断

または、Pod の一般的なトラブルシューティングを実行します。

Pod ステータス: 保留

リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
oc get pod | grep {ceph-component}
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。

$ oc describe pod/${MYPOD}

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。

$ oc logs pod/${MYPOD}

重要

ノードが割り当てられている場合は、ノードの kubelet を確認します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。

$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15

6.3.15. CephMonVersionMismatch

意味	通常、このアラートは、アップグレードに長い時間がかかっているときにトリガーされます。
影響	Medium

診断

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` が進行中であることが確認された場合は、5 分間待てば、このアラートは自動的に解決されます。待機した場合、または別のエラーステータス条件が表示された場合は、トラブルシューティングを続けてください。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。
```
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
```

6.3.16. CephNodeDown

意味	Ceph Pod を実行しているノードがダウンしています。Ceph はノード障害に対処するように設計されているため、ストレージ操作は引き続き機能しますが、別のノードがダウンしてストレージ機能に影響を与えるリスクを最小限に抑えるために、問題を解決することを推奨します。
影響	Medium

診断

実行中および障害が発生しているすべての Pod を一覧表示します。
```
oc -n openshift-storage get pods
```
重要
オブジェクトストレージデバイス (OSD) Pod が新しいノードでスケジュールされるように、OpenShift Data Foundation のリソース要件を満たしていることを確認します。Ceph クラスターが障害発生中で現在復旧中の OSD のデータを回復するため、これには数分かかる場合があります。この復旧の動作を確認するには、OSD Pod が新しいワーカーノードに正しく配置されていることを確認します。
障害が発生していた OSD Pod が現在実行されているかどうかを確認します。
```
oc -n openshift-storage get pods
```
障害が発生していた OSD Pod がスケジュールされていない場合は、describe コマンドを使用してイベントを確認し、Pod が再スケジュールされなかった理由を特定します。
障害が発生している OSD Pod のイベントに関する情報を取得します。
```
oc -n openshift-storage get pods | grep osd
```
障害が発生している 1 つ以上の OSD Pod を見つけます。
```
oc -n openshift-storage describe pods/<osd_podname_ from_the_ previous step>
```
イベントセクションで、リソースが満たされていないなど、障害の理由を探します。
さらに、rook-ceph-toolbox を使用して復旧を確認することもできます。このステップはオプションですが、大規模な Ceph クラスターの場合に役立ちます。ツールボックスにアクセスするには、次のコマンドを実行します。
```
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
```
障害が発生したノードがあるかどうかを確認します。
1. ワーカーノードのリストを取得し、ノードのステータスを確認します。
```
oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'
```
2. NotReady ステータスのノードに対して describe を使用し、障害に関する詳細情報を取得します。
```
oc describe node <node_name>
```

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。
```
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
```

6.3.17. CephOSDCriticallyFull

意味	オブジェクトストレージデバイス (OSD) の 1 つがほぼ満杯です。すぐにクラスターを拡張してください。
影響	High

診断

データの削除によるストレージスペースの解放: データを削除すると、クラスターは自己修復プロセスを通じてアラートを解決します。

重要

これは、読み取り専用モードではないものの、ほぼ満杯の OpenShift Data Foundation クラスターにのみ適用されます。読み取り専用モードでは、データの削除を含む変更、つまり永続ボリューム要求 (PVC)、永続ボリューム (PV)、またはその両方の削除を含む変更が防止されます。

ストレージ容量の拡張: 現在のストレージサイズは 1 TB 未満です

まず拡張能力を評価する必要があります。1 TB のストレージを追加するごとに、クラスターには最低限利用可能な 2 つの vCPU と 8 GiB メモリーを持つノードがそれぞれ 3 つ必要です。

アドオンを使用してストレージ容量を 4 TB に増やすことができます。クラスターは自己修復プロセスによってアラートを解決します。vCPU とメモリーリソースの最小要件が満たされていない場合は、クラスターにさらに 3 つのワーカーノードを追加する必要があります。

軽減策

現在のストレージサイズが 4 TB の場合は、Red Hat サポートにお問い合わせください。
オプション: 次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。
```
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
```

6.3.18. CephOSDDiskNotResponding

意味	ディスクデバイスが応答していません。すべてのオブジェクトストレージデバイス (OSD) が稼働しているかどうかを確認します。
影響	Medium

診断

Pod ステータス: 保留

リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
$ oc get pod | grep rook-ceph
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。
```
$ oc describe pod/${MYPOD}
```

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。
```
$ oc logs pod/${MYPOD}
```
重要
- ノードが割り当てられている場合は、ノードの kubelet を確認します。
- 実行中の Pod の基本的な正常性、ノードアフィニティー、およびノードでのリソースの可用性が確認されたら、Ceph ツールを実行してストレージコンポーネントのステータスを取得します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。
```
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
```

6.3.19. CephOSDDiskUnavailable

意味	いずれかのホストでディスクデバイスにアクセスできず、対応するオブジェクトストレージデバイス (OSD) が Ceph クラスターによって out とマークされています。このアラートは、Ceph ノードが 10 分以内に回復に失敗した場合に発生します。
影響	High

診断

障害が発生したノードの特定

ワーカーノードのリストを取得し、ノードのステータスを確認します。

oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'

NotReady ステータスのノードに対して describe を使用し、障害に関する詳細情報を取得します。
```
oc describe node <node_name>
```

6.3.20. CephOSDFlapping

意味	過去 5 分間にストレージデーモンが 5 回再起動しました。Pod イベントまたは Ceph のステータスを確認し、原因を突き止めてください。
影響	High

診断

Red Hat Ceph Storage トラブルシューティングガイドの OSD のフラップセクションの手順に従います。

または、Pod の一般的なトラブルシューティング手順に従います。

Pod ステータス: 保留

リソースの問題、保留中の永続ボリューム要求 (PVC)、ノードの割り当て、および kubelet の問題を確認します。
```
$ oc project openshift-storage
```
```
$ oc get pod | grep rook-ceph
```
問題のある Pod として識別された Pod の変数として MYPOD を設定します。
```
# 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 ステータス: 保留中や実行中ではないが、準備完了状態でもない

readiness プローブを確認します。
```
$ oc describe pod/${MYPOD}
```

Pod ステータス: 保留中ではないが、実行中でもない

アプリケーションまたはイメージの問題を確認します。
```
$ oc logs pod/${MYPOD}
```
重要
- ノードが割り当てられている場合は、ノードの kubelet を確認します。
- 実行中の Pod の基本的な正常性、ノードアフィニティー、およびノードでのリソースの可用性が確認されたら、Ceph ツールを実行してストレージコンポーネントのステータスを取得します。

軽減策

デバッグログの情報

この手順はオプションです。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。
```
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.15
```

6.3.21. CephOSDNearFull

意味	バックエンドストレージデバイスのオブジェクトストレージデバイス (OSD) の使用率が、ホストで 75% を超えました。
影響	High

軽減策

クラスター内のスペースを解放するか、ストレージクラスターを拡張するか、Red Hat サポートにお問い合わせください。ストレージのスケーリングの詳細は、ストレージのスケーリングガイドを参照してください。

6.3.22. CephOSDSlowOps

意味	リクエストが遅いオブジェクトストレージデバイス (OSD) とは、`osd_op_complaint_time` パラメーターで定義される時間内にキュー内の 1 秒あたりの I/O 操作 (IOPS) を処理しないすべての OSD です。デフォルトでは、このパラメーターは 30 秒に設定されています。
影響	Medium

診断

遅いリクエストの詳細は、Openshift コンソールを使用して取得できます。

OSD Pod ターミナルにアクセスし、次のコマンドを実行します。
```
$ ceph daemon osd.<id> ops
```
```
$ ceph daemon osd.<id> dump_historic_ops
```
注記
OSD の番号は Pod 名に表示されます。たとえば、rook-ceph-osd-0-5d86d4d8d4-zlqkx では、<0> が OSD です。

軽減策

OSD のリクエストが遅い主な原因は次のとおりです。

ディスクドライブ、ホスト、ラック、ネットワークスイッチなどの基礎となるハードウェアまたはインフラストラクチャーに関する問題Openshift 監視コンソールを使用して、クラスターリソースに関するアラートまたはエラーを見つけます。これにより、OSD の操作が遅くなる根本原因を把握できます。
ネットワークの問題。これらの問題は、通常、OSD のフラップに関連しています。Red Hat Ceph Storage トラブルシューティングガイドの OSD のフラップセクションを参照してください。
ネットワークに問題がある場合は、OpenShift Data Foundation チームにエスカレートされます。
システムの負荷。Openshift コンソールを使用して、OSD Pod と OSD を実行しているノードのメトリクスを確認します。より多くのリソースを追加または割り当てることが、解決策になる可能性があります。

6.3.23. CephOSDVersionMismatch

意味	通常、このアラートは、アップグレードに長い時間がかかっているときにトリガーされます。
影響	Medium

診断

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` が進行中であることが確認された場合は、5 分間待てば、このアラートは自動的に解決されます。待機した場合、または別のエラーステータス条件が表示された場合は、トラブルシューティングを続けてください。

6.3.24. CephPGRepairTakingTooLong

意味	自己修復操作に時間がかかりすぎています。
影響	High

診断

一貫性のない配置グループ (PG) を確認し、修正します。詳細は、Red Hat ナレッジベースソリューション Ceph の一貫性のない配置グループの処理を参照してください。

6.3.25. CephPoolQuotaBytesCriticallyExhausted

意味	1 つ以上のプールがクォータに達したか、ほぼ達しています。このエラー状態を引き起こすための閾値は、`mon_pool_quota_crit_threshold` 設定オプションで制御されます。
影響	High

軽減策

プールクォータを調整します。次のコマンドを実行して、プールクォータを完全に削除するか、上下に調整します。

ceph osd pool set-quota <pool> max_bytes <bytes>

ceph osd pool set-quota <pool> max_objects <objects>

クォータ値を 0 に設定すると、クォータが無効になります。

6.3.26. CephPoolQuotaBytesNearExhaustion

意味	1 つまたは複数のプールが、設定された満杯のしきい値に近づいています。この警告状態を引き起こす可能性のあるしきい値としては、`mon_pool_quota_warn_threshold` 設定オプションがあります。
影響	High

軽減策

プールクォータを調整します。次のコマンドを実行して、プールクォータを完全に削除するか、上下に調整します。

ceph osd pool set-quota <pool> max_bytes <bytes>

ceph osd pool set-quota <pool> max_objects <objects>

クォータ値を 0 に設定すると、クォータが無効になります。

6.3.27. OSDCPULoadHigh

意味	OSD は Ceph Storage の重要なコンポーネントであり、データの配置と回復の管理を担当します。OSD コンテナー内の CPU 使用率が高い場合、処理要求が増加していることを示しています。その結果、ストレージパフォーマンスが低下する可能性があります。
影響	High

診断

Kubernetes ダッシュボードまたは同等のダッシュボードに移動します。
Workloads セクションにアクセスし、OSD のアラートに関連する適切な Pod を選択します。
Metrics タブをクリックし、OSD コンテナーの CPU メトリクスを表示します。
CPU 使用率が (アラート設定の指定のとおり) 一定期間にわたって 80% を超えていることを確認します。

軽減策

OSD の CPU 使用率が常に高い場合は、次の手順の実施を検討してください。

ストレージクラスターの全体的なパフォーマンスを評価し、CPU 使用率が高くなる原因となっている OSD を特定します。
既存のノードに新しいストレージデバイスを追加するか、新しいストレージデバイスを備えた新しいノードを追加して、クラスター内の OSD の数を増やします。負荷の分散やシステム全体のパフォーマンス向上に役立つ方法については、ストレージのスケーリングガイドを確認してください。

6.3.28. PersistentVolumeUsageCritical

意味	永続ボリューム要求 (PVC) が最大容量に近づいており、タイムリーに対処しないとデータが失われる可能性があります。
影響	High

軽減策

PVC サイズを拡張して容量を増やします。

OpenShift Web コンソールにログインします。
Storage PersistentVolumeClaim をクリックします。
Project ドロップダウンリストから openshift-storage を選択します。
拡張したい PVC で、Action menu (⋮) Expand PVC をクリックします。
Total size を目的のサイズに更新します。
Expand をクリックします。

または、スペースを占有している可能性のある不要なデータを削除することもできます。

6.3.29. PersistentVolumeUsageNearFull

意味	永続ボリューム要求 (PVC) が最大容量に近づいており、タイムリーに対処しないとデータが失われる可能性があります。
影響	High

軽減策

PVC サイズを拡張して容量を増やします。

OpenShift Web コンソールにログインします。
Storage PersistentVolumeClaim をクリックします。
Project ドロップダウンリストから openshift-storage を選択します。
拡張したい PVC で、Action menu (⋮) Expand PVC をクリックします。
Total size を目的のサイズに更新します。
Expand をクリックします。

または、スペースを占有している可能性のある不要なデータを削除することもできます。

6.3. クラスターアラートの解決

6.3.1. CephClusterCriticallyFull

6.3.2. CephClusterErrorState

6.3.3. CephClusterNearFull

6.3.4. CephClusterReadOnly

6.3.5. CephClusterWarningState

6.3.6. CephDataRecoveryTakingTooLong

6.3.7. CephMdsCacheUsageHigh

6.3.8. CephMdsCpuUsageHigh

6.3.9. CephMdsMissingReplicas

6.3.10. CephMgrIsAbsent

6.3.11. CephMgrIsMissingReplicas

6.3.12. CephMonHighNumberOfLeaderChanges

6.3.13. CephMonQuorumAtRisk

6.3.14. CephMonQuorumLost

6.3.15. CephMonVersionMismatch

6.3.16. CephNodeDown

6.3.17. CephOSDCriticallyFull

6.3.18. CephOSDDiskNotResponding

6.3.19. CephOSDDiskUnavailable

6.3.20. CephOSDFlapping

6.3.21. CephOSDNearFull

6.3.22. CephOSDSlowOps

6.3.23. CephOSDVersionMismatch

6.3.24. CephPGRepairTakingTooLong

6.3.25. CephPoolQuotaBytesCriticallyExhausted

6.3.26. CephPoolQuotaBytesNearExhaustion

6.3.27. OSDCPULoadHigh

6.3.28. PersistentVolumeUsageCritical

6.3.29. PersistentVolumeUsageNearFull

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links