第7章 既知の問題

マネージドクラスターのアプリケーション 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)

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

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

(BZ#2007376)

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

障害復旧 (DR) で保護されるワークロードをフェイルオーバーすると、ボリュームにファイルシステムの整合性チェック (fsck) エラーがあると示すボリュームマウントエラーにより、Pod が起動しない可能性があります。これにより、ワークロードはフェイルオーバークラスターにフェイルオーバーできなくなります。

(BZ#2021460)

各アクションの数分以内にフェイルオーバーと再配置が実行されると、再配置が失敗します

PeerReady 条件ステータスが TRUE になる前に、ユーザーがあるクラスターから別のクラスターへのアプリケーションの再配置を開始すると、DRPC YAML ファイルを介して、または次の oc コマンドを実行することによって、条件ステータスが表示されます。

$ oc get drpc -o yaml -n <application-namespace>

<application-namespace> は、アプリケーションをデプロイするためのワークロードが存在する名前空間です。

ピア (ターゲットクラスター) がクリーンな状態になる前に再配置が開始された場合、再配置は永久に停止します。

回避策: DRPC .Spec.Action を Failover に戻し、PeerReady 条件ステータスが TRUE になるまで待ちます。回避策を適用した後、アクションを 再配置 に変更すると、再配置が有効になります。

(BZ#2056871)

ユーザーは、DR ポリシーの作成中に同期スケジュールとして値を 0 分に設定でき、レプリケーションポリシーとして同期を報告し、地域の DR セットアップで検証されます。

DRPolicyList ページは、sync 間隔の値を使用してレプリケーションタイプを表示します。ゼロに設定されている場合、レプリケーションタイプは、メトロクラスターと地域クラスターの同期 (同期) と見なされます。この問題はユーザーを混乱させます。これは、ユーザーインターフェイスに Async スケジューリングタイプとして表示されている場合でも、バックエンドが Sync を考慮しているためです。

回避策: sync または async を決定するには、DRCluster CR ステータスから Ceph Fsid をフェッチする必要があります。

(BZ#2114501)

アプリケーションを削除すると、Pod は削除されますが、PVC は削除されません

RHACM コンソールからアプリケーションを削除しても、DRPC は削除されません。DRPC を削除しないと、VRG だけでなく VRG も削除されません。VRG/VR が削除されない場合、PVC ファイナライザーリストがクリーンアップされず、PVC が Terminating 状態のままになります。

回避策: 次のコマンドを使用して、ハブクラスターの DRPC を手動で削除します

$ oc delete drpc <name> -n <namespace>

結果:

(BZ#2108716)

両方の DRPC が、同じ名前空間で作成されたすべての永続ボリューム要求を保護します

複数のディザスタリカバリー （DR） 保護ワークロードをホストするネームスペースは、その spec.pvcSelector フィールドを使用してワークロードに基づいて PVC を指定および分離しないハブクラスタの同じネームスペース内の各 DRPlacementControl リソースのネームスペース内のすべての持続ボリューム請求 (PVC) を保護します。

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

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

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

(BZ#2111163)

一部のイメージで RBD ミラースケジューリングが停止する

Ceph Manager デーモンは、さまざまな理由でブロックリストに登録されます。これにより、スケジュールされた RBD ミラースナップショットが、イメージがプライマリーであるクラスターでトリガーされなくなります。ミラーリングが有効になっている (つまり DR 保護されている) すべての RBD イメージは、rbd mirror snapshot schedule status -p ocs-storagecluster-cephblockpool を使用して調べたときにスケジュールを一覧表示しないため、ピアサイトにアクティブにミラーリングされません。

回避策: イメージがプライマリーである管理対象クラスターで Ceph Manager のデプロイを再起動して、現在実行中のインスタンスに対するブロックリストを回避します。これは、次のように Ceph Manager のデプロイをスケールダウンしてからスケールアップすることで実行できます。

$ oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=0
$ oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=1

結果: rbd mirror snapshot schedule status -p ocs-storagecluster-cephblockpool を使用して調べると、DR が有効で、管理対象クラスターでプライマリーとして示されているイメージがミラーリングスケジュールの報告を開始します。

(BZ#2067095)

Ceph が Globalnet によって割り当てられたグローバル IP を認識しない

Ceph は Globalnet によって割り当てられたグローバル IP を認識しないため、Globalnet を使用して重複するサービス CIDR を持つクラスター間で障害復旧ソリューションを設定することはできません。このため、サービス CIDR が重複している場合、障害復旧ソリューションは機能しません。

(BZ#2102397)

ボリュームレプリケーショングループの削除は、削除中に作成された新しいボリュームレプリケーションでスタックします。これは、永続的なボリュームクレームをファイナライザーで更新できないためスタックします。

ディザスターリカバリー (DR) リコンサイラーのバグにより、マネージドクラスターで内部 VolumeReplicaitonGroup リソースの削除中に、ワークロードがフェールオーバーまたは再配置された場所から、persistent volume claim (PVC) が保護されようとします。結果のクリーンアップ操作は完了せず、アプリケーションの DRPlacementControl で PeerReady 状態を報告します。

これにより、アプリケーションはフェイルオーバーまたは再配置され、DRPlacementControl リソースがその PeerReady 状態を false として報告するため、再配置または再フェイルオーバーできなくなります。

回避策: 回避策を適用する前に、VolumeReplicationGroup の削除中に PVC を保護することが原因であるかどうかを次のように判断します。

結果: ハブクラスターの DRPlacementControl は、PeerReady 状態を true として報告し、さらにワークロードの再配置またはフェイルオーバーアクションを有効にします。(BZ#2116605)

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

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

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

(BZ#2114573)

セカンダリークラスターへのフェールオーバー中に、PVC の一部がプライマリークラスターに残る

Kubernetes v1.23 より前の動作では、Kubernetes コントロールプレーンは StatefulSet 用に作成された PVC をクリーンアップしませんでした。これはクラスター管理者または StatefulSet を管理するソフトウェア Operator のままになります。このため、ステートフルセットの PVC は、Pod が削除されたときにそのまま残されていました。これにより、Ramen がアプリケーションを元のクラスターにフェールバックできなくなります。

回避策: ワークロードが StatefulSets を使用している場合は、フェールバックまたは別のクラスターに再配置する前に、次の操作を行います。

結果: ピアクラスターがクリーンアップされ、新しいアクションの準備が整います。(BZ#2118270)

フェイルバック中にアプリケーションが Relocating 状態でスタックする

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

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

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

(BZ#2120201)

ゾーンがダウンしている場合、アプリケーションが FailingOver 状態で停止する

フェイルオーバーまたは再配置時に、どの s3 ストアにも到達できない場合、フェイルオーバーまたは再配置プロセスがハングします。Openshift DR ログが S3 ストアに到達できないことを示している場合、トラブルシューティングを行い、s3 ストアを操作可能にすることで、OpenShift DR はフェイルオーバーまたは再配置操作を続行できます。

(BZ#2121680)

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

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

(BZ#2100920)