第7章 既知の問題

フェイルオーバーアクションは、RPC エラー still in use を表示し、Pod で失敗した RADOS ブロックデバイスのイメージマウントを報告する。

障害復旧 (DR) で保護されるワークロードをフェイルオーバーすると、フェイルオーバーしたクラスター上のボリュームを使用している Pod が、RADOS ブロックデバイス (RBD) イメージがまだ使用中であることを報告する時に停止する可能性があります。これにより、Pod が長時間 (最大数時間) 起動できなくなります。

(BZ#2007376)

マネージドクラスターのアプリケーション namespace が作成される

アプリケーション namespace は、Disaster Recovery(DR) 関連の事前デプロイアクションのために RHACM マネージドクラスターに存在する必要があるため、アプリケーションが ACM ハブクラスターにデプロイされるときに事前に作成されます。ただし、アプリケーションがハブクラスターで削除され、対応する namespace がマネージドクラスターで削除された場合、それらはマネージドクラスターに再表示されます。

回避策: openshift-dr は、ACM ハブのマネージドクラスター namespace に namespace manifestwork リソースを維持します。これらのリソースは、アプリケーションの削除後に削除する必要があります。たとえば、クラスター管理者として、ハブクラスターで oc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mw のコマンドを実行します。

(BZ#2059669)

クラスターがストレッチモードの場合、ceph df が無効な MAX AVAIL 値を報告する

Red Hat Ceph Storage クラスターのクラッシュルールに複数の実行ステップがある場合、ceph df レポートは、マップの使用可能な最大サイズを間違って表示します。この問題は、今後のリリースで修正される予定です。

(BZ#2100920)

両方の DRPC が、同じ namespace で作成されたすべての永続ボリューム要求を保護する

複数の障害復旧 (DR) で保護されたワークロードをホストする namespace は、指定されていないハブクラスター上の同じ namespace 内の各 DRPlacementControl リソースの namespace にある永続ボリュームクレーム (PVC) をすべて保護し、その spec.pvcSelector フィールドを使用してワークロードに基づいて PVC を分離します。

これにより、複数のワークロードにわたって DRPlacementControl spec.pvcSelector に一致する PVC が生成されます。あるいは、すべてのワークロードでセレクターが欠落している場合、レプリケーション管理が各 PVC を複数回管理し、個々の DRPlacementControl アクションに基づいてデータの破損または無効な操作を引き起こす可能性があります。

回避策: ワークロードに属する PVC に一意のラベルを付け、選択したラベルを DRPlacementControl spec.pvcSelector として使用して、どの DRPlacementControl が namespace 内の PVC のどのサブセットを保護および管理するかを明確にします。ユーザーインターフェイスを使用して DRPlacementControl の spec.pvcSelector フィールドを指定することはできません。したがって、そのようなアプリケーションの DRPlacementControl を削除し、コマンドラインを使用して作成する必要があります。

結果: PVC は複数の DRPlacementControl リソースによって管理されなくなり、操作およびデータの不整合は発生しません。

(BZ#2111163)

MongoDB Pod は、cephrbd ボリュームのデータを読み取る許可エラーのため、CrashLoopBackoff になっています

異なるマネージドクラスターにまたがる Openshift プロジェクトには、異なるセキュリティーコンテキスト制約 (SCC) があり、特に指定された UID 範囲と FSGroups が異なります。これにより、特定のワークロード Pod とコンテナーが、ログ内のファイルシステムアクセスエラーが原因で、これらのプロジェクト内でフェイルオーバーの操作または再配置操作を開始できなくなります。

回避策: ワークロードプロジェクトが同じプロジェクトレベルの SCC ラベルを持つすべてのマネージドクラスターで作成されていることを確認し、フェイルオーバーまたは再配置時に同じファイルシステムコンテキストを使用できるようにします。Pod は、ファイルシステム関連のアクセスエラーで DR 後のアクションに失敗しなくなりました。

(BZ#2114573)

再配置中にアプリケーションが Relocating 状態でスタックする

マルチクラウドオブジェクトゲートウェイでは、同じ名前または namespace の複数の永続ボリューム (PV) オブジェクトを同じパスの S3 ストアに追加できました。これにより、同一の claimRef を指す複数のバージョンが検出されたため、Ramen は PV を復元しません。

回避策: S3 CLI または同等の機能を使用して、重複する PV オブジェクトを S3 ストアからクリーンアップします。タイムスタンプがフェイルオーバーまたは再配置の時刻に近いものだけを保持します。

結果: 復元操作が完了し、フェイルオーバーまたは再配置操作が次のステップに進みます。

(BZ#2120201)

障害復旧のワークロードが削除されたままになる

クラスターからワークロードを削除すると、対応する Pod が FailedKillPod などのイベントで終了しない場合があります。これにより、PVC、VolumeReplication、VolumeReplicationGroup などの DR リソースに依存するガベージコレクションで遅延または障害が発生する可能性があります。また、古いリソースがまだガベージコレクションされていないため、クラスターへの同じワークロードの今後のデプロイもできなくなります。

回避策: Pod が現在実行中で、終了状態でスタックしているワーカーノードを再起動します。これにより、Pod が正常に終了し、その後、関連する DR API リソースもガベージコレクションされます。

(BZ#2159791)

マネージドクラスターが OpenShift Container Platform と OpenShift Data Foundation の異なるバージョン上にある場合、アプリケーションのフェイルオーバーが Failover 状態でハングする

OpenShift Data Foundation 4.14 を使用した障害復旧ソリューションは、永続ボリューム (PV) データに加えて永続ボリューム要求 (PVC) データを保護および復元します。プライマリークラスターが古い OpenShift Data Foundation バージョン上にあり、ターゲットクラスターが 4.14 に更新されている場合、S3 ストアに PVC データがないため、フェイルオーバーが停止します。

回避策: Disaster Recovery クラスターをアップグレードする場合は、最初にプライマリークラスターをアップグレードしてから、アップグレード後の手順を実行する必要があります。

(BZ#2214306)

DRPolicy が同じ namespace 内の複数のアプリケーションに適用されると、ボリュームレプリケーショングループが作成されない

namespace 内の他のアプリケーションと同じ場所に配置されているアプリケーション用に DRPlacementControl (DRPC) が作成される場合、DRPC にはアプリケーション用のラベルセレクターセットがありません。その後ラベルセレクターに変更が加えられた場合、OpenShift Data Foundation Hub コントローラーの検証アドミッション Webhook は変更を拒否します。

回避策: アドミッション Webhook がそのような変更を許可するように変更されるまでは、DRPC validatingwebhookconfigurations にパッチを適用して Webhook を削除できます。

$ oc patch validatingwebhookconfigurations vdrplacementcontrol.kb.io-lq2kz --type=json --patch='[{"op": "remove", "path": "/webhooks"}]'

(BZ#2210762)

c1 クラスターから c2 クラスターへのアプリのフェイルオーバーがフェイルオーバーでハングする

S3 ストアの設定ミスによりデータが S3 ストアにアップロードされない場合でも、Ramen は、フェイルオーバーアクションを無効にしないので、フェイルオーバー中にフェイルオーバークラスターでクラスターデータが利用できません。そのため、フェイルオーバーを完了できません。

回避策: 初期デプロイ後に Ramen ログを調べて、s3 設定エラーが報告されていないことを確認します。

$ oc get drpc -o yaml

(BZ#2248723)

ハブ復旧後のデータ損失の潜在的なリスク

孤立したリソースをクリーンアップするように設計されたエビクションルーチンにより、ハブの回復後に潜在的なデータ損失のリスクが存在します。このルーチンは、コレクション用の対応する ManifestWorks が欠如している AppliedManifestWorks インスタンスを識別し、マークします。1 時間のハードコーディングされた猶予期間が提供されます。この期間が経過すると、AppliedManifestWork に関連付けられたすべてのリソースがガベージコレクションの対象になります。

ハブクラスターが最初の 1 時間以内に対応する ManifestWorks を再生成できなかった場合は、データ損失が発生する可能性があります。これは、データ損失のリスクを最小限に抑えるために、ManifestWorks の ハブ後のリカバリーの再作成を妨げる可能性がある問題に迅速に対処することの重要性を強調しています。

(BZ-2252933)