第7章 障害復旧のトラブルシューティング
7.1. Metro-DR のトラブルシューティング
7.1.1. フェイルオーバー後にステートフルセットアプリケーションがスタックする
- 問題
優先クラスターへの再配置中に、DRPlacementControl が停止し、PROGRESSION に "MovingToSecondary" と報告されます。
以前は、Kubernetes v1.23 より前のバージョンでは、Kubernetes コントロールプレーンが StatefulSet 用に作成された PVC をクリーンアップしませんでした。このアクティビティーは、クラスター管理者または StatefulSet を管理するソフトウェア operator に任されていました。これが原因で、Pod が削除されたときに、StatefulSet の PVC はそのまま残されました。これにより、Ramen がアプリケーションを優先クラスターに再配置できなくなります。
- 解決方法
ワークロードが StatefulSets を使用していて、再配置が停止し、PROGRESSION に "MovingToSecondary" と報告される場合は、次を実行します。
$ oc get pvc -n <namespace>
StatefulSet に属するnamespace の制限付き PVC ごとに、次を実行します。
$ oc delete pvc <pvcname> -n namespace
すべての PVC が削除されると、ボリュームレプリケーショングループ (VRG) はセカンダリーに移行してから削除されます。
以下のコマンドを実行します。
$ oc get drpc -n <namespace> -o wide
数秒から数分後、PROGRESSION に "Completed" と報告され、再配置が完了します。
- 結果
- ワークロードが優先クラスターに再配置されます。
BZ リファレンス: 2118270
7.1.2. DR ポリシーが同じ namespace 内のすべてのアプリケーションを保護する
- 問題
-
DR ポリシーで使用するアプリケーションが 1 つだけ選択されている場合でも、同じnamespace 内のすべてのアプリケーションが保護されます。これにより、複数のワークロードで
DRPlacementControl
spec.pvcSelector
に一致する PVC が生成されるか、すべてのワークロードでセレクターが欠落している場合、レプリケーション管理が各 PVC を複数回管理し、個々のDRPlacementControl
アクションに基づいてデータの破損または無効な操作を引き起こす可能性があります。 - 解決方法
-
ワークロードに属する PVC に一意のラベルを付け、選択したラベルを DRPlacementControl
spec.pvcSelector
として使用して、どの DRPlacementControl がネームスペース内の PVC のどのサブセットを保護および管理するかを明確にします。ユーザーインターフェイスを使用して DRPlacementControl のspec.pvcSelector
フィールドを指定することはできません。したがって、そのようなアプリケーションの DRPlacementControl を削除し、コマンドラインを使用して作成する必要があります。
BZ リファレンス: [2128860]
7.1.3. アプリケーションのフェイルバック中に Relocating 状態でスタックする
- 問題
-
この問題は、アプリケーションのフェイルオーバーおよびフェイルバックを実行した後 (すべてのノードまたはクラスターが稼働している) に発生する可能性があります。フェールバックを実行すると、アプリケーションが
Relocating
状態でスタックし、PV リストアの完了に対してWaiting
というメッセージが表示されます。 - 解決方法
- S3 クライアントまたは同等のサービスを使用して、重複する PV オブジェクトを s3 ストアからクリーンアップします。タイムスタンプがフェイルオーバーまたは再配置の時刻に近いものだけを保持します。
BZ リファレンス: 2120201
7.1.4. 再配置またはフェイルバックが Initiating
状態でスタックする可能性がある
- 問題
-
プライマリークラスターがダウンして、セカンダリークラスターがダウンしている間にオンラインに戻ると、
relocate
またはfailback
がInitiating
の状態でスタックする可能性があります。 - 解決方法
この状況を回避するには、古いアクティブなハブからマネージドクラスターへの全アクセスを遮断します。
あるいは、ワークロードを移動する前またはクリーンアップフェーズにあるときに、古いアクティブハブクラスター上の ApplicationSet コントローラーをスケールダウンすることもできます。
以前のアクティブなハブで、以下のコマンドを使用して 2 つのデプロイメントをスケールダウンします。
$ oc scale deploy -n openshift-gitops-operator openshift-gitops-operator-controller-manager --replicas=0 $ oc scale statefulset -n openshift-gitops openshift-gitops-application-controller --replicas=0
BZ リファレンス: [2243804]