Red Hat OpenShift Container Storage のトラブルシューティング
OpenShift Container Storage のエラーおよび問題のトラブルシューティング方法
概要
第1章 概要
OpenShift Container Storage のトラブルシューティングは、管理者が Red Hat OpenShift Container Storage クラスターのトラブルシューティングおよび修正を行う方法を理解するのに役立ちます。
ほとんどのトラブルシューティングタスクは、修正または回避策のいずれかに重点を置いています。本書は、管理者が直面する可能性のあるエラーに基づいていくつかの章に分類されています。
- 2章must-gather を使用したログファイルおよび診断情報のダウンロード では、OpenShift Container Storage で must-gather ユーティリティーを使用する方法を示します。
- 3章トラブルシューティングに共通して必要になるログ では、OpenShift Container Storage に共通して必要になるログファイルを取得する方法について説明します。
- 5章OpenShift Container Storage のアラートおよびエラーのトラブルシューティング では、発生したエラーを特定し、必要なアクションを実行する方法を示します。
第2章 must-gather を使用したログファイルおよび診断情報のダウンロード
Red Hat OpenShift Container Storage が問題を自動的に解決できない場合、must-gather ツールを使用してログファイルと診断情報を収集し、お客様または Red Hat サポートが問題を確認し、解決策を判別できるようにします。
OpenShift Container Storage が外部モードでデプロイされる場合には、must-gather は Red Hat OpenShift Container Storage クラスターからのみログを収集し、外部 Red Hat Ceph Storage クラスターからデバッグデータおよびログを収集しません。外部の Red Hat Ceph Storage クラスターからデバッグログを収集するには、Red Hat Ceph Storage の トラブルシューティングガイド を参照するか、または Red Hat Ceph Storage の管理者にお問い合わせください。
手順
OpenShift Container Storage クラスターに接続されているクライアントから
must-gather
コマンドを実行します。$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6 --dest-dir=<directory-name>
これにより、指定されたディレクトリーに以下の情報が収集されます。
- すべての OpenShift Container Storage クラスター関連のカスタムリソース (CR) とそれらの namespace。
- すべての OpenShift Container Storage 関連の Pod の Pod ログ。
- ステータス、クラスターの正常性などの一部の標準的な Ceph コマンドの出力。
コマンドの差異
状態が Ready ではないマスターノードが 1 つ以上ある場合には、
must-gather
Pod を安全にスケジュールできるように--node-name
を使用して Ready のマスターノードを指定します。$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6 --dest-dir=<directory-name> --node-name=<node-name>
特定の時点から情報を収集する場合は、以下を行います。
たとえば 5 秒以内または 2 日以内に収集されたログの相対的な期間を指定するには、
/usr/bin/gather since=<duration>
を追加します。$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6 --dest-dir=<directory-name> /usr/bin/gather since=<duration>
その後にログを収集する特定の時間を指定するには、
/usr/bin/gather since-time=<rfc3339-timestamp>
を追加します。$ oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:v4.6 --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 Container Storage のトラブルシューティングに共通して使用されるログの一部と、それらを生成するコマンドが一覧表示されます。
特定 Pod のログを生成します。
$ oc logs <pod-name> -n <namespace>
Ceph または OpenShift Container Storage クラスターのログを生成します。
$ oc logs rook-ceph-operator-<ID> -n openshift-storage
cephfs または rbd などのプラグイン Pod のログを生成し、app-pod の PVC マウントで問題を検出します。
$ oc logs csi-cephfsplugin-<ID> -n openshift-storage -c csi-cephfsplugin
$ oc logs csi-rbdplugin-<ID> -n openshift-storage -c csi-rbdplugin
CSI Pod のすべてのコンテナーのログを生成するには、以下を実行します。
$ oc logs csi-cephfsplugin-<ID> -n openshift-storage --all-containers
$ oc logs csi-rbdplugin-<ID> -n openshift-storage --all-containers
PVC が BOUND 状態にない場合に問題を検出するために、cephfs または rbd プロビジョナー Pod のログを生成します。
$ oc logs csi-cephfsplugin-provisioner-<ID> -n openshift-storage -c csi-cephfsplugin
$ oc logs csi-rbdplugin-provisioner-<ID> -n openshift-storage -c csi-rbdplugin
CSI Pod のすべてのコンテナーのログを生成するには、以下を実行します。
$ oc logs csi-cephfsplugin-provisioner-<ID> -n openshift-storage --all-containers
$ oc logs csi-rbdplugin-provisioner-<ID> -n openshift-storage --all-containers
cluster-info コマンドを使用して OpenShift Container Storage ログを生成します。
$ oc cluster-info dump -n openshift-storage --output-directory=<directory-name>
OpenShift Container Storage の Operator ログおよびイベントを確認します。
Operator ログを確認するには、以下を実行します。
# oc logs <ocs-operator> -n openshift-storage
- <ocs-operator>
# oc get pods -n openshift-storage | grep -i "ocs-operator" | awk '{print $1}'
Operator イベントを確認するには、以下を実行します。
# oc get events --sort-by=metadata.creationTimestamp -n openshift-storage
OpenShift Container Storage の Operator のバージョンおよびチャネルを取得します。
# oc get csv -n openshift-storage
出力例:
NAME DISPLAY VERSION REPLACES PHASE ocs-operator.v4.6.2 OpenShift Container Storage 4.6.2 Succeeded
# oc get subs -n openshift-storage
出力例:
NAME PACKAGE SOURCE CHANNEL ocs-operator ocs-operator redhat-operators stable-4.6
installplan が作成されていることを確認します。
# oc get installplan -n openshift-storage
OpenShift Container Storage を更新後のコンポーネントのイメージを確認します。
イメージが実行中であるを確認するために使用するコンポーネントの Pod があるノードを確認します。
# oc get pods -o wide | grep <component-name>
以下に例を示します。
# oc get pods -o wide | grep rook-ceph-operator
出力例:
rook-ceph-operator-566cc677fd-bjqnb 1/1 Running 20 4h6m 10.128.2.5 rook-ceph-operator-566cc677fd-bjqnb 1/1 Running 20 4h6m 10.128.2.5 dell-r440-12.gsslab.pnq2.redhat.com <none> <none> <none> <none>
dell-r440-12.gsslab.pnq2.redhat.com
は node-name です。イメージ ID を確認します。
# oc debug node/<node-name>
<node-name>
イメージが実行中であることを確認するために使用するコンポーネントの Pod があるノードの名前です。
# chroot /host
# crictl images | grep <component>
以下に例を示します。
# crictl images | grep rook-ceph
出力例:
IMAGE TAG IMAGEID SIZE registry.redhat.io/ocs4/rook-ceph-rhel8-operator@sha256 <none> 5600a36370df4 1.55GB
IMAGEID
を書き留め、これを Rook Ceph Operator ページの Digest ID にマップします。
関連情報
第4章 OpenShift Container Storage デプロイメント後のクラスター全体のデフォルトノードセレクターの上書き
クラスター全体でのデフォルトノードセレクターが Openshift Container Storage に使用される場合、CSI daemonset によって生成される Pod はセレクターに一致するノードでのみ起動できます。セレクターに一致しないノードから Openshift Container Storage を使用できるようにするには、コマンドラインインターフェイスで以下の手順を実行して cluster-wide default node selector
を上書きします。
手順
openshift-storage namespace の空のノードセレクターを指定します。
$ oc annotate namespace openshift-storage openshift.io/node-selector=
DaemonSets によって生成される元の Pod を削除します。
oc delete pod -l app=csi-cephfsplugin -n openshift-storage oc delete pod -l app=csi-rbdplugin -n openshift-storage
第5章 OpenShift Container Storage のアラートおよびエラーのトラブルシューティング
5.1. アラートとエラーの解決
Red Hat OpenShift Container Storage は、多くの共通する障害シナリオを検出し、これらを自動的に解決できます。ただし、一部の問題には管理者の介入が必要です。
現在発生しているエラーを確認するには、以下のいずれかの場所を確認します。
- Monitoring → Alerting → Firing オプション
- Home → Overview → Overview タブ
- Home → Overview → Persistent Storage タブ
- Home → Overview → Object Service タブ
表示されるエラーをコピーして、これを以下のセクションで検索し、その重大度と解決策を確認します。
Name:
Message:
Description: Severity: Warning Resolution: Fix Procedure: Inspect the user interface and log, and verify if an update is in progress.
|
Name:
Message:
Description: Severity: Warning Resolution: Fix Procedure: Inspect the user interface and log, and verify if an update is in progress.
|
Name:
Message:
Description: Severity: Crtical Resolution: Fix Procedure: Remove unnecessary data or expand the cluster. |
Name:
Fixed:
Description: Severity: Warning Resolution: Fix Procedure: Remove unnecessary data or expand the cluster. |
Name:
Message:
Description: Severity: Warning Resolution: Workaround Procedure: Resolving NooBaa Bucket Error State |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Workaround Procedure: Resolving NooBaa Bucket Error State |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message:
Description: Severity: Warning Resolution: Fix |
Name:
Message: Description: `Minimum required replicas for storage metadata service not available. Might affect the working of storage cluster.` Severity: Warning Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support Procedure:
|
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Warning Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support |
Name:
Message:
Description: Severity: Critical Resolution: Contact Red Hat support Procedure:
|
5.2. NooBaa Bucket エラー状態の解決
手順
- OpenShift Web コンソールにログインし、Object Service をクリックします。
- Details カードの System Name フィールドにあるリンクをクリックします。
- 左側のペインで、Buckets オプションをクリックし、エラー状態のバケットを検索します。
- その Bucket Name をクリックします。バケットで発生しているエラーが表示されます。
バケットの特定のエラーに応じて、以下のいずれかまたは両方を実行します。
領域に関連するエラーの場合:
- 左側のペインで Resources オプションをクリックします。
- エラー状態のリソースをクリックします。
- エージェントを追加してリソースをスケーリングします。
リソースの正常性エラーの場合:
- 左側のペインで Resources オプションをクリックします。
- エラー状態のリソースをクリックします。
- 接続エラーは、バッキングサービスが利用できないため、復元する必要があることを示します。
- アクセス/パーミッションのエラーについては、接続の Access Key および Secret Key を更新します。
5.3. クォータを超過した状態の NooBaa Bucket の解決
A NooBaa Bucket Is In Exceeding Quota State エラーを解決するには、以下のいずれかを実行します。
- バケットの一部のデータをクリーンアップします。
以下の手順に従って、バケットクォータを増やします。
- OpenShift Web コンソールにログインし、Object Service をクリックします。
- Details カードの System Name フィールドにあるリンクをクリックします。
- 左側のペインで、Buckets オプションをクリックし、エラー状態のバケットを検索します。
- その Bucket Name をクリックします。バケットで発生しているエラーが表示されます。
- Bucket Policies → Edit Quota をクリックし、クォータを増やします。
5.4. NooBaa バケット容量またはクォータの状態の解決
手順
- OpenShift Web コンソールにログインし、Object Service をクリックします。
- Details カードの System Name フィールドにあるリンクをクリックします。
- 左側のペインで Resources オプションをクリックし、PV プールリソースを検索します。
- 容量が低いステータスの PV プールリソースについては、そのResource Name をクリックします。
- プール設定を編集し、エージェントの数を増やします。
5.5. Pod のリカバリー
一部の問題により最初のノード (例: NODE1
) が NotReady 状態になると、ReadWriteOnce (RWO) アクセスモードで PVC を使用するホストされた Pod は、2 つ目のノード (例: NODE2
) に移行しようとしますが、multi-attach エラーにより停止します。このような場合には、以下の手順に従って MON、OSD、およびアプリケーション Pod を回復できます。
手順
-
(AWS または vSphere 側から)
NODE1
の電源をオフにし、NODE1
が完全に停止していることを確認します。 以下のコマンドを使用して
NODE1
で Pod を強制的に削除します。$ oc delete pod <pod-name> --grace-period=0 --force
5.6. EBS ボリュームの割り当て解除からのリカバリー
OSD ディスクがある OSD または MON Elastic Block Storage (EBS) ボリュームがワーカー Amazon EC2 インスタンスからアタッチ解除すると、ボリュームは 1 分または 2 分以内に自動的に再度アタッチされます。ただし、OSD Pod は CrashLoopBackOff
状態になります。Pod を回復して Running
状態に戻すには、EC2 インスタンスを再起動する必要があります。
第6章 ローカルストレージ Operator デプロイメントの確認
ローカルストレージ Operator を使用する OpenShift Container Storage クラスターはローカルストレージデバイスを使用してデプロイされます。ローカルストレージデバイスを使用して既存のクラスターが OpenShift Container Storage と共にデプロイされているかどうかを確認するには、以下の手順に従います。
前提条件
-
OpenShift Container Storage が
openshift-storage
namespace にインストールされ、実行されている。
手順
OpenShift Container Storage クラスターの Persistent Volume Claim(永続ボリューム要求、PVC) に関連付けられたストレージクラスをチェックすることにより、ローカルストレージデバイスを使用してクラスターがデプロイされているかどうかを確認できます。
以下のコマンドを使用して、OpenShift Container Storage クラスターの PVC に関連付けられたストレージクラスを確認します。
$ oc get pvc -n openshift-storage
出力を確認します。ローカルストレージ Operator を含むクラスターの場合、
ocs-deviceset
に関連付けられた PVC はストレージクラスlocalblock
を使用します。出力は以下の例のようになります。NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-noobaa-db-0 Bound pvc-d96c747b-2ab5-47e2-b07e-1079623748d8 50Gi RWO ocs-storagecluster-ceph-rbd 114s ocs-deviceset-0-0-lzfrd Bound local-pv-7e70c77c 1769Gi RWO localblock 2m10s ocs-deviceset-1-0-7rggl Bound local-pv-b19b3d48 1769Gi RWO localblock 2m10s ocs-deviceset-2-0-znhk8 Bound local-pv-e9f22cdc 1769Gi RWO localblock 2m10s
第7章 トラブルシューティングおよびアンインストール時の残りのリソースの削除
Operator によって管理されるカスタムリソースの一部は、必要なすべてのクリーンアップタスクを実行しても、ファイナライザーで Terminating ステータスのままになり、完了まで待機する必要がある場合があります。このような場合には、このようなリソースを強制的に削除する必要があります。これを実行しないと、すべてのアンインストール手順を実行しても、リソースは Terminating 状態のままになります。
openshift-storage namespace が削除時に Terminating 状態のままであるかどうかを確認します。
$ oc get project openshift-storage
出力:
NAME DISPLAY NAME STATUS openshift-storage Terminating
コマンド出力の
STATUS
セクションでNamespaceFinalizersRemaining
およびNamespaceContentRemaining
メッセージの有無を確認し、一覧表示される各リソースについて以下の手順を実行します。$ oc get project openshift-storage -o yaml
出力例:
status: conditions: - lastTransitionTime: "2020-07-26T12:32:56Z" message: All resources successfully discovered reason: ResourcesDiscovered status: "False" type: NamespaceDeletionDiscoveryFailure - lastTransitionTime: "2020-07-26T12:32:56Z" message: All legacy kube types successfully parsed reason: ParsedGroupVersions status: "False" type: NamespaceDeletionGroupVersionParsingFailure - lastTransitionTime: "2020-07-26T12:32:56Z" message: All content successfully deleted, may be waiting on finalization reason: ContentDeleted status: "False" type: NamespaceDeletionContentFailure - lastTransitionTime: "2020-07-26T12:32:56Z" message: 'Some resources are remaining: cephobjectstoreusers.ceph.rook.io has 1 resource instances' reason: SomeResourcesRemain status: "True" type: NamespaceContentRemaining - lastTransitionTime: "2020-07-26T12:32:56Z" message: 'Some content in the namespace has finalizers remaining: cephobjectstoreuser.ceph.rook.io in 1 resource instances' reason: SomeFinalizersRemain status: "True" type: NamespaceFinalizersRemaining
先の手順に記載されている残りのすべてのリソースを削除します。
削除する各リソースについて、以下を実行します。
削除する必要のあるリソースの種類を取得します。上記の出力のメッセージを確認します。
例:
message: Some content in the namespace has finalizers remaining: cephobjectstoreuser.ceph.rook.io
ここで、cephobjectstoreuser.ceph.rook.io はオブジェクトの種類です。
オブジェクトの種類に対応するオブジェクト名を取得します。
$ oc get <Object-kind> -n <project-name>
例:
$ oc get cephobjectstoreusers.ceph.rook.io -n openshift-storage
出力例:
NAME AGE noobaa-ceph-objectstore-user 26h
リソースにパッチを適用します。
$ oc patch -n <project-name> <object-kind>/<object-name> --type=merge -p '{"metadata": {"finalizers":null}}'
以下に例を示します。
$ oc patch -n openshift-storage cephobjectstoreusers.ceph.rook.io/noobaa-ceph-objectstore-user \ --type=merge -p '{"metadata": {"finalizers":null}}'
出力:
cephobjectstoreuser.ceph.rook.io/noobaa-ceph-objectstore-user patched
openshift-storage プロジェクトが削除されていることを確認します。
$ oc get project openshift-storage
出力:
Error from server (NotFound): namespaces "openshift-storage" not found
問題が解決しない場合は、Red Hat サポート にご連絡ください。
第8章 外部モードでの CephFS PVC 作成のトラブルシューティング
Red Hat Ceph Storage クラスターを 4.1.1 以前のバージョンから最新リリースに更新し、これが新規にデプロイされたクラスターではない場合は、Red Hat Ceph Storage クラスターで CephFS プールのアプリケーションタイプを手動で設定し、外部モードで CephFS PVC の作成を有効にする必要があります。
CephFS pvc が
Pending
ステータスで停止しているかどうかを確認します。$ oc get pvc
出力例:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ngx-fs-pxknkcix20-pod Pending ocs-external-storagecluster-cephfs 28h [...]
describe
出力を確認し、それぞれの pvc のイベントを表示します。予想されるエラーメッセージは
cephfs_metadata/csi.volumes.default/csi.volume.pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx: (1) Operation not permitted)
です。# oc describe pvc ngx-fs-pxknkcix20-pod -n nginx-file
出力例:
Name: ngx-fs-pxknkcix20-pod Namespace: nginx-file StorageClass: ocs-external-storagecluster-cephfs Status: Pending Volume: Labels: <none> Annotations: volume.beta.kubernetes.io/storage-provisioner: openshift-storage.cephfs.csi.ceph.com Finalizers: [kubernetes.io/pvc-protection] Capacity: Access Modes: VolumeMode: Filesystem Mounted By: ngx-fs-oyoe047v2bn2ka42jfgg-pod-hqhzf Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 107m (x245 over 22h) openshift-storage.cephfs.csi.ceph.com_csi-cephfsplugin-provisioner-5f8b66cc96-hvcqp_6b7044af-c904-4795-9ce5-bf0cf63cc4a4 (combined from similar events): failed to provision volume with StorageClass "ocs-external-storagecluster-cephfs": rpc error: code = Internal desc = error (an error (exit status 1) occurred while running rados args: [-m 192.168.13.212:6789,192.168.13.211:6789,192.168.13.213:6789 --id csi-cephfs-provisioner --keyfile=stripped -c /etc/ceph/ceph.conf -p cephfs_metadata getomapval csi.volumes.default csi.volume.pvc-1ac0c6e6-9428-445d-bbd6-1284d54ddb47 /tmp/omap-get-186436239 --namespace=csi]) occurred, command output streams is ( error getting omap value cephfs_metadata/csi.volumes.default/csi.volume.pvc-1ac0c6e6-9428-445d-bbd6-1284d54ddb47: (1) Operation not permitted)
<cephfs metadata pool name>
(ここではcephfs_metadata
) および<cephfs data pool name>
(ここではcephfs_data
) の設定を確認します。コマンドを実行するには、jq
を Red Hat Ceph Storage クライアントノードに事前にインストールする必要があります。# ceph osd pool ls detail --format=json | jq '.[] | select(.pool_name| startswith("cephfs")) | .pool_name, .application_metadata' "cephfs_data" { "cephfs": {} } "cephfs_metadata" { "cephfs": {} }
CephFS プールのアプリケーションタイプを設定します。
Red Hat Ceph Storage クライアントノードで以下のコマンドを実行します。
# ceph osd pool application set <cephfs metadata pool name> cephfs metadata cephfs
# ceph osd pool application set <cephfs data pool name> cephfs data cephfs
設定が適用されているかどうかを確認します。
# ceph osd pool ls detail --format=json | jq '.[] | select(.pool_name| startswith("cephfs")) | .pool_name, .application_metadata' "cephfs_data" { "cephfs": { "data": "cephfs" } } "cephfs_metadata" { "cephfs": { "metadata": "cephfs" } }
CephFS PVC のステータスを再度確認します。PVC が
Bound
状態になるはずです。# oc get pvc
出力例:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ngx-fs-pxknkcix20-pod Bound pvc-1ac0c6e6-9428-445d-bbd6-1284d54ddb47 1Mi RWO ocs-external-storagecluster-cephfs 29h [...]
第9章 OpenShift Container Storage でのモニター Pod の復元
3 つすべてが停止している場合はモニター Pod を復元し、OpenShift Container Storage がモニター 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 " [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.admin] key = AQDxTF1hpzguOxAA0sS8nN4udoO35OEbt3bqMQ== caps mds = "allow *" caps mgr = "allow *" caps mon = "allow *" 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" [mgr.a] key = AQBOTV1hGYOEORAA87471+eIZLZtptfkcHvTRg== caps mds = "allow *" caps mon = "allow profile mgr" caps osd = "allow *"
重要-
client.csi
関連のキーリングの場合は、それぞれの OpenShift Container Storage シークレットからキーの取得後に、デフォルトのcaps
を追加します。 - OSD キーリングは、復元後に自動的に追加されます。
-
mon-a Pod に移動します。
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 rook-ceph-operator --replicas=1
# oc -n openshift-storage scale deployment ocs-operator --replicas=1
CephFS の復元
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 サービスがない場合は、以下の手順を実行します。
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 rook-ceph-operator --replicas=1 -n openshift-storage
# 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 の名前です。
Multicloud Object Gateway の復元
MON Pod の復元後、Multicloud Object Gateway (MCG) のステータスを確認し、これはアクティブで、バッキングストアおよび bucketclass は Ready
状態である必要があります。これがない場合は、MCG 関連の Pod をすべて再起動して、MCG のステータスをチェックして、MCG がバックアップされていることを確認します。
MCG ステータスを確認します。
noobaa status -n openshift-storage
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 の名前です。