第7章 既知の問題

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

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

(BZ#2007376)

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

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

(BZ#2021460)

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

一部のイメージで 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 df が無効な MAX AVAIL 値を報告する

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

(BZ#2100920)

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

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

(BZ#2102397)

両方の 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)

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

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

(BZ#2121680)

ワークロードをピアクラスターにフェイルオーバーまたは再配置すると、フェイルオーバーまたは再配置元のクラスターがクリーンアップされるまで、PeerReady 条件が true に設定される

障害復旧 (DR) アクションを開始した後、ワークロードがピアクラスターにフェイルオーバーまたは再配置される間、PeerReady 条件は最初に true に設定されます。その後、フェイルオーバーまたは再配置元のクラスターは、今後のアクションのためにクリーンアップされるまで、false に設定されます。アクションを実行するために DRPlacementControl ステータス条件を見ているユーザーは、この中間的な PeerReady 状態を見て、ピアの準備ができていると認識し、アクションを実行する可能性があります。この場合、操作は保留中されるか失敗し、回復するためにユーザーの介入が必要になることがあります。

回避策: アクションを実行する前に、Available と PeerReady の両方の状態を調べます。ワークロードの DR 状態を正常にするために、両方が true である必要があります。両方の状態が true のときにアクションを実行すれば、要求された操作が進行します。

(BZ#2138855)

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

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

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

(BZ#2159791)

ブロックリスト登録により Pod がエラー状態で停止することがある

ネットワークの問題、または非常に過負荷/不均衡なクラスターが原因でブロックリスト登録が実行されると、テイルレイテンシーの大きな急増が発生します。このため、Pod が CreateContainerError で停止し、Error: relabel failed /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount: lsetxattr /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount/#ib_16384_0.dblwr: read-only file system というメッセージが表示されます。

回避策: 次の手順に従って、これらの Pod がスケジュールされ、障害が発生しているノードを再起動します。

(BZ#2094320)