OpenShift Data Foundation のトラブルシューティング
OpenShift Data Foundation のトラブルシューティングの手順
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、用語の置き換えは、今後の複数のリリースにわたって段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック (英語のみ)
Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があれば、ぜひお知らせください。
フィードバックを送信するには、Bugzilla チケットを作成します。
- Bugzilla の Web サイトに移動します。
- Component セクションで、documentation を選択します。
- 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 のアラートおよびエラーのトラブルシューティング では、発生したエラーを特定し、必要なアクションを実行する方法を示します。
Red Hat は、間違ったコマンドを実行するとデータ損失が発生する可能性があるため、OpenShift Data Foundation クラスターでの Ceph コマンドの実行をサポートしていません (Red Hat サポートまたは Red Hat ドキュメントで示されていない限り)。その場合、Red Hat サポートチームは商業的に合理的な努力しか提供できず、データ損失が発生した場合にすべてのデータを復元できない可能性があります。
第2章 must-gather を使用したログファイルおよび診断情報のダウンロード
Red Hat OpenShift Data Foundation が問題を自動的に解決できない場合、must-gather
ツールを使用してログファイルと診断情報を収集し、お客様または Red Hat サポートが問題を確認し、解決策を判別できるようにします。
Red Hat OpenShift Data Foundation が外部モードでデプロイされる場合、must-gather
は OpenShift Data Foundation クラスターからのみログを収集し、外部の Red Hat Ceph Storage クラスターからデバッグデータおよびログを収集しません。外部の Red Hat Ceph Storage クラスターからデバッグログを収集するには、Red Hat Ceph Storage の トラブルシューティングガイド を参照するか、Red Hat Ceph Storage の管理者にお問い合わせください。
前提条件
オプション: OpenShift Data Foundation が非接続環境にデプロイされている場合、個別の
must-gather
イメージを非接続環境で利用できるミラーレジストリーにミラーリングするようにしてください。$ oc image mirror registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.12 <local-registry>/odf4/ocs-must-gather-rhel8:v4.12 [--registry-config=<path-to-the-registry-config>] [--insecure=true]
<local-registry>
- 非接続の OpenShift Container Platform クラスターで利用可能なローカルイメージのミラーレジストリーです。
<path-to-the-registry-config>
-
レジストリー認証情報へのパスで、デフォルトは
~/.docker/config.json
です。 --insecure
- ミラーレジストリーがセキュアでない場合にのみこのフラグを追加します。
詳細は、Red Hat ナレッジベースソリューションを参照してください。
手順
OpenShift Data Foundation クラスターに接続されているクライアントから
must-gather
コマンドを実行します。$ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.12 --dest-dir=<directory-name>
<directory-name>
データを書き込むディレクトリーの名前です。
重要非接続環境のデプロイメントの場合は、
--image
パラメーターのイメージをミラーリングされたmust-gather
イメージに置き換えます。$ oc adm must-gather --image=<local-registry>/odf4/ocs-must-gather-rhel8:v4.12 --dest-dir=<directory-name>
<local-registry>
- 非接続の OpenShift Container Platform クラスターで利用可能なローカルイメージのミラーレジストリーです。
これにより、指定されたディレクトリーに以下の情報が収集されます。
- すべての Red Hat OpenShift Data Foundation クラスター関連のカスタムリソース (CR) とそれらの namespace。
- すべての Red Hat OpenShift Data Foundation 関連の Pod の Pod ログ。
- ステータス、クラスターの正常性などの一部の標準的な Ceph コマンドの出力。
コマンドの差異
状態が Ready ではないマスターノードが 1 つ以上ある場合には、
must-gather
Pod を安全にスケジュールできるように--node-name
を使用して Ready のマスターノードを指定します。$ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.12 --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.12 --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.12 --dest-dir=_<directory-name>_ /usr/bin/gather since-time=<rfc3339-timestamp>
以下のように、これらのコマンドのサンプルの値を置き換えます。
- <node-name>
-
状態が Ready ではないマスターノードが 1 つ以上ある場合には、このパラメーターを使用して、状態がまだ Ready のマスターノード名を指定します。これにより、
must-gather
Pod が準備状態にないマスターノードにスケジュールされないようにすることで、スケジューリングエラーを回避します。 - <directory-name>
-
must-gather
によって収集される情報を保存するディレクトリー。 - <duration>
-
5h
(5 時間前から開始する) など、相対的な期間として情報を収集する期間 (の開始点) を指定します。 - <rfc3339-timestamp>
-
2020-11-10T04:00:00+00:00
(2020 年 11 月 11 日の 4am UTC から開始する) など、RFC 3339 タイムスタンプとして情報を収集する期間 (の開始点) を指定します。
第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 ログは障害に関する情報を提供せず、問題のトラブルシューティングの制限として機能します。Enabling and disabling debug logs for rook-ceph-operatorを参照してください。
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 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 ログおよびイベントを確認します。
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 Operator のバージョンおよびチャネルを取得します。
# oc get csv -n openshift-storage
出力例:
NAME DISPLAY VERSION REPLACES PHASE mcg-operator.v4.12.0 NooBaa Operator 4.12.0 Succeeded ocs-operator.v4.12.0 OpenShift Container Storage 4.12.0 Succeeded odf-csi-addons-operator.v4.12.0 CSI Addons 4.12.0 Succeeded odf-operator.v4.12.0 OpenShift Data Foundation 4.12.0 Succeeded
# oc get subs -n openshift-storage
出力例:
NAME PACKAGE SOURCE CHANNEL mcg-operator-stable-4.12-redhat-operators-openshift-marketplace mcg-operator redhat-operators stable-4.12 ocs-operator-stable-4.12-redhat-operators-openshift-marketplace ocs-operator redhat-operators stable-4.12 odf-csi-addons-operator odf-csi-addons-operator redhat-operators stable-4.12 odf-operator odf-operator redhat-operators stable-4.12
installplan が作成されていることを確認します。
# 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 にマップします。
関連情報
3.1. ログの詳細レベルの調整
ログのデバッグによって消費されるスペースの量は、重大な問題になる可能性があります。Red Hat OpenShift Data Foundation は、ログのデバッグによって消費されるストレージの量を調整して制御する方法を提供します。
デバッグログの詳細レベルを調整するために、CSI 操作を担当するコンテナーのログレベルを調整できます。コンテナーの yaml ファイルで、次のパラメーターを調整してログレベルを設定します。
-
CSI_LOG_LEVEL
- デフォルトは5
-
CSI_SIDECAR_LOG_LEVEL
- デフォルトは1
サポートされている値は 0
~ 5
です。一般的な有用なログには 0
を使用し、トレースレベルの詳細度には 5
を使用します。
第4章 OpenShift Data Foundation デプロイメント後のクラスター全体のデフォルトノードセレクターの上書き
クラスター全体でのデフォルトノードセレクターが OpenShift Data Foundation に使用される場合、CSI daemonset によって生成される Pod はセレクターに一致するノードでのみ起動できます。セレクターに一致しないノードから OpenShift Data Foundation を使用できるようにするには、コマンドラインインターフェイスで以下の手順を実行して 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 Platform Web コンソールにログインします。
- Workloads → Secrets をクリックします。
クラスター全体の暗号化に使用される ocs-kms-token を更新するには、以下を実行します。
-
Project を
openshift-storage
に設定します。 - ocs-kms-token → Actions → Edit Secret をクリックします。
- Value フィールドに暗号化トークンファイルをドラッグアンドドロップまたはアップロードします。トークンには、コピーおよび貼り付けが可能なファイルまたはテキストのいずれかを指定できます。
- Save をクリックします。
-
Project を
暗号化された永続ボリュームのある指定のプロジェクトまたは namespace の ceph-csi-kms-token を更新するには、以下を実行します。
- 必要な Project を選択します。
- 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 → Data Foundation → Storage System → storage system リンクのポップアップ → Overview → Block and File タブ
- Storage → Data Foundation → Storage System → storage system リンクのポップアップ → Overview → Object タブ
表示されるエラーをコピーして、これを以下のセクションで検索し、その重大度と解決策を確認します。
名前:
メッセージ:
説明: 重大度: Warning 解決策: Fix Procedure: Inspect the user interface and log, and verify if an update is in progress.
|
名前:
メッセージ:
説明: 重大度: Warning 解決策: Fix Procedure: Inspect the user interface and log, and verify if an update is in progress.
|
名前:
メッセージ:
説明: 重大度: Crtical 解決策: Fix 手順: 不要なデータを削除するか、クラスターを拡張します。 |
名前:
修正済:
説明: 重大度: Warning 解決策: Fix 手順: 不要なデータを削除するか、クラスターを拡張します。 |
名前:
メッセージ:
説明: 重大度: Warning 解決策: Workaround |
名前:
メッセージ:
説明: 重大度: Warning 解決策: Fix |
名前:
メッセージ:
説明: 重大度: Warning 解決策: Fix |
名前:
メッセージ: 説明: `Minimum required replicas for storage metadata service not available. Might affect the working of storage cluster.` 重大度: Warning 手順:
|
名前:
メッセージ:
説明: 重大度: Critical 手順:
|
Name:
メッセージ:
Description: Severity: Critical 手順:
|
名前:
メッセージ:
説明: 重大度: Critical 手順:
|
名前:
メッセージ:
説明: 重大度: Warning 手順:
|
名前:
メッセージ:
説明: 重大度: Warning |
名前:
メッセージ:
説明: 重大度: Critical |
名前:
メッセージ:
説明: 重大度: Critical |
名前:
メッセージ:
説明: 重大度: Warning |
名前:
メッセージ:
説明: 重大度: Warning |
名前:
メッセージ:
説明: 重大度: Critical |
Name:
Message:
Description: 重大度: Critical 手順:
|
名前:
Message:
Description: 重大度: Critical |
名前:
メッセージ: 説明: 1 つまたはいくつかのアプリケーションで障害復旧が失敗しています。 重大度: Warning |
名前:
メッセージ: 説明: クラスター全体で障害復旧に失敗します。mirror デーモンが 1 分以上異常状態になっています。Mirroring on this cluster is not working as expected. 重大度: Critical |
6.2. クラスターの健全性問題の解決
OpenShift Data Foundation ユーザーインターフェイスに表示される Red Hat Ceph Storage クラスターが出力する可能性のある正常性メッセージには限りがあります。これらは、固有の識別子を持つヘルスチェックとして定義されています。識別子は、ツールが正常性チェックを理解し、その意味を反映する方法でそれらを提示できるようにすることを目的とした、簡潔な疑似人間可読文字列です。詳細情報およびトラブルシューティングを行うには、以下のヘルスコードをクリックします。
正常性コード | 説明 |
---|---|
1 つまたは複数の Ceph Monitor のディスク領域が不足しています。 |
6.2.1. MON_DISK_LOW
この警告は、監視データベースをパーセンテージとして格納するファイルシステムの使用可能な領域が mon_data_avail_warn
を下回る場合にトリガーされます (デフォルトは、15% です)。これは、システム上の他のプロセスまたはユーザーが、モニターで使用されているのと同じファイルシステムを満杯にしていることを示している可能性があります。また、モニターのデータベースが大きいことを示すこともできます。
ファイルシステムへのパスは、mon のデプロイメントによって異なります。mon が storagecluster.yaml
でデプロイされている場所へのパスを見つけることができます。
パスの例:
-
PVC パスにデプロイされる mon:
/var/lib/ceph/mon
-
ホストパス経由でデプロイされる mon:
/var/lib/rook/mon
領域を消去するには、ファイルシステムで使用率の高いファイルを表示し、削除するファイルを選択します。ファイルを表示するには、以下のコマンドを実行します。
# du -a <path-in-the-mon-node> |sort -n -r |head -n10
<path-in-the-mon-node>
を、mon がデプロイされているファイルシステムへのパスに置き換えます。
6.3. クラスターアラートの解決
OpenShift Data Foundation ユーザーインターフェイスに表示される Red Hat Ceph Storage クラスターが出力する可能性のある正常性アラートには限りがあります。これらは、固有の識別子を持つ正常性アラートとして定義されています。識別子は、ツールが正常性チェックを理解し、その意味を反映する方法でそれらを提示できるようにすることを目的とした、簡潔な疑似人間可読文字列です。詳細の確認とトラブルシューティングを行うには、正常性アラートをクリックしてください。
正常性アラート | 概要 |
---|---|
ストレージクラスターの使用率が 80% を超えました。 | |
ストレージクラスターが 10 分以上エラー状態になっています。 | |
ストレージクラスターが最大容量に近づいています。データの削除またはクラスターの拡張が必要です。 | |
ストレージクラスターは現在読み取り専用であり、すぐにデータを削除するか、クラスターを拡張する必要があります。 | |
ストレージクラスターが 10 分以上警告状態になっています。 | |
データ復旧が長期間アクティブになっています。 | |
ストレージメタデータサービスに最低限必要なレプリカが利用できません。ストレージクラスターの動作に影響を与える可能性があります。 | |
Alertmanager が Prometheus のターゲット検出に表示されません。 | |
Ceph マネージャーにレプリカがありません。これにより、正常性ステータスのレポートが作成され、 | |
Ceph モニターのリーダーの変更回数が異常です。 | |
ストレージクラスターのクォーラムが不足しています。 | |
ストレージクラスター内のモニター Pod の数が十分ではありません。 | |
複数の異なるバージョンの Ceph Mon コンポーネントが実行されています。 | |
ストレージノードがダウンしました。すぐにノードを確認してください。アラートにノード名が含まれています。 | |
バックエンドオブジェクトストレージデバイス (OSD) の使用率が 80% を超えました。すぐにスペースを解放するか、ストレージクラスターを拡張するか、サポートにお問い合わせください。 | |
いずれかのホストでディスクデバイスが応答していません。 | |
いずれかのホストでディスクデバイスにアクセスできません。 | |
Ceph Storage OSD のフラッピング。 | |
OSD ストレージデバイスの 1 つが満杯に近づいています。 | |
OSD リクエストの処理に時間がかかりすぎています。 | |
複数の異なるバージョンの Ceph OSD コンポーネントが実行されています。 | |
自己修復操作に時間がかかりすぎています。 | |
ストレージプールクォータの使用率が 90% を超えました。 | |
ストレージプールクォータの使用率が 70% を超えました。 | |
永続ボリューム要求の使用率が容量の 85% を超えました。 | |
永続ボリューム要求の使用量が容量の 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/ocs4/ocs-must-gather-rhel8:v4.6
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/ocs4/ocs-must-gather-rhel8:v4.6
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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.7. 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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.8. 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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.9. 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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.10. 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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.11. 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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.12. CephMonQuorumLost
意味 | Ceph クラスターには、ストレージクラスターに関する重要な情報を格納するモニター Pod の冗長セットがあります。モニター Pod は定期的に同期して、ストレージクラスターに関する情報を取得します。最新の情報を取得した最初のモニター Pod は、リーダーになります。その他のモニター Pod は、リーダーに問い合わせてから同期プロセスを開始します。ネットワーク接続の問題や、1 つ以上のモニター Pod で別の種類の問題が生じると、リーダーの異常な変更が発生します。この状況は、ストレージクラスターのパフォーマンスに悪影響を及ぼす可能性があります。 |
影響 | High |
ネットワークの問題を確認します。ネットワークに問題がある場合は、以下のトラブルシューティング手順に進む前に、OpenShift Data Foundation チームにエスカレートする必要があります。
診断
Ceph MON クォーラムを復元します。詳細は、トラブルシューティングガイド の OpenShift Data Foundation での ceph-monitor クォーラムの復元 を参照してください。Ceph MON クォーラムの復元が失敗した場合は、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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.13. 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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.14. 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
障害が発生したノードがあるかどうかを確認します。
ワーカーノードのリストを取得し、ノードのステータスを確認します。
oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'
NotReady
ステータスのノードに対して describe を使用し、障害に関する詳細情報を取得します。oc describe node <node_name>
軽減策
- デバッグログの情報
この手順は任意です。次のコマンドを実行して、Ceph クラスターのデバッグ情報を収集します。
$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6
6.3.15. 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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.16. 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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.18. 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/ocs4/ocs-must-gather-rhel8:v4.6
6.3.19. CephOSDNearFull
意味 | バックエンドストレージデバイスのオブジェクトストレージデバイス (OSD) の使用率が、ホストで 75% を超えました。 |
影響 | High |
軽減策
クラスター内のスペースを解放するか、ストレージクラスターを拡張するか、Red Hat サポートにお問い合わせください。ストレージのスケーリングの詳細は、ストレージのスケーリングガイド を参照してください。
6.3.20. CephOSDSlowOps
意味 |
リクエストが遅いオブジェクトストレージデバイス (OSD) とは、 |
影響 | 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.21. 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.22. CephPGRepairTakingTooLong
意味 | 自己修復操作に時間がかかりすぎています。 |
影響 | High |
診断
一貫性のない配置グループ (PG) を確認し、修正します。詳細は、Red Hat ナレッジベースソリューション Ceph の一貫性のない配置グループの処理 を参照してください。
6.3.23. CephPoolQuotaBytesCriticallyExhausted
意味 |
1 つ以上のプールがクォータに達したか、ほぼ達しています。このエラー状態を引き起こすための閾値は、 |
影響 | High |
軽減策
プールクォータを調整します。次のコマンドを実行して、プールクォータを完全に削除するか、上下に調整します。
ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>
クォータ値を 0
に設定すると、クォータが無効になります。
6.3.24. CephPoolQuotaBytesNearExhaustion
意味 |
1 つまたは複数のプールが、設定された満杯のしきい値に近づいています。この警告状態を引き起こす可能性のあるしきい値としては、 |
影響 | High |
軽減策
プールクォータを調整します。次のコマンドを実行して、プールクォータを完全に削除するか、上下に調整します。
ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>
クォータ値を 0
に設定すると、クォータが無効になります。
6.3.25. PersistentVolumeUsageCritical
意味 | 永続ボリューム要求 (PVC) が最大容量に近づいており、タイムリーに対処しないとデータが失われる可能性があります。 |
影響 | High |
軽減策
PVC サイズを拡張して容量を増やします。
- OpenShift Web コンソールにログインします。
- Storage → PersistentVolumeClaim をクリックします。
-
Project ドロップダウンリストから
openshift-storage
を選択します。 - 拡張したい PVC で、Action menu (⋮) → Expand PVC をクリックします。
- Total size を目的のサイズに更新します。
- Expand をクリックします。
または、スペースを占有している可能性のある不要なデータを削除することもできます。
6.3.26. PersistentVolumeUsageNearFull
意味 | 永続ボリューム要求 (PVC) が最大容量に近づいており、タイムリーに対処しないとデータが失われる可能性があります。 |
影響 | High |
軽減策
PVC サイズを拡張して容量を増やします。
- OpenShift Web コンソールにログインします。
- Storage → PersistentVolumeClaim をクリックします。
-
Project ドロップダウンリストから
openshift-storage
を選択します。 - 拡張したい PVC で、Action menu (⋮) → Expand PVC をクリックします。
- Total size を目的のサイズに更新します。
- Expand をクリックします。
または、スペースを占有している可能性のある不要なデータを削除することもできます。
6.4. 健全でないバケットのエラーコードを見つける
手順
- OpenShift Web コンソールで、Storage → Object Storage をクリックします。
- Object Bucket Claims タブをクリックします。
-
Bound
状態ではない Object Bucket Claim (OBC) を探してクリックします。 Events タブをクリックし、次のいずれかを実行します。
- バケットの現在の状態についてのヒントとなる可能性のあるイベントを探します。
- YAML タブをクリックし、YAML のステータスとモードのセクション周辺の関連エラーを探します。
OBC が
Pending
状態の場合、製品ログにエラーが表示される場合があります。ただし、この場合は、提供されたすべての変数が正確であるかを確認することを推奨します。
6.5. 異常な namesace ストアリソースのエラーコードを見つける
手順
- OpenShift Web コンソールで、Storage → Object Storage をクリックします。
- Namespace Store タブをクリックします。
-
Bound
状態ではない namespace ストアリソースを探し、これをクリックします。 Events タブをクリックし、次のいずれかを実行します。
- リソースの現在の状態についてのヒントとなる可能性のあるイベントを探します。
- YAML タブをクリックし、YAML のステータスとモードのセクション周辺の関連エラーを探します。
6.6. 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
6.7. EBS ボリュームの割り当て解除からのリカバリー
OSD ディスクがある OSD または MON Elastic Block Storage (EBS) ボリュームがワーカー Amazon EC2 インスタンスからアタッチ解除すると、ボリュームは 1 分または 2 分以内に自動的に再度アタッチされます。ただし、OSD Pod は CrashLoopBackOff
状態になります。Pod を回復して Running
状態に戻すには、EC2 インスタンスを再起動する必要があります。
6.8. rook-ceph-operator のデバッグログの有効化および無効化
rook-ceph-operator のデバッグログを有効にし、問題のトラブルシューティングに役立つ障害情報を取得します。
手順
- デバッグログの有効化
rook-ceph-operator の configmap を編集します。
$ oc edit configmap rook-ceph-operator-config
ROOK_LOG_LEVEL: DEBUG
パラメーターをrook-ceph-operator-config
yaml ファイルに追加して、rook-ceph-operator のデバッグログを有効にします。… data: # The logging level for the operator: INFO | DEBUG ROOK_LOG_LEVEL: DEBUG
rook-ceph-operator ログがデバッグ情報で構成されるようになります。
- デバッグログの無効化
rook-ceph-operator の configmap を編集します。
$ oc edit configmap rook-ceph-operator-config
ROOK_LOG_LEVEL: INFO
パラメーターをrook-ceph-operator-config
yaml ファイルに追加して、rook-ceph-operator のデバッグログを無効にします。… data: # The logging level for the operator: INFO | DEBUG ROOK_LOG_LEVEL: INFO
第7章 ローカルストレージ Operator デプロイメントの確認
ローカルストレージ Operator を使用する Red Hat OpenShift Data Foundation クラスターは、ローカルストレージデバイスを使用してデプロイされます。ローカルストレージデバイスを使用して既存のクラスターが OpenShift Data Foundation でデプロイされているかどうかを確認するには、以下の手順に従います。
前提条件
-
OpenShift Data Foundation が
openshift-storage
namespace にインストールされ、実行されている。
手順
OpenShift Data Foundation クラスターの Persistent Volume Claim(永続ボリューム要求、PVC) に関連付けられたストレージクラスをチェックすることにより、ローカルストレージデバイスを使用してクラスターがデプロイされているかどうかを確認できます。
以下のコマンドを使用して、OpenShift Data Foundation クラスターの 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
関連情報
- Deploying OpenShift Data Foundation using local storage devices on VMware
- Deploying OpenShift Data Foundation using local storage devices on Red Hat Virtualization
- Deploying OpenShift Data Foundation using local storage devices on bare metal
- Deploying OpenShift Data Foundation using local storage devices on IBM Power
第8章 障害が発生した、または不要な Ceph Object Storage デバイスの削除
障害が発生した、または不要な Ceph OSD (オブジェクトストレージデバイス) は、ストレージインフラストラクチャーのパフォーマンスに影響を与えます。したがって、ストレージクラスターの信頼性と回復力を向上させるには、障害が発生した、または不要な Ceph OSD を削除する必要があります。
障害が発生した、または不要な Ceph OSD を削除する場合は、次の手順を実行します。
Ceph の健全性ステータスを確認します。
詳細は、 Ceph クラスターが正常であることの確認 を参照してください。
OSD のプロビジョニングに基づいて、障害が発生した、または不要な Ceph OSD を削除します。
参照:
ローカルディスクを使用している場合は、古い OSD を削除した後、これらのディスクを再利用できます。
8.1. Ceph クラスターが正常であることの確認
ストレージの健全性は、Block、File、Object のダッシュボードに表示されます。
手順
- OpenShift Web コンソールで、Storage → Data Foundation をクリックします。
- Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
- Block and File タブの Status カードで、Storage Cluster に緑色のチェックマークが表示されていることを確認します。
- Details カードで、クラスター情報が表示されていることを確認します。
8.2. 動的にプロビジョニングされた Red Hat OpenShift Data Foundation で失敗した、または不要な Ceph OSD を削除。
動的にプロビジョニングされた Red Hat OpenShift Data Foundation で失敗した、または不要な Ceph OSD を削除するには、手順のステップに従ってください。
クラスターのスケールダウンは、Red Hat サポートチームの支援がある場合にのみサポートされます。
- Ceph コンポーネントが正常な状態ではないときに OSD を削除すると、データが失われる可能性があります。
- 2 つ以上の OSD を同時に削除すると、データが失われます。
前提条件
- Ceph が正常かどうかを確認します。詳細は、 Ceph クラスターが正常であることの確認 を参照してください。
- アラートが発生していないか、再構築プロセスが進行中ではないことを確認してください。
手順
OSD デプロイメントをスケールダウンします。
# oc scale deployment rook-ceph-osd-<osd-id> --replicas=0
Ceph OSD を削除するための
osd-prepare
Pod を取得します。# oc get deployment rook-ceph-osd-<osd-id> -oyaml | grep ceph.rook.io/pvc
osd-prepare
Pod を削除します。# oc delete -n openshift-storage pod rook-ceph-osd-prepare-<pvc-from-above-command>-<pod-suffix>
失敗した OSD をクラスターから削除します。
# failed_osd_id=<osd-id> # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=$<failed_osd_id> | oc create -f -
ここで、
FAILED_OSD_ID
はrook-ceph-osd
接頭辞の直後の Pod 名の整数です。ログを確認して、OSD が正常に削除されたことを確認します。
# oc logs -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
-
オプション: OpenShift Container Platform の ocs-osd-removal-job Pod から
cephosd:osd.0 is NOT ok to destroy
としてエラーが発生した場合は、エラーcephosd:osd.0 is NOT ok to destroy
のトラブルシューティング を参照してください。 OSD デプロイメントを削除します。
# oc delete deployment rook-ceph-osd-<osd-id>
検証手順
OSD が正常に削除されたかどうかを確認するには、次のコマンドを実行します。
# oc get pod -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
このコマンドはステータスを Completed として返す必要があります。
8.3. ローカルストレージデバイスを使用してプロビジョニングされた、失敗したまたは不要な Ceph OSD を削除
次の手順に従って、ローカルストレージデバイスを使用してプロビジョニングされた失敗した Ceph または不要な Ceph を削除できます。
クラスターのスケールダウンは、Red Hat サポートチームの支援がある場合にのみサポートされます。
- Ceph コンポーネントが正常な状態ではないときに OSD を削除すると、データが失われる可能性があります。
- 2 つ以上の OSD を同時に削除すると、データが失われます。
前提条件
- Ceph が正常かどうかを確認します。詳細は、 Ceph クラスターが正常であることの確認 を参照してください。
- アラートが発生していないか、再構築プロセスが進行中ではないことを確認してください。
手順
OSD デプロイメント上のレプリカを 0 にスケールして、OSD を強制的にマークダウンします。障害により OSD がすでにダウンしている場合は、この手順をスキップできます。
# oc scale deployment rook-ceph-osd-<osd-id> --replicas=0
失敗した OSD をクラスターから削除します。
# failed_osd_id=<osd_id> # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=$<failed_osd_id> | oc create -f -
ここで、
FAILED_OSD_ID
はrook-ceph-osd
接頭辞の直後の Pod 名の整数です。ログを確認して、OSD が正常に削除されたことを確認します。
# oc logs -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
-
オプション: OpenShift Container Platform の ocs-osd-removal-job Pod から
cephosd:osd.0 is NOT ok to destroy
としてエラーが発生した場合は、エラーcephosd:osd.0 is NOT ok to destroy
のトラブルシューティング を参照してください。 障害のある OSD に関連付けられた Persistent Volume Claim (永続ボリューム要求、PVC) リソースを削除します。
失敗した OSD に関連付けられた
PVC
を取得します。# oc get -n openshift-storage -o yaml deployment rook-ceph-osd-<osd-id> | grep ceph.rook.io/pvc
PVC に関連付けられた
persistent volume
(PV) を取得します。# oc get -n openshift-storage pvc <pvc-name>
障害が発生したデバイス名を取得します。
# oc get pv <pv-name-from-above-command> -oyaml | grep path
失敗した OSD に関連付けられた
prepare-pod
を取得します。# oc describe -n openshift-storage pvc ocs-deviceset-0-0-nvs68 | grep Mounted
関連付けられた PVC を削除する前に
osd-prepare pod
を削除します。# oc delete -n openshift-storage pod <osd-prepare-pod-from-above-command>
失敗した OSD に関連付けられた
PVC
を削除します。# oc delete -n openshift-storage pvc <pvc-name-from-step-a>
障害が発生したデバイスエントリーを
LocalVolume custom resoure
(CR) から削除します。障害が発生したデバイスを使用してノードにログインします。
# oc debug node/<node_with_failed_osd>
障害が発生したデバイス名の /dev/disk/by-id/<id> を記録します。
# ls -alh /mnt/local-storage/localblock/
オプション: OSD のプロビジョニングにローカルストレージオペレーターが使用されている場合は、{osd-id} を使用してマシンにログインし、デバイスのシンボリックリンクを削除します。
# oc debug node/<node_with_failed_osd>
障害が発生したデバイス名の OSD シンボリックリンクを取得します。
# ls -alh /mnt/local-storage/localblock
symlink を削除します。
# rm /mnt/local-storage/localblock/<failed-device-name>
- OSD に関連付けられている PV を削除します。
# oc delete pv <pv-name>
検証手順
OSD が正常に削除されたかどうかを確認するには、次のコマンドを実行します。
#oc get pod -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
このコマンドはステータスを Completed として返す必要があります。
8.4. 失敗した、あるいは不要な Ceph OSD の削除中のエラー cephosd:osd.0 is NOT ok to destroy
のトラブルシューティング
このエラーが、OpenShift Container Platform の ocs-osd-removal-job から cephosd:osd.0 is NOT ok to destroy
として発生した場合は、FORCE_OSD_REMOVAL オプションを指定して OSD 削除を実行し、OSD を破棄状態に移行します。
# oc process -n openshift-storage ocs-osd-removal -p FORCE_OSD_REMOVAL=true -p FAILED_OSD_IDS=$<failed_osd_id> | oc create -f -
FORCE_OSD_REMOVAL オプションは、すべての PG がアクティブな状態にある場合にのみ使用する必要があります。そうでない場合、PG はバックフィルを完了するか、PG がアクティブであることを確認するためにさらに調査する必要があります。
第9章 トラブルシューティングおよびアンインストール時の残りのリソースの削除
Operator によって管理されるカスタムリソースの一部は、必要なすべてのクリーンアップタスクを実行しても、ファイナライザーで "Terminating" ステータスのままになり、完了まで待機する必要がある場合があります。このような場合には、このようなリソースを強制的に削除する必要があります。これを実行しないと、すべてのアンインストール手順を実行しても、リソースは Terminating 状態のままになります。
openshift-storage namespace が削除時に 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
問題が解決しない場合は、Red Hat サポート にご連絡ください。
第10章 外部モードでの CephFS PVC 作成のトラブルシューティング
Red Hat Ceph Storage クラスターを 4.1.1 以前のバージョンから最新リリースに更新し、これが新規にデプロイされたクラスターではない場合は、Red Hat Ceph Storage クラスターで 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-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 -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 [...]
第11章 OpenShift Data Foundation でのモニター Pod の復元
3 つすべてが停止している場合はモニター Pod を復元し、OpenShift Data Foundation がモニター 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
namespace ですべてのデプロイメントのバックアップを作成します。# 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
livenessProbe
パラメーターを削除するように OSD デプロイメントにパッチを適用し、コマンドパラメーター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
クラスターマップを取得します。recover_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
recover_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 Pod に移動し、取得した
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"
キーリングファイルのサンプル
/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 シークレットからキーをフェッチした後、デフォルトのcaps
を追加します。 - OSD キーリングは、復元後に自動的に追加されます。
-
mon-a Pod に移動し、
monstore
にmonmap
があることを確認します。mon-a Pod に移動します。
# 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
をインポートします。重要以前に作成した キーリング ファイルを使用します。
# 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 Pod にコピーします。# 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 Pod に移動し、コピーした
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、Milla、および OSD Pod が稼働していることを確認します。
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
マルチクラウドオブジェクトゲートウェイ (MCG) のステータスを確認します。アクティブで、backingstore と bucketclass が
Ready
状態になっている必要があります。noobaa status -n openshift-storage
重要MCG がアクティブ状態でなく、backingstore と bucketclass が
Ready
状態でない場合は、すべての MCG 関連 Pod を再起動する必要があります。詳細は、「Multicloud Object Gateway の復元」 を参照してください。
11.1. Multicloud Object Gateway の復元
Multicloud Object Gateway (MCG) がアクティブ状態でなく、backingstore および 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 Object Gateway (RGW) が設定されている場合は、Pod を再起動します。
# oc delete pods <rgw-pod> -n openshift-storage
<rgw-pod>
- RGW Pod の名前です。
OpenShift Container Platform 4.11 では、リカバリー後、RBD PVC がアプリケーション Pod にマウントされません。したがって、アプリケーション Pod をホストしているノードを再起動する必要があります。アプリケーション Pod をホストしているノード名を取得するには、次のコマンドを実行します。
# oc get pods <application-pod> -n <namespace> -o yaml | grep nodeName nodeName: node_name
第12章 OpenShift Data Foundation での ceph-monitor クォーラムの復元
状況によっては、ceph-mons
がクォーラムを失う可能性があります。mons
が再びクォーラムを形成できない場合は、クォーラムを再度取得する手動の手順があります。唯一の要件は、1 つ以上の mon
が正常である必要があることです。以下の手順は、正常でない mon
をクォーラムから削除し、単一の mon
でクォーラムを再度作成してから、クォーラムを元のサイズに戻すことができます。
たとえば、3 つの mons
があり、クォーラムが失われる場合は、クォーラムから 2 つの悪い mons
を削除して、適切な mon
がクォーラムの唯一の mon
であることを通知してから、適切なmon
を再起動する必要があります。
手順
monmap
を変更する場合にmons
がフェイルオーバーしないように、rook-ceph-operator
を停止します。# oc -n openshift-storage scale deployment rook-ceph-operator --replicas=0
新しい
monmap
を注入します。警告monmap
は非常に慎重に注入する必要があります。誤って実行すると、クラスターは永続的に破棄される可能性があります。Cephmonmap
は、mon
クォーラムを追跡します。monmap
は、正常な mon のみが含まれるように更新されます。この例では、正常な mon はrook-ceph-mon-b
ですが、正常でないmon
はrook-ceph-mon-a
およびrook-ceph-mon-c
になります。現在の
rook-ceph-mon-b
デプロイメントのバックアップを作成します。# oc -n openshift-storage get deployment rook-ceph-mon-b -o yaml > rook-ceph-mon-b-deployment.yaml
YAML ファイルを開き、コマンド および 引数 を
mon
コンテナーからコピーします (以下の例の containers リストを参照)。これは、monmap
の変更に必要です。[...] containers: - args: - --fsid=41a537f2-f282-428e-989f-a9e07be32e47 - --keyring=/etc/ceph/keyring-store/keyring - --log-to-stderr=true - --err-to-stderr=true - --mon-cluster-log-to-stderr=true - '--log-stderr-prefix=debug ' - --default-log-to-file=false - --default-mon-cluster-log-to-file=false - --mon-host=$(ROOK_CEPH_MON_HOST) - --mon-initial-members=$(ROOK_CEPH_MON_INITIAL_MEMBERS) - --id=b - --setuser=ceph - --setgroup=ceph - --foreground - --public-addr=10.100.13.242 - --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db - --public-bind-addr=$(ROOK_POD_IP) command: - ceph-mon [...]
コピーした
command
およびargs
フィールドを、以下のように貼り付け可能なコマンドを形成するためにクリーンアップします。# ceph-mon \ --fsid=41a537f2-f282-428e-989f-a9e07be32e47 \ --keyring=/etc/ceph/keyring-store/keyring \ --log-to-stderr=true \ --err-to-stderr=true \ --mon-cluster-log-to-stderr=true \ --log-stderr-prefix=debug \ --default-log-to-file=false \ --default-mon-cluster-log-to-file=false \ --mon-host=$ROOK_CEPH_MON_HOST \ --mon-initial-members=$ROOK_CEPH_MON_INITIAL_MEMBERS \ --id=b \ --setuser=ceph \ --setgroup=ceph \ --foreground \ --public-addr=10.100.13.242 \ --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db \ --public-bind-addr=$ROOK_POD_IP
注記--log-stderr-prefix
フラグおよび括弧の周りの一重引用符を必ず削除し、ROOK_CEPH_MON_HOST
、ROOK_CEPH_MON_INITIAL_MEMBERS
、およびROOK_POD_IP
) に渡されます。rook-ceph-mon-b
デプロイメントにパッチを適用し、mon
Pod を削除せずにこのmon
の作業を停止します。# oc -n openshift-storage patch deployment rook-ceph-mon-b --type='json' -p '[{"op":"remove", "path":"/spec/template/spec/containers/0/livenessProbe"}]' # oc -n openshift-storage patch deployment rook-ceph-mon-b -p '{"spec": {"template": {"spec": {"containers": [{"name": "mon", "command": ["sleep", "infinity"], "args": []}]}}}}'
mon-b
Pod で以下の手順を実行します。正常な
mon
の Pod に接続し、以下のコマンドを実行します。# oc -n openshift-storage exec -it <mon-pod> bash
変数を設定します。
# monmap_path=/tmp/monmap
ceph
mon
を適切なmon
デプロイメントから貼り付け、--extract-monmap=${monmap_path}
フラグを追加して、monmap
をファイルにデプロイメントします。# ceph-mon \ --fsid=41a537f2-f282-428e-989f-a9e07be32e47 \ --keyring=/etc/ceph/keyring-store/keyring \ --log-to-stderr=true \ --err-to-stderr=true \ --mon-cluster-log-to-stderr=true \ --log-stderr-prefix=debug \ --default-log-to-file=false \ --default-mon-cluster-log-to-file=false \ --mon-host=$ROOK_CEPH_MON_HOST \ --mon-initial-members=$ROOK_CEPH_MON_INITIAL_MEMBERS \ --id=b \ --setuser=ceph \ --setgroup=ceph \ --foreground \ --public-addr=10.100.13.242 \ --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db \ --public-bind-addr=$ROOK_POD_IP \ --extract-monmap=${monmap_path}
monmap
の内容を確認します。# monmaptool --print /tmp/monmap
monmap
から不正なmons
を削除します。# monmaptool ${monmap_path} --rm <bad_mon>
この例では、
mon0
およびmon2
を削除します。# monmaptool ${monmap_path} --rm a # monmaptool ${monmap_path} --rm c
ceph
mon
コマンドを貼り付け、--inject-monmap=${monmap_path}
フラグを以下のように追加することで、変更したmonmap
を適切なmon
に挿入します。# ceph-mon \ --fsid=41a537f2-f282-428e-989f-a9e07be32e47 \ --keyring=/etc/ceph/keyring-store/keyring \ --log-to-stderr=true \ --err-to-stderr=true \ --mon-cluster-log-to-stderr=true \ --log-stderr-prefix=debug \ --default-log-to-file=false \ --default-mon-cluster-log-to-file=false \ --mon-host=$ROOK_CEPH_MON_HOST \ --mon-initial-members=$ROOK_CEPH_MON_INITIAL_MEMBERS \ --id=b \ --setuser=ceph \ --setgroup=ceph \ --foreground \ --public-addr=10.100.13.242 \ --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db \ --public-bind-addr=$ROOK_POD_IP \ --inject-monmap=${monmap_path}
- シェルを終了して続行します。
Rook
configmaps
を編集します。Operator が
mon
を追跡するのに使用するconfigmap
を編集します。# oc -n openshift-storage edit configmap rook-ceph-mon-endpoints
data 要素で、以下のような 3 つの
mon
(またはmoncount
に応じて) が表示されることを確認します。data: a=10.100.35.200:6789;b=10.100.13.242:6789;c=10.100.35.12:6789
リストから問題の
mon
を削除し、末尾に適切なmon
を 1 つ削除します。以下に例を示します。data: b=10.100.13.242:6789
- ファイルを保存して終了します。
ここで、
mons
およびその他のコンポーネントに使用されるSecret
を調整する必要があります。変数
good_mon_id
の値を設定します。以下に例を示します。
# good_mon_id=b
oc patch
コマンドを使用して、rook-ceph-config
シークレットにパッチを適用し、mon_host
およびmon_initial_members
の 2 つのキー/値のペアを更新できます。# mon_host=$(oc -n openshift-storage get svc rook-ceph-mon-b -o jsonpath='{.spec.clusterIP}') # oc -n openshift-storage patch secret rook-ceph-config -p '{"stringData": {"mon_host": "[v2:'"${mon_host}"':3300,v1:'"${mon_host}"':6789]", "mon_initial_members": "'"${good_mon_id}"'"}}'
注記hostNetwork: true
を使用している場合は、mon_host
変数をmon
がピニングされるノード IP (nodeSelector
) に置き換える必要があります。これは、対象の “mode” で作成されたrook-ceph-mon-*
サービスがないためです。
mon
を再起動します。変更を取得するには、元の
ceph-mon
コマンドで適切なmon
Pod を再起動する必要があります。mon
デプロイメント YAML ファイルのバックアップでoc replace
コマンドを使用します。# oc replace --force -f rook-ceph-mon-b-deployment.yaml
注記--force
オプションはデプロイメントを削除し、新たに作成します。クラスターのステータスを確認します。
ステータスは、クォーラムの
mon
が 1 つ表示されるはずです。ステータスが適切であれば、クラスターは再度正常であるはずです。
クォーラムにある 2 つの mon デプロイメントを削除します。
以下に例を示します。
# oc delete deploy <rook-ceph-mon-1> # oc delete deploy <rook-ceph-mon-2>
この例では、削除するデプロイメントは
rook-ceph-mon-a
およびrook-ceph-mon-c
です。Operator を再起動します。
rook Operator を再び起動し、クラスターの健全性の監視を再開します。
注記多数のリソースがすでに存在するエラーを無視するのは安全です。
# oc -n openshift-storage scale deployment rook-ceph-operator --replicas=1
Operator は
mons
をさらに追加し、mon
数に応じて再びクォーラムサイズを増やします。
第13章 Red Hat OpenShift Data Foundation コンソールプラグインの有効化
Data Foundation コンソールプラグインはデフォルトで有効になっています。OpenShift Data Foundation Operator のインストール時にこのオプションの選択を解除された場合は、以下の手順を使用して、グラフィカルユーザーインターフェイス (GUI) またはコマンドラインインターフェイスのいずれかからコンソールプラグインをデプロイ後に有効にします。
前提条件
- OpenShift Web コンソールへの管理者アクセスがある。
-
OpenShift Data Foundation Operator が
openshift-storage
namespace にインストールされ、実行されている。
手順
- ユーザーインターフェイスを使用する場合
- OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
-
選択された Project が
openshift-storage
であることを確認します。 - OpenShift Data Foundation Operator をクリックします。
console プラグインオプションを有効にします。
- Details タブで、Console plugin の下にある 鉛筆 アイコンをクリックします。
- Enable を選択し、Save をクリックします。
- コマンドラインインターフェイスの使用
以下のコマンドを実行して console プラグインオプションを有効にします。
$ oc patch console.operator cluster -n openshift-storage --type json -p '[{"op": "add", "path": "/spec/plugins", "value": ["odf-console"]}]'
検証手順
console プラグインオプションが有効になると、ポップアップメッセージが表示され、
Web console update is available
が GUI に表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。- Web コンソールで、Storage に移動し、Data Foundation が使用可能かどうかを確認します。
第14章 OpenShift Data Foundation コンポーネントのリソースの変更
OpenShift Data Foundation をインストールすると、OpenShift Data Foundation Pod が消費できる事前に定義されたリソースが提供されます。I/O 負荷が高い状況では、これらの制限を引き上げる必要がある場合があります。
- rook-ceph Pod の CPU およびメモリーリソースを変更するには、「rook-ceph Pod の CPU およびメモリーリソースの変更」 を参照してください。
- Multicloud Object Gateway(MCG) のリソースを調整するには、「MCG のリソースのチューニング」 を参照してください。
14.1. rook-ceph Pod の CPU およびメモリーリソースの変更
OpenShift Data Foundation のインストール時に、rook-ceph Pod の事前に定義された CPU およびメモリーリソースが提供されます。要件に応じてこれらの値を手動で増やすことができます。
以下の Pod で CPU およびメモリーリソースを変更できます。
-
mgr
-
mds
-
rgw
以下の例は、rook-ceph Pod の CPU およびメモリーリソースを変更する方法を示しています。この例では、既存の MDS Pod 値である cpu
および memory
がそれぞれ 1
および 4Gi
から 2
および 8Gi
に増えています。
ストレージクラスターを編集します。
# oc edit storagecluster -n openshift-storage <storagecluster_name>
<storagecluster_name>
ストレージクラスターの名前を指定します。
以下に例を示します。
# 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>
ストレージクラスターの名前を指定します。
以下に例を示します。
# oc patch -n openshift-storage storagecluster ocs-storagecluster \ --type merge \ --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "2","memory": "8Gi"},"requests": {"cpu": "2","memory": "8Gi"}}}}}'
14.2. MCG のリソースのチューニング
Multicloud Object Gateway (MCG) のデフォルト設定は、パフォーマンスではなくリソース消費量が少ないように最適化されています。MCG のリソースを調整する方法の詳細については、Red Hat ナレッジベースソリューション のマルチクラウドオブジェクトゲートウェイ (NooBaa) のパフォーマンス調整ガイドを 参照してください。
第15章 グローバル Pod ネットワークを手動で有効化することによる ovs-multitenant
プラグインでの odf-console
へのアクセス
OpenShift Container Platform では、ovs-multitenant
プラグインが Software-Defined Networking (SDN) に使用されている場合、異なるプロジェクトの Pod は、異なるプロジェクトの Pod およびサービスとの間でパケットを送受信できません。プロジェクトの Pod ネットワークはグローバルではないため、デフォルトでは、Pod は namespace またはプロジェクト間で通信できません。
odf-console にアクセスするには、openshift-console
namespace の OpenShift コンソール Pod が 、openshift-storage
namespace の OpenShift Data Foundation odf-console に接続する必要があります。これは、グローバル Pod ネットワークを手動で有効にした場合にのみ可能です。
問題
OpenShift Container Platform で ovs-multitenant プラグインが使用されている場合、odf-console プラグインが失敗し、次のメッセージが表示されます。
GET request for "odf-console" plugin failed: Get "https://odf-console-service.openshift-storage.svc.cluster.local:9001/locales/en/plugin__odf-console.json": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
解決方法
OpenShift Data Foundation プロジェクトの Pod ネットワーキングをグローバルにします。
$ oc adm pod-network make-projects-global openshift-storage