OpenShift Container Storage is now OpenShift Data Foundation starting with version 4.9.
第7章 既知の問題
このセクションでは、Red Hat OpenShift Data Foundation 4.11 の既知の問題について説明します。
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
のコマンドを実行します。
フェイルオーバーアクションは、RPC エラー still in use を表示し、Pod で失敗した RADOS ブロックデバイスのイメージマウントを報告します。
障害復旧 (DR) で保護されるワークロードをフェイルオーバーすると、フェールオーバーしたクラスター上のボリュームを使用している Pod が、RADOS ブロックデバイス (RBD) イメージがまだ使用中であることを報告する時に停止する可能性があります。これにより、Pod が長時間 (最大数時間) 起動できなくなります。
フェイルオーバーアクションは、RPC エラー fsck を表示し、Pod で失敗した RADOS ブロックデバイスのイメージマウントを報告する。
障害復旧 (DR) で保護されるワークロードをフェイルオーバーすると、ボリュームにファイルシステムの整合性チェック (fsck) エラーがあると示すボリュームマウントエラーにより、Pod が起動しない可能性があります。これにより、ワークロードはフェイルオーバークラスターにフェイルオーバーできなくなります。
各アクションの数分以内にフェイルオーバーと再配置が実行されると、再配置が失敗します
PeerReady
条件ステータスがTRUE
になる前に、ユーザーがあるクラスターから別のクラスターへのアプリケーションの再配置を開始すると、DRPC YAML ファイルを介して、または次のoc
コマンドを実行することによって、条件ステータスが表示されます。oc get drpc -o yaml -n <application-namespace>
$ oc get drpc -o yaml -n <application-namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <application-namespace>
は、アプリケーションをデプロイするためのワークロードが存在する名前空間です。ピア (ターゲットクラスター) がクリーンな状態になる前に再配置が開始された場合、再配置は永久に停止します。
回避策: DRPC
.Spec.Action
をFailover
に戻し、PeerReady
条件ステータスが TRUE になるまで待ちます。回避策を適用した後、アクションを 再配置 に変更すると、再配置が有効になります。
ユーザーは、DR ポリシーの作成中に同期スケジュールとして値を 0 分に設定でき、レプリケーションポリシーとして同期を報告し、地域の DR セットアップで検証されます。
DRPolicyList
ページは、sync
間隔の値を使用してレプリケーションタイプを表示します。ゼロに設定されている場合、レプリケーションタイプは、メトロクラスターと地域クラスターの同期 (同期) と見なされます。この問題はユーザーを混乱させます。これは、ユーザーインターフェイスにAsync
スケジューリングタイプとして表示されている場合でも、バックエンドがSync
を考慮しているためです。回避策:
sync
またはasync
を決定するには、DRCluster CR ステータスから CephFsid
をフェッチする必要があります。
アプリケーションを削除すると、Pod は削除されますが、PVC は削除されません
RHACM コンソールからアプリケーションを削除しても、DRPC は削除されません。DRPC を削除しないと、VRG だけでなく VRG も削除されません。VRG/VR が削除されない場合、PVC ファイナライザーリストがクリーンアップされず、PVC が
Terminating
状態のままになります。回避策: 次のコマンドを使用して、ハブクラスターの DRPC を手動で削除します
oc delete drpc <name> -n <namespace>
$ oc delete drpc <name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果:
- DRPC は VRG を削除します
- VRG は VR を削除します
- VR が PVC のファイナライザーリストからファイナライザーを削除します。
- VRG が PVC のファイナライザーリストからファイナライザーを削除します。
両方の 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 リソースによって管理されなくなり、操作およびデータの不整合は発生しません。
一部のイメージで 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
$ oc -n openshift-storage scale deployments/rook-ceph-mgr-a --replicas=0 $ oc -n openshift-storage scale deployments/rook-ceph-mgr-a --replicas=1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果:
rbd mirror snapshot schedule status -p ocs-storagecluster-cephblockpool
を使用して調べると、DR が有効で、管理対象クラスターでプライマリーとして示されているイメージがミラーリングスケジュールの報告を開始します。
Ceph が Globalnet によって割り当てられたグローバル IP を認識しない
Ceph は Globalnet によって割り当てられたグローバル IP を認識しないため、Globalnet を使用して重複するサービス CIDR を持つクラスター間で障害復旧ソリューションを設定することはできません。このため、サービス
CIDR
が重複している場合、障害復旧ソリューションは機能しません。
ボリュームレプリケーショングループの削除は、削除中に作成された新しいボリュームレプリケーションでスタックします。これは、永続的なボリュームクレームをファイナライザーで更新できないためスタックします。
ディザスターリカバリー (DR) リコンサイラーのバグにより、マネージドクラスターで内部
VolumeReplicaitonGroup
リソースの削除中に、ワークロードがフェールオーバーまたは再配置された場所から、persistent volume claim (PVC) が保護されようとします。結果のクリーンアップ操作は完了せず、アプリケーションのDRPlacementControl
でPeerReady
状態を報告します。これにより、アプリケーションはフェイルオーバーまたは再配置され、
DRPlacementControl
リソースがそのPeerReady
状態をfalse
として報告するため、再配置または再フェイルオーバーできなくなります。回避策: 回避策を適用する前に、
VolumeReplicationGroup
の削除中に PVC を保護することが原因であるかどうかを次のように判断します。再配置またはフェイルオーバー元のマネージドクラスターのワークロード名前空間にある
VolumeReplicationGroup
リソースに、次の値があることを確認します。-
VRG
metadata.deletionTimestamp
がnon-zero
です -
VRG
spec.replicationState
はSecondary
です
-
VRG
上記のようにワークロード名前空間の
VolumeReplication
リソースを一覧表示し、リソースに次の値があることを確認します。-
metadata.generation
は1
に設定されています -
spec.replicationState
はセカンダリー
に設定されています - VolumeReplication リソースがステータスを報告しない
-
-
上記の状態の VolumeReplication リソースごとに、対応する PVC リソース (VR
spec.dataSource
フィールドに表示される) の値は、non-zero
としてのmetadata.deletionTimestamp
が必要です。 復元するには、ファイナライザーを削除します。
-
VRG リソースからの
volumereplicationgroups.ramendr.openshift.io/vrg-protection
-
それぞれの PVC リソースからの
volumereplicationgroups.ramendr.openshift.io/pvc-vr-protection
-
VRG リソースからの
結果: ハブクラスターの
DRPlacementControl
は、PeerReady
状態をtrue
として報告し、さらにワークロードの再配置またはフェイルオーバーアクションを有効にします。(BZ#2116605)
MongoDB Pod は、
cephrbd
ボリュームのデータを読み取る許可エラーのため、CrashLoopBackoff
になっています異なるマネージドクラスターにまたがる Openshift プロジェクトには、異なるセキュリティーコンテキスト制約 (SCC) があり、特に指定された UID 範囲および/または
FSGroups
が異なります。これにより、特定のワークロード Pod とコンテナーが、ログ内のファイルシステムアクセスエラーが原因で、これらのプロジェクト内でポストフェールオーバーまたは再配置操作を開始できなくなります。回避策: ワークロードプロジェクトが同じプロジェクトレベルの SCC ラベルを持つすべてのマネージドクラスターで作成されていることを確認し、フェイルオーバーまたは再配置時に同じファイルシステムコンテキストを使用できるようにします。Pod は、ファイルシステム関連のアクセスエラーで DR 後のアクションに失敗しなくなりました。
セカンダリークラスターへのフェールオーバー中に、PVC の一部がプライマリークラスターに残る
Kubernetes v1.23 より前の動作では、Kubernetes コントロールプレーンは StatefulSet 用に作成された PVC をクリーンアップしませんでした。これはクラスター管理者または StatefulSet を管理するソフトウェア Operator のままになります。このため、ステートフルセットの PVC は、Pod が削除されたときにそのまま残されていました。これにより、Ramen がアプリケーションを元のクラスターにフェールバックできなくなります。
回避策: ワークロードが StatefulSets を使用している場合は、フェールバックまたは別のクラスターに再配置する前に、次の操作を行います。
-
oc get drpc -n <namespace> -o wide
実行します。 PeerReady 列に TRUE が表示されている場合は、フェールバックまたは再配置を続行できます。それ以外の場合は、ピアクラスターで次の操作を行います。
-
oc get pvc -n <namespace>
を実行します。 -
StatefulSet に属する名前空間のバインドされた PVC ごとに、
oc delete pvc <pvcname> -n namespace
を実行します。 - すべての PVC が削除されると、ボリュームレプリケーショングループ (VRG) はセカンダリーに移行してから削除されます。
-
-
次のコマンド
oc get drpc -n <namespace> -o wide
を再度実行します。数秒から数分後、PeerReady 列がTRUE
に変わります。その後、フォールバックまたは再配置を続行できます。
結果: ピアクラスターがクリーンアップされ、新しいアクションの準備が整います。(BZ#2118270)
-
フェイルバック中にアプリケーションが Relocating 状態でスタックする
マルチクラウドオブジェクトゲートウェイでは、同じ名前または名前空間の複数の永続ボリューム (PV) オブジェクトを同じパスの S3 ストアに追加できました。これにより、同一の
claimRef
を指す複数のバージョンが検出されたため、Ramen は PV を復元しません。回避策: S3 CLI または同等の機能を使用して、重複する PV オブジェクトを S3 ストアからクリーンアップします。タイムスタンプがフェールオーバーまたは再配置の時刻に近いものだけを保持します。
結果: 復元操作が完了し、フェイルオーバーまたは再配置操作が次のステップに進みます。
ゾーンがダウンしている場合、アプリケーションが FailingOver 状態で停止する
フェイルオーバーまたは再配置時に、どの s3 ストアにも到達できない場合、フェイルオーバーまたは再配置プロセスがハングします。Openshift DR ログが S3 ストアに到達できないことを示している場合、トラブルシューティングを行い、s3 ストアを操作可能にすることで、OpenShift DR はフェイルオーバーまたは再配置操作を続行できます。
クラスターがストレッチモードの場合、ceph
df
が無効な MAX AVAIL 値を報告するRed Hat Ceph Storage クラスターのクラッシュルールに複数の実行ステップがある場合、
ceph df
レポートは、マップの使用可能な最大サイズを間違って表示します。この問題は、今後のリリースで修正される予定です。