OpenShift Data Foundation のトラブルシューティング
OpenShift Data Foundation のトラブルシューティングの手順
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバックの提供
弊社のドキュメントについてのご意見をお聞かせください。ドキュメントの改善点があれば、ぜひお知らせください。フィードバックをお寄せいただくには、以下をご確認ください。
特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。
- ドキュメントの表示が Multi-page HTML 形式になっていていることを確認してください。ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
- マウスカーソルを使用して、コメントを追加するテキストの部分を強調表示します。
- 強調表示されたテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される指示に従ってください。
より詳細なフィードバックをお寄せいただく場合は、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 のアラートおよびエラーのトラブルシューティング では、発生したエラーを特定し、必要なアクションを実行する方法を示します。
第2章 must-gather を使用したログファイルおよび診断情報のダウンロード
Red Hat OpenShift Data Foundation が問題を自動的に解決できない場合、must-gather ツールを使用してログファイルと診断情報を収集し、お客様または Red Hat サポートが問題を確認し、解決策を判別できるようにします。
Red Hat OpenShift Data Foundation が外部モードでデプロイされる場合、must-gather は Red Hat 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.9 <local-registry>/odf4/ocs-must-gather-rhel8:v4.9 [--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 ナレッジベースソリューションを参照してください。
手順
Red Hat OpenShift Data Foundation クラスターに接続されているクライアントから
must-gather
コマンドを実行します。$ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.9 --dest-dir=<directory-name>
<directory-name>
データを書き込むディレクトリーの名前です。
重要非接続環境のデプロイメントの場合は、
--image
パラメーターのイメージをミラーリングされた must-gather イメージに置き換えます。$ oc adm must-gather --image=<local-registry>/odf4/ocs-must-gather-rhel8:v4.9 --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.9 --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.9 --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.9 --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.9.2 NooBaa Operator 4.9.2 mcg-operator.v4.9.1 Succeeded ocs-operator.v4.9.2 OpenShift Container Storage 4.9.2 ocs-operator.v4.9.1 Succeeded odf-operator.v4.9.2 OpenShift Data Foundation 4.9.2 odf-operator.v4.9.1 Succeeded
# oc get subs -n openshift-storage
出力例:
NAME PACKAGE SOURCE CHANNEL mcg-operator-stable-4.9-redhat-operators-openshift-marketplace mcg-operator redhat-operators stable-4.9 ocs-operator-stable-4.9-redhat-operators-openshift-marketplace ocs-operator redhat-operators stable-4.9 odf-operator odf-operator redhat-operators stable-4.9
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 にマップします。
関連情報
第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 → Openshift Data Foundation → Storage System → storage system link in the pop up → Overview → Block and File タブ
- Storage → Openshift Data Foundation → Storage System → storage system link in the pop up → Overview → Object タブ
表示されるエラーをコピーして、これを以下のセクションで検索し、その重大度と解決策を確認します。
Name:
Message:
Description: Severity: Warning Resolution: Fix Procedure: Inspect the user interface and log, and verify if an update is in progress.
|
Name:
Message:
Description: Severity: Warning Resolution: Fix Procedure: Inspect the user interface and log, and verify if an update is in progress.
|
Name:
Message:
Description: Severity: Crtical Resolution: Fix Procedure: Remove unnecessary data or expand the cluster. |
Name:
Fixed:
Description: Severity: Warning Resolution: Fix Procedure: Remove unnecessary data or expand the cluster. |
Name:
Message:
Description: Severity: Warning Resolution: Workaround Procedure: Resolving NooBaa Bucket Error State |
Name:
Message:
Description: Severity: Warning Resolution: Fix Procedure: Resolving NooBaa Bucket Error State |
Name:
Message:
Description: Severity: Warning Resolution: Fix Procedure: Resolving NooBaa Bucket Error State |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Workaround Procedure: Resolving NooBaa Bucket Error State |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message: Description: `Minimum required replicas for storage metadata service not available. Might affect the working of storage cluster.` Severity: Warning Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
Name:
Message: 説明: 1 つまたはいくつかのアプリケーションで障害復旧が失敗しています。 Severity: Warning Resolution: Contact Red Hat support |
Name:
Message: 説明: クラスター全体で障害復旧に失敗します。mirror デーモンが 1 分以上異常状態になっています。このクラスターのミラーリングは予想通りに機能しません。 Severity: Critical Resolution: Contact Red Hat support |
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. NooBaa Bucket エラー状態の解決
手順
- OpenShift Web コンソールで、Storage → OpenShift Data Foundation をクリックします。
- Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
- Object タブをクリックします。
- Details カードの System Name フィールドにあるリンクをクリックします。
- 左側のペインで、Buckets オプションをクリックし、エラー状態のバケットを検索します。エラー状態のバケットが namespace バケットである場合は、必ず Namespace Buckets ペインをクリックします。
- その Bucket Name をクリックします。バケットで発生しているエラーが表示されます。
バケットの特定のエラーに応じて、以下のいずれかまたは両方を実行します。
領域に関連するエラーの場合:
- 左側のペインで Resources オプションをクリックします。
- エラー状態のリソースをクリックします。
- エージェントを追加してリソースをスケーリングします。
リソースの正常性エラーの場合:
- 左側のペインで Resources オプションをクリックします。
- エラー状態のリソースをクリックします。
- 接続エラーは、バッキングサービスが利用できないため、復元する必要があることを示します。
- アクセス/パーミッションのエラーについては、接続の Access Key および Secret Key を更新します。
6.4. クォータを超過した状態の NooBaa Bucket の解決
A NooBaa Bucket Is In Exceeding Quota State エラーを解決するには、以下のいずれかを実行します。
- バケットの一部のデータをクリーンアップします。
以下の手順に従って、バケットクォータを増やします。
- OpenShift Web コンソールで、Storage → OpenShift Data Foundation をクリックします。
- Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
- Object タブをクリックします。
- Details カードの System Name フィールドにあるリンクをクリックします。
- 左側のペインで、Buckets オプションをクリックし、エラー状態のバケットを検索します。
- Bucket Name をクリックします。バケットで発生しているエラーが表示されます。
- Bucket Policies → Edit Quota をクリックし、クォータを増やします。
6.5. NooBaa バケット容量またはクォータの状態の解決
手順
- OpenShift Web コンソールで、Storage → OpenShift Data Foundation をクリックします。
- Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
- Object タブをクリックします。
- Details カードの System Name フィールドにあるリンクをクリックします。
- 左側のペインで Resources オプションをクリックし、PV プールリソースを検索します。
- 容量が低いステータスの PV プールリソースについては、そのResource Name をクリックします。
- プール設定を編集し、エージェントの数を増やします。
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章 トラブルシューティングおよびアンインストール時の残りのリソースの削除
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 サポート にご連絡ください。
第9章 外部モードでの 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 [...]
第10章 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
重要ファイルシステムがオフラインであるか、MDS サービスが見つからない場合は、CephFS を復元する必要があります。詳細は、「CephFS の復元」 を参照してください。
マルチクラウドオブジェクトゲートウェイ (MCG) のステータスを確認します。アクティブで、backingstore と bucketclass が
Ready
状態になっている必要があります。noobaa status -n openshift-storage
重要MCG がアクティブ状態でなく、backingstore と bucketclass が
Ready
状態でない場合は、すべての MCG 関連 Pod を再起動する必要があります。詳細は、「Multicloud Object Gateway の復元」 を参照してください。
10.1. CephFS の復元
ファイルシステムがオフラインであるか、MDS サービスが見つからない場合は、CephFS を復元する必要があります。
手順
rook-ceph-operator
およびocs Operator
デプロイメントをスケールダウンします。# oc scale deployment rook-ceph-operator --replicas=0 -n openshift-storage
# oc scale deployment ocs-operator --replicas=0 -n openshift-storage
MDS デプロイメントにパッチを適用して、
livenessProbe
パラメーターを削除し、コマンドパラメーターsleep
を使用して実行します。# for i in $(oc get deployment -l app=rook-ceph-mds -oname);do oc patch ${i} -n openshift-storage --type='json' -p '[{"op":"remove", "path":"/spec/template/spec/containers/0/livenessProbe"}]' ; oc patch ${i} -n openshift-storage -p '{"spec": {"template": {"spec": {"containers": [{"name": "mds", "command": ["sleep", "infinity"], "args": []}]}}}}' ; done
CephFS を復元します。
# ceph fs reset ocs-storagecluster-cephfilesystem --yes-i-really-mean-it
reset
コマンドが失敗した場合は、データおよびメタデータプールを使用してデフォルトのファイルシステムを強制的に作成し、リセットします。注記cephfilesystem
がない場合は、reset
コマンドが失敗する場合があります。# ceph fs new ocs-storagecluster-cephfilesystem ocs-storagecluster-cephfilesystem-metadata ocs-storagecluster-cephfilesystem-data0 --force
# ceph fs reset ocs-storagecluster-cephfilesystem --yes-i-really-mean-it
MDS デプロイメントを置き換えます。
# oc replace --force -f oc_get_deployment.rook-ceph-mds-ocs-storagecluster-cephfilesystem-a.yaml
# oc replace --force -f oc_get_deployment.rook-ceph-mds-ocs-storagecluster-cephfilesystem-b.yaml
rook-ceph-operator
およびocs-operator
デプロイメントをスケールアップします。# oc scale deployment ocs-operator --replicas=1 -n openshift-storage
CephFS のステータスを確認します。
# ceph fs status
ステータスは active である必要があります。
CephFS Persistent Volume Claim(永続ボリューム要求、PVC) を使用していたデプロイメントに割り当てられたアプリケーション Pod が、CephFS の復元後に
CreateContainerError
状態のままになる場合は、アプリケーション Pod を再起動します。# oc -n <namespace> delete pods <cephfs-app-pod>
<namespace>
- プロジェクトの namespace です。
<cephfs-app-pod>
- CephFS アプリケーション Pod の名前です。
- 新規 CephFS または RBD PVC がバインドされない場合は、Ceph CSI に関連するすべての Pod を再起動します。
10.2. 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 の名前です。
第11章 Red Hat OpenShift Data Foundation コンソールプラグインの有効化
OpenShift Data Foundation Operator のインストール後に自動的に有効にされていない場合は、console プラグインオプションを有効にします。console プラグインは、Web コンソールに含まれるカスタムインターフェイスを提供します。console プラグインオプションは、グラフィカルユーザーインターフェイス (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 に表示されます。このポップアップから Web コンソールのリフレッシュ をクリックして、反映するコンソールを変更します。- Web コンソールで Storage に移動し、OpenShift Data Foundation が利用可能かどうかを確認します。