Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第6章 既知の問題

このセクションでは、Red Hat OpenShift Data Foundation 4.17 の既知の問題を説明します。

6.1. 障害復旧
リンクのコピー

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

    Red Hat Ceph Storage クラスターのクラッシュルールに複数の "take" ステップがある場合、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#2128860)

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

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

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

    (BZ#2081855)

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

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

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

    (BZ#2159791)

  • 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 で保護されているリソースである場合、エラーは無視できます。

    (BZ-2264445)

  • PeerReady フラグを無効にすると、アクションをフェイルオーバーに変更できなくなります

    DR コントローラーは、必要に応じて完全な調整を実行します。クラスターにアクセスできなくなると、DR コントローラーは健全性チェックを実行します。ワークロードがすでに再配置されている場合、この健全性チェックによりワークロードに関連付けられた PeerReady フラグが無効になり、クラスターがオフラインであるため健全性チェックは完了しません。その結果、無効にされた PeerReady フラグは、アクションを Failover に変更できなくなります。

    回避策: コマンドラインインターフェイスを使用して、PeerReady フラグが無効になっているにもかかわらず、DR アクションをフェイルオーバーに変更します。

    (BZ-2264765)

  • ストレッチクラスター内の 2 つのデータセンター間の接続が失われると、Ceph にアクセスできなくなり、IO が一時停止します。

    2 つのデータセンターが相互の接続を失っても Arbiter ノードに接続されたままの場合は、モニター間で無限の選出が発生するという選出ロジックに不具合があります。その結果、モニターはリーダーを選出できず、Ceph クラスターが使用できなくなります。また、接続が切断されている間は IO が一時停止されます。

    回避策: ゾーンノードを停止して、いずれかのデータゾーンのモニターをシャットダウンします。さらに、存続した mon Pod の接続スコアをリセットすることもできます。

    その結果、モニターがクォーラムを形成できるようになり、Ceph が再び使用可能になり、IOs resume が再開します。

    (Partner BZ#2265992)

  • 交換前のクラスターからの古い Ceph プール ID を使用すると、RBD アプリケーションの再配置に失敗する

    新しいピアクラスターが作成される前に作成されたアプリケーションの場合、ピアクラスターが置き換えられると CSI configmap 内の CephBlockPoolID のマッピングを更新できないため、RBD PVC をマウントできません。

    回避策: 交換されていないピアクラスター上の cephBlockPoolID のマッピングを使用して rook-ceph-csi-mapping-config configmap を更新します。これにより、アプリケーション用の RBD PVC をマウントできるようになります。

    (BZ#2267731)

  • 使用できない管理対象クラスター上のプライマリーワークロードのハブ回復後、lastGroupSyncTime に関する情報が失われる

    以前に管理対象クラスターにフェイルオーバーされたアプリケーションは lastGroupSyncTime を報告しないため、VolumeSynchronizationDelay のアラートがトリガーされます。これは、DRPolicy の一部である ACM ハブとマネージドクラスターが使用できない場合、バックアップから新しい ACM ハブクラスターが再構築されるためです。

    回避策: ワークロードのフェイルオーバー先のマネージドクラスターが使用できない場合でも、残っているマネージドクラスターにフェイルオーバーできます。

    (BZ#2275320)

  • MCO Operator が veleroNamespaceSecretKeyRef と CACertificates フィールドを調整する

    OpenShift Data Foundation Operator がアップグレードされると、Ramen 設定の s3StoreProfiles の下の CACertificates フィールドと veleroNamespaceSecretKeyRef フィールドが失われます。

    回避策: Ramen 設定に CACertificates フィールドと veleroNamespaceSecretKeyRef フィールドのカスタム値がある場合は、アップグレードの実行後にそれらのカスタム値を設定します。

    (BZ#2277941)

  • アップグレード後の token-exchange-agent Pod が不安定である

    以前のデプロイメントリソースが適切にクリーンアップされていないため、マネージドクラスター上の token-exchange-agent Pod が不安定になります。これにより、アプリケーションのフェイルオーバーアクションが失敗する可能性があります。

    回避策: ナレッジベースの記事 "token-exchange-agent" pod on managed cluster is unstable after upgrade to ODF 4.17.0 を参照してください。

    結果: 回避策に従うと、"token-exchange-agent" pod が安定し、フェイルオーバーアクションが期待どおりに機能します。

    (BZ#2293611)

  • 再配置時に MAC 割り当てに失敗したため、virtualmachines.kubevirt.io リソースの復元に失敗する

    仮想マシンを優先クラスターに再配置すると、MAC アドレスが使用できないために再配置を完了できない場合があります。これは、仮想マシンがフェイルオーバークラスターにフェイルオーバーされたときに、優先されるクラスター上で完全に消去されていない場合に発生します。

    ワークロードを再配置する前に、ワークロードが優先されるクラスターから完全に削除されていることを確認します。

    (BZ#2295404)

  • CephFS の再配置が WaitForReadiness で停止する

    DRPC の進行が WaitForReadiness で停止するシナリオがあります。この状態が長期間続く場合は、既知の問題が発生し、Ramen が PlacementDecision を新しいプライマリーに更新できない可能性があります。

    その結果、再配置プロセスは完了せず、ワークロードは新しいプライマリークラスターにデプロイされないままになります。これにより、ユーザーが介入するまで回復が遅れる可能性があります。

    回避策: 新しいプライマリーを指すように PlacementDecision を手動で更新します。

  • PlacementRule を使用するワークロードの場合:

    1. PlacementRule を編集します。 

      $ oc edit placementrule --subresource=status -n [namespace] [name of the placementrule]7
      Copy to Clipboard Toggle word wrap

      以下に例を示します。 

      $ oc edit placementrule --subresource=status -n busybox-workloads-cephfs-2  busybox-placement
      Copy to Clipboard Toggle word wrap

    2. placementrule のステータスに以下を追加します。 

      status:
  decisions:
  - clusterName: [primary cluster name]
    reason: [primary cluster name]
      Copy to Clipboard Toggle word wrap

  • Placement を使用するワークロードの場合:

    1. PlacementRule を編集します。 

      $ oc edit placementdecision --subresource=status -n [namespace] [name of the placementdecision]
      Copy to Clipboard Toggle word wrap

      以下に例を示します。 

      $ oc get placementdecision --subresource=status -n openshift-gitops busybox-3-placement-cephfs-decision-1
      Copy to Clipboard Toggle word wrap

    2. placementrule のステータスに以下を追加します。 

      status:
  decisions:
  - clusterName: [primary cluster name]
    reason: [primary cluster name]
      Copy to Clipboard Toggle word wrap

      その結果、PlacementDecision が更新され、ワークロードがプライマリークラスターにデプロイされます。

      (BZ#2319334)

  • ReplicationDestination リソースがまだ作成されていない場合にフェイルオーバープロセスが失敗する

    LastGroupSyncTime の更新前にユーザーがフェイルオーバーを開始すると、フェイルオーバープロセスが失敗する場合があります。このように失敗すると、ReplicationDestination が存在しないことを示すエラーメッセージが表示されます。

    回避策:

    ハブクラスターの VRG の ManifestWork を編集します。

    マニフェストから次のセクションを削除します。 

    /spec/workload/manifests/0/spec/volsync
    Copy to Clipboard Toggle word wrap

    変更を保存します。

    この回避策を正しく適用すると、VRG は ReplicationDestination リソースを使用した PVC の復元の試行を省略します。PVC がすでに存在する場合、アプリケーションはそれをそのまま使用します。PVC が存在しない場合は、新しい PVC が作成されます。

    (BZ#2283038)

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る