第7章 既知の問題
このセクションでは、Red Hat OpenShift Data Foundation 4.15 の既知の問題について説明します。
7.1. 障害復旧
マネージドクラスターのアプリケーション namespace の作成
アプリケーション namespace は、Disaster Recovery(DR) 関連の事前デプロイアクションのために RHACM マネージドクラスターに存在する必要があるため、アプリケーションが ACM ハブクラスターにデプロイされるときに事前に作成されます。ただし、アプリケーションがハブクラスターで削除され、対応する namespace がマネージドクラスターで削除された場合、それらはマネージドクラスターに再表示されます。
回避策:
openshift-dr
は、ACM ハブのマネージドクラスター namespace に namespacemanifestwork
リソースを維持します。これらのリソースは、アプリケーションの削除後に削除する必要があります。たとえば、クラスター管理者として、ハブクラスターで以下のコマンドを実行します。$ oc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mw
クラスターがストレッチモードの場合、ceph
df
が無効な MAX AVAIL 値を報告するRed Hat Ceph Storage クラスターのクラッシュルールに複数の実行ステップがある場合、
ceph df
レポートは、マップの使用可能な最大サイズを間違って表示します。この問題は、今後のリリースで修正される予定です。
両方の 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 リソースによって管理されなくなり、操作およびデータの不整合は発生しません。
MongoDB Pod は、
cephrbd
ボリュームのデータを読み取る許可エラーのため、CrashLoopBackoff
になっています異なるマネージドクラスターにまたがる Openshift プロジェクトには、異なるセキュリティーコンテキスト制約 (SCC) があり、特に指定された UID 範囲と
FSGroups
が異なります。これにより、特定のワークロード Pod とコンテナーが、ログ内のファイルシステムアクセスエラーが原因で、これらのプロジェクト内でフェイルオーバーの操作または再配置操作を開始できなくなります。回避策: ワークロードプロジェクトが同じプロジェクトレベルの SCC ラベルを持つすべてのマネージドクラスターで作成されていることを確認し、フェイルオーバーまたは再配置時に同じファイルシステムコンテキストを使用できるようにします。Pod は、ファイルシステム関連のアクセスエラーで DR 後のアクションに失敗しなくなりました。
障害復旧のワークロードが削除されたままになる
クラスターからワークロードを削除すると、対応する Pod が
FailedKillPod
などのイベントで終了しない場合があります。これにより、PVC
、VolumeReplication
、VolumeReplicationGroup
などの DR リソースに依存するガベージコレクションで遅延または障害が発生する可能性があります。また、古いリソースがまだガベージコレクションされていないため、クラスターへの同じワークロードの今後のデプロイもできなくなります。回避策: Pod が現在実行中で、終了状態でスタックしているワーカーノードを再起動します。これにより、Pod が正常に終了し、その後、関連する DR API リソースもガベージコレクションされます。
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"}]'
マネージドクラスターが OpenShift Container Platform と OpenShift Data Foundation の異なるバージョン上にある場合、アプリケーションのフェイルオーバーが
Failover
状態でハングするOpenShift Data Foundation を使用した障害復旧ソリューションは、永続ボリューム (PV) データに加えて永続ボリューム要求 (PVC) データを保護および復元します。プライマリークラスターが古い OpenShift Data Foundation バージョン上にあり、ターゲットクラスターが 4.15 に更新されている場合、S3 ストアに PVC データがないため、フェイルオーバーが停止します。
回避策: Disaster Recovery クラスターをアップグレードする場合は、最初にプライマリークラスターをアップグレードしてから、アップグレード後の手順を実行する必要があります。
c1 クラスターから c2 クラスターへのアプリのフェイルオーバーがフェイルオーバーでハングする
S3 ストアの設定ミスによりデータが S3 ストアにアップロードされない場合、フェイルオーバーアクションは Ramen では無効になりません。これは、フェイルオーバー中にフェイルオーバークラスターでクラスターデータが利用できないことを意味します。そのため、フェイルオーバーを完了できません。
回避策: 初期デプロイ後に Ramen ログを調べて、s3 設定エラーが報告されていないことを確認します。
$ oc get drpc -o yaml
ハブ復旧後のデータ損失の潜在的なリスク
孤立したリソースをクリーンアップするように設計されたエビクションルーチンにより、ハブの回復後に潜在的なデータ損失のリスクが存在します。このルーチンは、コレクション用の対応する
ManifestWorks
が欠如しているAppliedManifestWorks
インスタンスを識別し、マークします。1 時間のハードコーディングされた猶予期間が提供されます。この期間が経過すると、AppliedManifestWork
に関連付けられたすべてのリソースがガベージコレクションの対象になります。ハブクラスターが最初の 1 時間以内に対応する
ManifestWorks
を再生成できなかった場合は、データ損失が発生する可能性があります。これは、データ損失のリスクを最小限に抑えるために、ManifestWorks の
ハブ後のリカバリーの再作成を妨げる可能性がある問題に迅速に対処することの重要性を強調しています。
Regional DR Cephfs ベースのアプリケーションのフェイルオーバーで、サブスクリプションに関する警告が表示される
アプリケーションがフェイルオーバーまたは再配置されると、ハブサブスクリプションに "Some resources failed to deployUse View status YAML link to view the details." というエラーが表示されます。これは、バッキングストレージプロビジョナーとして CephFS を使用し、Red Hat Advanced Cluster Management for Kubernetes (RHACM) サブスクリプションでデプロイし、DR で保護されたアプリケーションの永続ボリューム要求 (PVC) がそれぞれの DR コントローラーにより所有されているためです。
回避策: サブスクリプションステータスのエラーを修正する回避策はありません。ただし、デプロイに失敗したサブスクリプションリソースをチェックして、それらが PVC であることを確認できます。これにより、他のリソースに問題が発生しないようにします。サブスクリプション内のデプロイに失敗した唯一のリソースが DR で保護されているリソースである場合、エラーは無視できます。
PeerReady
フラグを無効にすると、アクションをフェイルオーバーに変更できなくなりますDR コントローラーは、必要に応じて完全な調整を実行します。クラスターにアクセスできなくなると、DR コントローラーは健全性チェックを実行します。ワークロードがすでに再配置されている場合、この健全性チェックによりワークロードに関連付けられた
PeerReady
フラグが無効になり、クラスターがオフラインであるため健全性チェックは完了しません。その結果、無効にされたPeerReady
フラグは、アクションを Failover に変更できなくなります。回避策: コマンドラインインターフェイスを使用して、
PeerReady
フラグが無効になっているにもかかわらず、DR アクションをフェイルオーバーに変更します。
ストレッチクラスター内の 2 つのデータセンター間の接続が失われると、Ceph にアクセスできなくなり、IO が一時停止します。
2 つのデータセンターが相互の接続を失っても Arbiter ノードに接続されたままの場合は、モニター間で無限の選出が発生するという選出ロジックに不具合があります。その結果、モニターはリーダーを選出できず、Ceph クラスターが使用できなくなります。また、接続が切断されている間は IO が一時停止されます。
回避策: モニターがクォーラムを超えているデータセンターの 1 つでモニターをシャットダウンし (ceph -s コマンドを実行すると確認可)、残りのモニターの接続スコアをリセットします。
その結果、モニターがクォーラムを形成できるようになり、Ceph が再び使用可能になり、IOs resume が再開します。
フェイルオーバー後に古いプライマリー管理対象クラスターが復元された後、ApplicationSet ワークロードのクリーンアップとデータ同期が停止したままになる
ハブクラスターに障害が発生した場合に、マネージドクラスターへの ApplicationSet ベースのワークロードのデプロイメントは、ガベージコレクションされません。ワークロードは残りのマネージドクラスターにフェイルオーバーされている間、スタンバイハブクラスターに復元されます。ワークロードのフェイルオーバー元のクラスターは、新しく回復されたスタンバイハブに再び参加します。
障害復旧 (DR) で保護されており、リージョン DRPolicy が適用されている ApplicationSet は、
VolumeSynchronizationDelay
アラートの起動を開始します。さらに、このような DR で保護されたワークロードは、2 つのクラスター間でデータが同期されていないため、ピアクラスターにフェイルオーバーしたり、ピアクラスターに再配置したりできません。回避策は、OpenShift ワークロード用の OpenShift Data Foundation Disaster Recovery の設定 の Regional-DR のトラブルシューティングセクションを参照してください。