第7章 障害復旧のトラブルシューティング


7.1. Metro-DR のトラブルシューティング

7.1.1. フェイルオーバー後にステートフルセットアプリケーションがスタックする

問題

優先クラスターへの再配置中に、DRPlacementControl が停止し、PROGRESSION に "MovingToSecondary" と報告されます。

以前は、Kubernetes v1.23 より前のバージョンでは、Kubernetes コントロールプレーンが StatefulSet 用に作成された PVC をクリーンアップしませんでした。このアクティビティーは、クラスター管理者または StatefulSet を管理するソフトウェア operator に任されていました。これが原因で、Pod が削除されたときに、StatefulSet の PVC はそのまま残されました。これにより、Ramen がアプリケーションを優先クラスターに再配置できなくなります。

解決方法
  1. ワークロードが StatefulSets を使用していて、再配置が停止し、PROGRESSION に "MovingToSecondary" と報告される場合は、次を実行します。

    $ oc get pvc -n <namespace>
  2. StatefulSet に属するnamespace の制限付き PVC ごとに、次を実行します。

    $ oc delete pvc <pvcname> -n namespace

    すべての PVC が削除されると、ボリュームレプリケーショングループ (VRG) はセカンダリーに移行してから削除されます。

  3. 以下のコマンドを実行します。

    $ 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 または failbackInitiating の状態でスタックする可能性があります。
解決方法

この状況を回避するには、古いアクティブなハブからマネージドクラスターへの全アクセスを遮断します。

あるいは、ワークロードを移動する前またはクリーンアップフェーズにあるときに、古いアクティブハブクラスター上の 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]

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.