2.3. レプリカを 1 つ含まれるストレージクラス
アプリケーションで使用するレプリカが 1 つ含まれるストレージクラスを作成できます。これにより、冗長なデータコピーが回避され、アプリケーションレベルでの復元管理が可能になります。
この機能を有効にすると、データレプリケーションのない単一のレプリカプールが作成され、アプリケーションに独自のレプリケーションがない場合は、データ損失、データ破損、および潜在的なシステム不安定のリスクが増加します。OSD が失われると、この機能を回復するのに非常に面倒な手順が必要になります。すべてのアプリケーションはデータを失う可能性があるため、OSD に障害が発生した場合は再作成する必要があります。
手順
次のコマンドを使用して単一レプリカ機能を有効にします。
$ oc patch storagecluster ocs-storagecluster -n openshift-storage --type json --patch '[\{ "op": "replace", "path": "/spec/managedResources/cephNonResilientPools/enable", "value": true }]'
2.3.1. 単一レプリカから OSD が失われた後の回復
レプリカ 1 (単一レプリカを持つストレージクラス) を使用する場合は、OSD が失われた場合に確実にデータが損失します。
手順
以下の復旧手順に従って、データを損失した後にアプリケーションを再度実行します。
Error
状態またはCrashLoopBackoff
状態の OSD Pod を見つけます。$ oc get pods -nopenshift-storage -l app=rook-ceph-osd | grep 'CrashLoopBackOff\|Error'
障害が発生した OSD があった replica-1 プールを特定します。
障害が発生した OSD が実行されていたノードを特定します。
failed_osd_id=0 #replace with the ID of the failed OSD
障害が発生した OSD が実行しているノードのゾーンを特定します。
failure_domain=$(oc get storageclass ocs-storagecluster-ceph-non-resilient-rbd -o yaml | grep domainLabel)
domainLabel=$”(oc get pods rook-ceph-osd-$failed_osd_id -o yaml | grep topology-location-$failure_domain:)”
出力には、次のようなプールが表示されます。
poolName= "ocs-storage cluster-ceph block pool-$domaiLabel”
$domaiLabel
は zoneName です。
replica-1 プールを削除します。
toolbox Pod に接続します。
toolbox=$(kubectl get pod -l app=rook-ceph-tools -noperator-namespace -o jsonpath='{.items[*].metadata.name}') oc rsh $toolbox -noperator-namespace
replica-1 プールを削除します。
ceph osd pool rm replica1-pool-name replica1-pool-name yes-I-really-really-mean-it
失敗した OSD Pod のデプロイメントをスケールダウンします。
failed_osd_id=0 #replace with the ID of the failed OSD oc scale deployment -nopenshift-storage rook-ceph-osd-$failed_osd_id --replicas=0
- 上記で特定された OSD をパージします。デバイスの置き換え ガイドのプラットフォームに基づいて、動作可能なストレージデバイスまたは障害が発生したストレージデバイスの置き換えセクションの手順を実行します。
- LSO を使用するプラットフォームの場合は、ディスクをワイプまたは交換します。
rook-ceph operator を再起動します。
$ oc delete pod -l rook-ceph-operator -nopenshift-storage
- 影響を受けるアプリケーションをそのアベイラビリティーゾーン内に再作成して、同じ名前の新しいプールの使用を開始します。