7.2. Regional-DR のトラブルシューティング
7.2.1. rbd-mirror デーモンのヘルスが警告状態になる リンクのコピーリンクがクリップボードにコピーされました!
- 問題
ミラーサービス
::get_mirror_service_statusがCephモニターを呼び出してrbd-mirrorのサービスステータスを取得すると、WARNING が報告されるケースが多数あるようです。ネットワークの切断後、
rbd-mirrorデーモンの正常性はwarning状態になりますが、両方のマネージドクラスター間の接続は問題ありません。- 解決方法
ツールボックスで次のコマンドを実行し、
leader:falseを探します。rbd mirror pool status --verbose ocs-storagecluster-cephblockpool | grep 'leader:'
rbd mirror pool status --verbose ocs-storagecluster-cephblockpool | grep 'leader:'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力に次のように表示される場合:
leader: falseこれは、デーモンの起動に問題があることを示しており、最も可能性の高い根本原因は、セカンダリークラスターへの確実な接続の問題である可能性があります。
回避策: Pod を削除するだけで
rbd-mirrorPod を別のノードに移動し、別のノードで再スケジュールされていることを確認します。leader: trueまたは出力なし
BZ リファレンス: [2118627]
7.2.2. 宛先ホスト名を解決できないため、volsync-rsync-src Pod がエラー状態になる リンクのコピーリンクがクリップボードにコピーされました!
- 問題
VolSyncソース Pod は、VolSync 宛先 Pod のホスト名を解決できません。VolSync Pod のログには、次のログスニペットのようなエラーメッセージが長時間にわたって一貫して表示されます。oc logs -n busybox-workloads-3-2 volsync-rsync-src-dd-io-pvc-1-p25rz
$ oc logs -n busybox-workloads-3-2 volsync-rsync-src-dd-io-pvc-1-p25rzCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
VolSync rsync container version: ACM-0.6.0-ce9a280 Syncing data to volsync-rsync-dst-dd-io-pvc-1.busybox-workloads-3-2.svc.clusterset.local:22 ... ssh: Could not resolve hostname volsync-rsync-dst-dd-io-pvc-1.busybox-workloads-3-2.svc.clusterset.local: Name or service not known
VolSync rsync container version: ACM-0.6.0-ce9a280 Syncing data to volsync-rsync-dst-dd-io-pvc-1.busybox-workloads-3-2.svc.clusterset.local:22 ... ssh: Could not resolve hostname volsync-rsync-dst-dd-io-pvc-1.busybox-workloads-3-2.svc.clusterset.local: Name or service not knownCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 解決方法
両方のノードで
submariner-lighthouse-agentを再起動します。oc delete pod -l app=submariner-lighthouse-agent -n submariner-operator
$ oc delete pod -l app=submariner-lighthouse-agent -n submariner-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2.3. フェイルオーバー後に古いプライマリーのマネージドクラスターが復元された後に、ApplicationSet ワークロードのクリーンアップとデータ同期が停止したままになる リンクのコピーリンクがクリップボードにコピーされました!
- 問題
ハブクラスターに障害が発生した場合に、マネージドクラスターへの ApplicationSet ベースのワークロードのデプロイメントは、ガベージコレクションされません。ワークロードは残りのマネージドクラスターにフェイルオーバーされている間、スタンバイハブクラスターに復元されます。ワークロードのフェイルオーバー元のクラスターは、新しく回復されたスタンバイハブに再び参加します。
したがって、Regional DRPolicy で DR 保護されている ApplicationSet は、VolumeSynchronizationDelay アラートの起動を開始します。さらに、このような DR で保護されたワークロードは、2 つのクラスター間でデータが同期されていないため、ピアクラスターにフェイルオーバーしたり、ピアクラスターに再配置したりできません。
- 解決方法
回避策として、新しく回復したハブからワークロードのフェイルオーバーが実行された後にハブに再参加したマネージドクラスター上で孤立したワークロードリソースを
openshift-gitopsOperator が所有できる必要があります。これを行うには、次の手順を実行します。-
openshift-gitopsnamespace のハブクラスター上の ArgoCD ApplicationSet リソースによって使用されている配置を決定します。 このフィールドの ApplicationSet の配置ラベル値 (
spec.generators.clusterDecisionResource.labelSelector.matchLabels) を検査します。これは、配置リソース <placement-name> の名前になります。
ApplicationSet で参照される
PlacementにPlacemenDecisionが存在することを確認します。oc get placementdecision -n openshift-gitops --selector cluster.open-cluster-management.io/placement=<placement-name>
$ oc get placementdecision -n openshift-gitops --selector cluster.open-cluster-management.io/placement=<placement-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、現在必要なフェイルオーバークラスターにワークロードを配置する 1 つの
PlacementDecisionが生成されます。クリーンアップする必要があるクラスターを指す ApplicationSet の新しい
PlacementDecisionを作成します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新たに作成した
PlacementDecisionを subresource のステータスに更新します。decision-status.yaml: status: decisions: - clusterName: <managedcluster-name-to-clean-up> # This would be the cluster from where the workload was failed over, NOT the current workload cluster reason: FailoverCleanupdecision-status.yaml: status: decisions: - clusterName: <managedcluster-name-to-clean-up> # This would be the cluster from where the workload was failed over, NOT the current workload cluster reason: FailoverCleanupCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch placementdecision -n openshift-gitops <placemen-name>-decision-<n> --patch-file=decision-status.yaml --subresource=status --type=merge
$ oc patch placementdecision -n openshift-gitops <placemen-name>-decision-<n> --patch-file=decision-status.yaml --subresource=status --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow ApplicationSet のアプリケーションリソースが必要なクラスターに配置されていることを確認します。
oc get application -n openshift-gitops <applicationset-name>-<managedcluster-name-to-clean-up>
$ oc get application -n openshift-gitops <applicationset-name>-<managedcluster-name-to-clean-up>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力で、SYNC STATUS が
Syncedと表示され、HEALTH STATUS がHealthyとして表示されているかどうかを確認します。手順 (3) で作成した PlacementDecision を削除します。これにより、ArgoCD は <managedcluster-name-to-clean-up> 上のワークロードリソースをガベージコレクションできるようになります。
oc delete placementdecision -n openshift-gitops <placemen-name>-decision-<n>
$ oc delete placementdecision -n openshift-gitops <placemen-name>-decision-<n>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Regional DRPolicy で DR 保護されている ApplicationSet は、
VolumeSynchronizationDelayアラートの実行を停止します。-
BZ リファレンス: [2268594]