3.16. 検出対象アプリケーションの障害復旧保護
Red Hat OpenShift Data Foundation は、Red Hat Advanced Cluster Management (RHACM) を使用せずに、マネージドクラスターの 1 つに直接デプロイされたワークロードに対して、障害復旧 (DR) 保護とサポートを提供するようになりました。このようなワークロードは、検出対象アプリケーションと呼ばれます。
RHACM を使用してデプロイされるワークロードは、管理対象アプリケーションと呼ばれるようになりました。RHACM を使用せずにマネージドクラスターの 1 つにワークロードを直接デプロイした場合、そのワークロードは検出対象アプリケーションと呼ばれます。このようなワークロードの詳細は RHACM コンソールで確認できますが、アプリケーションのライフサイクル (作成、削除、編集) は RHACM によって管理されません。
3.16.1. 検出対象アプリケーションの障害復旧保護の前提条件
このセクションでは、検出対象アプリケーションを保護するための前提条件を説明します。これには、データポリシーの割り当てや DR アクション (フェイルオーバーや再配置) の開始などのタスクが含まれます。
- すべての DR 設定がプライマリーマネージドクラスターとセカンダリーマネージドクラスターにインストールされていることを確認します。
OADP 1.4 Operator をインストールします。
注記OADP 1.4 より前のバージョンでは、検出対象アプリケーションの保護が機能しません。
-
プライマリー および セカンダリーマネージドクラスター で OperatorHub に移動し、キーワードフィルターを使用して
OADP
を検索します。 - OADP タイルをクリックします。
-
すべてのデフォルト設定をそのままにして、Install をクリックします。Operator リソースが
openshift-adp
プロジェクトにインストールされていることを確認します。
注記DR 設定を完了した後に OADP 1.4 をインストールする場合は、namespace
openshift-dr-system
内の プライマリーマネージドクラスター および セカンダリーマネージドクラスター のramen-dr-cluster-operator
Pod を再起動 (削除して再作成) する必要があります。-
プライマリー および セカンダリーマネージドクラスター で OperatorHub に移動し、キーワードフィルターを使用して
[オプション] CACertificates を
ramen-hub-operator-config
ConfigMap に追加します。プライマリークラスターとセカンダリークラスター間のネットワーク (SSL) アクセスを設定して、メタデータを、セキュアなトランスポートプロトコルを使用して別のクラスターの Multicloud Gateway (MCG) オブジェクトバケットに保存し、ハブクラスターに保存してオブジェクトバケットへのアクセスを検証できるようにします。
注記すべての OpenShift クラスターが環境の署名済みの有効な証明書セットを使用してデプロイされる場合は、このセクションを省略できます。
自己署名証明書を使用している場合は、
openshift-config
namespace にuser-ca-bundle
という名前の ConfigMap がすでに作成されており、この ConfigMap がデフォルトの Proxy クラスターリソースに追加されています。CACertificates のエンコード済みの値を見つけます。
$ oc get configmap user-ca-bundle -n openshift-config -o jsonpath="{['data']['ca-bundle\.crt']}" |base64 -w 0
この base64 でエンコードされた値を、Hub クラスターの configmap
ramen-hub-operator-config
に追加します。以下の例に、CACertificates を追加する場所を示します。$ oc edit configmap ramen-hub-operator-config -n openshift-operators
[...] ramenOpsNamespace: openshift-dr-ops s3StoreProfiles: - s3Bucket: odrbucket-36bceb61c09c s3CompatibleEndpoint: https://s3-openshift-storage.apps.hyper3.vmw.ibmfusion.eu s3ProfileName: s3profile-hyper3-ocs-storagecluster s3Region: noobaa s3SecretRef: name: 60f2ea6069e168346d5ad0e0b5faa59bb74946f caCertificates: {input base64 encoded value here} - s3Bucket: odrbucket-36bceb61c09c s3CompatibleEndpoint: https://s3-openshift-storage.apps.hyper4.vmw.ibmfusion.eu s3ProfileName: s3profile-hyper4-ocs-storagecluster s3Region: noobaa s3SecretRef: name: cc237eba032ad5c422fb939684eb633822d7900 caCertificates: {input base64 encoded value here}
プライマリーマネージドクラスター と セカンダリーマネージドクラスター の OADP Operator のデフォルト namespace
openshift-adp
に、DR シークレットが作成されていることを確認します。最初の DRPolicy 作成時に作成される DR シークレットは、以下のシークレットに類似したものになります。DR シークレット名の前には文字v
が付きます。$ oc get secrets -n openshift-adp NAME TYPE DATA AGE v60f2ea6069e168346d5ad0e0b5faa59bb74946f Opaque 1 3d20h vcc237eba032ad5c422fb939684eb633822d7900 Opaque 1 3d20h [...]
注記openshift-adp
namespace 内の各マネージドクラスターに 1 つの DR 作成シークレットが存在します。OADP namespace
openshift-adp
内の各マネージドクラスターに Data Protection Application (DPA) がすでにインストールされているかどうかを確認します。まだ作成されていない場合は、次の手順に従ってこのリソースを作成します。次の YAML 定義コンテンツを
dpa.yaml
にコピーして DPA を作成します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: labels: app.kubernetes.io/component: velero name: velero namespace: openshift-adp spec: backupImages: false configuration: nodeAgent: enable: false uploaderType: restic velero: defaultPlugins: - openshift - aws noDefaultBackupLocation: true
DPA リソースを作成します。
$ oc create -f dpa.yaml -n openshift-adp
dataprotectionapplication.oadp.openshift.io/velero created
OADP リソースが作成され、
Running
状態になっていることを確認します。$ oc get pods,dpa -n openshift-adp NAME READY STATUS RESTARTS AGE pod/openshift-adp-controller-manager-7b64b74fcd-msjbs 1/1 Running 0 5m30s pod/velero-694b5b8f5c-b4kwg 1/1 Running 0 3m31s NAME AGE dataprotectionapplication.oadp.openshift.io/velero 3m31s
3.16.2. サンプル検出対象アプリケーションの作成
プライマリーマネージドクラスター から セカンダリーマネージドクラスター への フェイルオーバー
をテストし、検出対象アプリケーションを 再配置
するには、RHACM のアプリケーション作成機能を使用せずにインストールされたサンプルアプリケーションが必要です。
手順
プライマリーマネージドクラスター にログインし、サンプルアプリケーションリポジトリーのクローンを作成します。
$ git clone https://github.com/red-hat-storage/ocm-ramen-samples.git
main
ブランチにいることを確認します。$ cd ~/ocm-ramen-samples $ git branch * main
お客様のシナリオ、都市、地域に基づいてサンプルアプリケーションを作成する場合は、適切なディレクトリーを使用してください。
注記検出対象アプリケーションでは、CephRBD またはブロックボリュームを使用するアプリケーションのみがサポートされます。
$ ls workloads/deployment | egrep -v 'cephfs|k8s|base' odr-metro-rbd odr-regional-rbd
プライマリーマネージドクラスターとセカンダリーマネージドクラスター の両方に、
busybox-discovered
という名前のプロジェクトを作成します。$ oc new-project busybox-discovered
プライマリーマネージドクラスター に
busybox
アプリケーションを作成します。このサンプルアプリケーションの例は、ブロック (Ceph RBD) ボリュームを使用する Metro-DR 用です。$ oc apply -k workloads/deployment/odr-metro-rbd -n busybox-discovered persistentvolumeclaim/busybox-pvc created deployment.apps/busybox created
注記OpenShift Data Foundation Disaster Recovery ソリューションによる保護は、複数の namespace にまたがる検出対象アプリケーションにまで拡張されました。
プライマリーマネージドクラスター 上の正しいプロジェクトで busybox が実行されていることを確認します。
$ oc get pods,pvc,deployment -n busybox-discovered
NAME READY STATUS RESTARTS AGE pod/busybox-796fccbb95-qmxjf 1/1 Running 0 18s NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE persistentvolumeclaim/busybox-pvc Bound pvc-b20e4129-902d-47c7-b962-040ad64130c4 1Gi RWO ocs-storagecluster-ceph-rbd <unset> 18s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/busybox 1/1 1 1 18
3.16.3. 障害復旧保護のためにサンプル検出アプリケーションを登録する
このセクションでは、Protected applications タブから検出対象アプリケーションに既存の DR ポリシーを適用する方法を説明します。
前提条件
- 障害復旧が設定されており、少なくとも 1 つの DR ポリシーが作成されている。
手順
-
RHACM コンソールで、Disaster recovery
Protected applications タブに移動します。 - DR 保護用に既存のアプリケーションを設定するために、Enroll application をクリックします。
- ACM discovered applications を選択します。
-
Namespace ページで DR cluster を選択します。これは
busybox
がインストールされている プライマリーマネージドクラスター の名前です。 アプリケーションがインストールされている namespace を選択します。たとえば、
busybox-discovered
です。注記ワークロードが複数の namespace に分散している場合は、それらの namespace すべてを DR 保護対象として選択できます。
-
検出対象アプリケーションの一意の 名前 (例:
busybox-rbd
) を選択し、Next をクリックします。 - Configuration ページで、Resource label を使用してリソースを保護します。ここで、kubernetes-object バックアップに含めるリソースと、ボリュームのレプリケート対象の永続データを設定できます。Resource label はデフォルトで選択されています。
-
ラベル式と PVC ラベルセレクターを指定します。kubernetes-objects と PVC の両方に対して ラベル
appname=busybox
を選択します。 - Next をクリックします。
Replication ページで、既存の DR Policy と kubernetes-objects backup interval を選択します。
注記PVC データレプリケーションと kubernetes オブジェクトのバックアップ間隔には、同じ期間 (5 分など) を選択することを推奨します。
- Next をクリックします。
設定を確認して、Save をクリックします。
問題を修正するには、Back ボタンを使用して画面に戻ります。
DR のフェイルオーバーと再配置のテストに進む前に、アプリケーションボリューム (PVC) と Kubernetes-objects のバックアップが Healthy 状態であることを確認します。検出対象アプリケーションのステータスは、Protected applications タブで確認できます。
DRPC のステータスを確認するために、ハブクラスターで次のコマンドを実行します。
$ oc get drpc {drpc_name} -o wide -n openshift-dr-ops
検出対象アプリケーションは、DRPlacementControl (DRPC) や Placement などのリソースを、
openshift-dr-ops
という新しい namespace のハブクラスターに保存します。DRPC 名は、前の手順で設定した一意の名前 (例:busybox-rbd
) によって識別できます。検出対象アプリケーションの VolumeReplicationGroup (VRG) のステータスを確認するために、busybox アプリケーションを手動でインストールしたマネージドクラスターで次のコマンドを実行します。
$ oc get vrg {vrg_name} -n openshift-dr-ops
検出対象アプリケーションに DR ポリシーが割り当てられると、VRG リソースは namespace
openshift-dr-ops
に保存されます。VRG 名は、前の手順で設定した一意の名前 (例:busybox-rbd
) によって識別できます。
3.16.4. 検出対象アプリケーションのフェイルオーバーと再配置
保護された検出対象アプリケーションは、管理対象アプリケーション と同様に、ピアクラスターに フェイルオーバー または 再配置 できます。ただし、アプリケーションのライフサイクルが管理対象アプリケーションのように RHACM によって管理されないため、検出対象アプリケーションには追加の手順がいくつかあります。
このセクションでは、保護された検出対象アプリケーションのフェイルオーバーおよび再配置プロセスを説明します。
1 つまたは両方のリソースタイプが Warning または Critical ステータスにある場合は、アプリケーションのフェイルオーバーまたは再配置を開始しないでください。
3.16.4.1. 障害復旧により保護された検出対象アプリケーションのフェイルオーバー
このセクションでは、障害復旧により保護された検出対象アプリケーションをフェイルオーバーする方法を説明します。
前提条件
-
両方のマネージドクラスターにアプリケーションの namespace が作成されていることを確認する (例:
busybox-discovered
)。
手順
Hub cluster でフェンシングを有効にします。
CLI ターミナルを開き、DRCluster resource を編集します。<drcluster_name> は一意の名前に置き換えます。
注意マネージドクラスターがフェンスされると、アプリケーションから OpenShift Data Foundation 外部ストレージクラスターへの すべて の通信が失敗し、現在フェンスされているクラスターの一部の Pod が異常な状態 (
CreateContainerError
、CrashLoopBackOff
など) になります。$ oc edit drcluster <drcluster_name>
apiVersion: ramendr.openshift.io/v1alpha1 kind: DRCluster metadata: [...] spec: ## Add this line clusterFence: Fenced cidrs: [...] [...]
出力例:
drcluster.ramendr.openshift.io/ocp4perf1 edited
Hub cluster 上の プライマリーマネージドクラスター のフェンシングステータスを確認します。<drcluster_name> は、一意の識別子に置き換えます。
$ oc get drcluster.ramendr.openshift.io <drcluster_name> -o jsonpath='{.status.phase}{"\n"}'
出力例:
Fenced
Ceph クラスターにログインし、OpenShift Container Platform クラスターノードに属する IP がブロックリストに含まれていることを確認します。
$ ceph osd blocklist ls
出力例
cidr:10.1.161.1:0/32 2028-10-30T22:30:03.585634+0000 cidr:10.1.161.14:0/32 2028-10-30T22:30:02.483561+0000 cidr:10.1.161.51:0/32 2028-10-30T22:30:01.272267+0000 cidr:10.1.161.63:0/32 2028-10-30T22:30:05.099655+0000 cidr:10.1.161.129:0/32 2028-10-30T22:29:58.335390+0000 cidr:10.1.161.130:0/32 2028-10-30T22:29:59.861518+0000
-
RHACM コンソールで、Disaster Recovery
Protected applications タブに移動します。 - アプリケーション行の最後で、Actions メニューをクリックし、フェイルオーバー の開始を選択します。
- Failover application モーダルウィンドウで、アプリケーションとターゲットクラスターのステータスを確認します。
-
Initiate をクリックします。
Failover
プロセスが完了するまで待ちます。 セカンダリーマネージドクラスター で busybox アプリケーションが実行されていることを確認します。
$ oc get pods,pvc -n busybox-discovered NAME READY STATUS RESTARTS AGE pod/busybox-796fccbb95-qmxjf 1/1 Running 0 2m46s NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE persistentvolumeclaim/busybox-pvc Bound pvc-b20e4129-902d-47c7-b962-040ad64130c4 1Gi RWO ocs-storagecluster-ceph-rbd <unset> 2m57s
結果が
WaitOnUserToCleanup
になるまで、フェイルオーバーの進行状況を確認します。DRPC 名は、前の手順で設定した一意の名前 (例:busybox-rbd
) によって識別できます。$ oc get drpc {drpc_name} -n openshift-dr-ops -o jsonpath='{.status.progression}{"\n"}' WaitOnUserToCleanUp
プライマリーマネージドクラスター から busybox アプリケーションを削除し、
Failover
プロセスを完了します。- Protected applications タブに移動します。アプリケーションを削除するためのメッセージが表示されます。
busybox
のクローンリポジトリーに移動し、フェイルオーバー
元の プライマリーマネージドクラスター で次のコマンドを実行します。アプリケーションの作成に使用したのと同じディレクトリー (odr-metro-rbd
など) を使用します。$ cd ~/ocm-ramen-samples/ $ git branch * main $ oc delete -k workloads/deployment/odr-metro-rbd -n busybox-discovered persistentvolumeclaim "busybox-pvc" deleted deployment.apps "busybox" deleted
- アプリケーションを削除した後、Protected applications タブに移動し、busybox リソースが両方とも Healthy 状態であることを確認します。
3.16.4.2. 障害復旧により保護された検出対象アプリケーションの再配置
このセクションでは、障害復旧により保護された検出対象アプリケーションを再配置する方法を説明します。
手順
ハブクラスターでフェンシングを無効にします。
このクラスターの DRCluster リソース を編集し、<drcluster_name> を一意の名前に置き換えます。
$ oc edit drcluster <drcluster_name>
apiVersion: ramendr.openshift.io/v1alpha1 kind: DRCluster metadata: [...] spec: cidrs: [...] ## Modify this line clusterFence: Unfenced [...] [...]
出力例:
drcluster.ramendr.openshift.io/ocp4perf1 edited
Fenced
であった OpenShift Container Platform ノードを正常に再起動します。リカバリーオーケストレーションの障害がさらに発生しないように、フェンシング解除後に I/O 操作を再開するには、再起動が必要です。ノードの正常な再起動 の手順に従って、クラスターのすべてのノードを再起動します。注記ノードで再起動して uncordon 操作を実行する前に、すべてのノードが最初に接続解除され、ドレインされていることを確認してください。
すべての OpenShift ノードが再起動され、
Ready
ステータスになったら、プライマリーマネージドクラスター (または Unfenced されたクラスター) でこのコマンドを実行して、すべての Pod が正常な状態であることを確認します。oc get pods -A | egrep -v 'Running|Completed'
出力例:
NAMESPACE NAME READY STATUS RESTARTS AGE
次のステップに進む前に、このクエリーの出力は 0 Pod である必要があります。
重要ストレージ通信が切断されたために Pod がまだ異常な状態にある場合は、続行する前にトラブルシューティングを行って解決してください。ストレージクラスターは OpenShift の外部にあるため、OpenShift アプリケーションを正常に動作させるには、サイトの停止後にストレージクラスターを適切に復元する必要もあります。
または、OpenShift Web コンソールのダッシュボードと概要タブを使用して、アプリケーションと外部 ODF ストレージクラスターの正常性を評価することもできます。OpenShift Data Foundation ダッシュボードの詳細は、Storage
Data Foundation に移動すると表示されます。 Unfenced
クラスターが正常な状態であることを確認します。プライマリーマネージドクラスターのハブクラスターのフェンシングステータスを確認します。<drcluster_name> は、一意の名前に置き換えます。$ oc get drcluster.ramendr.openshift.io <drcluster_name> -o jsonpath='{.status.phase}{"\n"}'
出力例:
Unfenced
Ceph クラスターにログインし、OpenShift Container Platform クラスターノードに属する IP がブロックリストに含まれていないことを確認します。
$ ceph osd blocklist ls
フェンシング中に追加された IP が表示されていないことを確認します。
-
RHACM コンソールで、Disaster Recovery
Protected applications タブに移動します。 - アプリケーション行の最後で、Actions メニューをクリックし、再配置 の開始を選択します。
- Relocate application モーダルウィンドウで、アプリケーションとターゲットクラスターのステータスを確認します。
- Initiate をクリックします。
結果が
WaitOnUserToCleanup
になるまで、再配置の進行状況を確認します。DRPC 名は、前の手順で設定した一意の名前 (例:busybox-rbd
) によって識別できます。$ oc get drpc {drpc_name} -n openshift-dr-ops -o jsonpath='{.status.progression}{"\n"}' WaitOnUserToCleanUp
プライマリーマネージドクラスター への 再配置 が完了する前に、セカンダリーマネージドクラスター から busybox アプリケーションを削除します。
busybox
のクローンリポジトリーに移動し、再配置
元の セカンダリーマネージドクラスター で次のコマンドを実行します。アプリケーションの作成に使用したのと同じディレクトリー (odr-metro-rbd
など) を使用します。$ cd ~/ocm-ramen-samples/ $ git branch * main $ oc delete -k workloads/deployment/odr-metro-rbd -n busybox-discovered persistentvolumeclaim "busybox-pvc" deleted deployment.apps "busybox" deleted
- アプリケーションを削除した後、Protected applications タブに移動し、busybox リソースが両方とも Healthy 状態であることを確認します。
プライマリーマネージドクラスター で
busybox
アプリケーションが実行されていることを確認します。$ oc get pods,pvc -n busybox-discovered NAME READY STATUS RESTARTS AGE pod/busybox-796fccbb95-qmxjf 1/1 Running 0 2m46s NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE persistentvolumeclaim/busybox-pvc Bound pvc-b20e4129-902d-47c7-b962-040ad64130c4 1Gi RWO ocs-storagecluster-ceph-rbd <unset> 2m57s
3.16.5. 保護されたアプリケーションの障害復旧の無効化
このセクションでは、保護されたアプリケーションを削除する場合、またはアプリケーションを保護する必要がなくなった場合に、障害復旧リソースを無効にする方法を説明します。
手順
- ハブクラスターにログインします。
DRPlacementControl
(DRPC) リソースをリスト表示します。DRPC リソースは、アプリケーションに DR ポリシーを割り当てるときにそれぞれ作成されたものです。$ oc get drpc -n openshift-dr-ops
DR ポリシーを割り当てるときに選択した一意の識別子 (たとえば、
busybox-rbd
) を含む名前を持つ DRPC を見つけて、その DRPC を削除します。$ oc delete {drpc_name} -n openshift-dr-ops
Placement リソースをリスト表示します。Placement リソースは、アプリケーションに DR ポリシーを割り当てるときにそれぞれ作成されたものです。
$ oc get placements -n openshift-dr-ops
DR ポリシーを割り当てるときに選択した一意の識別子 (たとえば、
busybox-rbd-placement-1
) を含む名前を持つ Placement を見つけて、その Placement を削除します。$ oc delete placements {placement_name} -n openshift-dr-ops