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

第7章 既知の問題

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

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

  • 整合性グループベースのワークロードの再配置後に同期が停止する

    ボリューム整合性グループが有効になっている CephRBD ボリュームを使用するアプリケーションが実行中で、セカンダリーマネージドクラスターがオフラインになると、これらのボリュームのレプリケーションが無期限に停止する可能性があります。この問題は、セカンダリークラスターがオンラインに戻った後も解決されない可能性があります。

    Volume SynchronizationDelay アラートがトリガーされ、ステータスは最初は Warning、その後 Critical にエスカレートされます。これは、影響を受けるアプリケーションにおけるボリューム整合性グループ内の CephRBD ボリュームのレプリケーションが停止したことを示します。

    回避策: Red Hat サポート にお問い合わせください。

    (DFBUGS-3812)

  • ノードのクラッシュにより kubelet サービスの障害が発生し、Data Foundation がエラー状態になる

    OpenShift クラスターで予期しないノードクラッシュが発生すると、ノードが NotReady 状態でスタックしたままとなり、ストレージクラスターに影響が及ぶ可能性があります。

    回避策:

  • 保留中の CSR を取得します。 

    oc get csr | grep Pending
    Copy to Clipboard Toggle word wrap

  • 保留中の CSR を承認します。 

    Approve the pending CSR
    Copy to Clipboard Toggle word wrap

    (DFBUGS-3636)

  • 4.18 から 4.19 にアップグレードした後、ramen-hub-operator-config に s3StoreProfile がない

    configmap がデフォルト値でオーバーライドされると、Multicluster Orchestrator (MCO) Operator によって追加されたカスタム S3Profiles やその他の詳細は失われます。これは、Ramen-DR ハブ Operator がアップグレードされた後、OLM が既存の ramen-hub-operator-config configmap を Ramen-hub CSV によって提供されるデフォルト値で上書きするために発生します。

    回避策: ハブクラスターで MCO Operator を再起動します。その結果、S3profiles などの必要な値が configmap で更新されます。

    (DFBUGS-3634)

  • それぞれのノードがダウンしている場合、CIDR 範囲は csiaddonsnode オブジェクトに保持されない

    ノードがダウンすると、Classless Inter-Domain Routing (CIDR) 情報が csiaddonsnode オブジェクトから消えます。これは、影響を受けるノードをフェンスする必要がある場合に、フェンシングメカニズムに影響を及ぼします。

    回避策: NetworkFenceClass オブジェクトが作成された直後に CIDR 情報を収集します。

    (DFBUGS-2948)

  • ノードの置き換え後、新しい mon Pod のスケジュールが失敗する

    ノードの置き換え後、新しい mon Pod は新しく追加されたノードでスケジュールを設定できません。その結果、mon pod は Pending 状態のままとなり、mon が使用できない状態で storagecluster のステータスに影響します。

    回避策: 正しい nodeSelector を使用して新しい mon デプロイメントを手動で更新します。

    (DFBUGS-2918)

  • v4.17.z から v4.18 にアップグレードした後、障害復旧が誤って設定されている

    ODF Multicluster Orchestrator および Openshift DR Hub Operator を 4.17.z から 4.18 にアップグレードすると、内部モードのデプロイメントで特定の障害復旧リソースが誤って設定されます。これは ocs-storagecluster-ceph-rbd および ocs-storagecluster-ceph-rbd-virtualization StorageClasses を使用するワークロードの障害復旧に影響します。

    この問題を回避するには、この ナレッジベースの記事 の手順に従ってください。

    (DFBUGS-1804)

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

    Red Hat Ceph Storage クラスターの CRUSH ルールに複数の take ステップがある場合、ceph df レポートには、関連付けられているプールの最大使用可能サイズが誤って表示されます。

    (DFBUGS-1748)

  • DRPC は同じ namespace で作成されたすべての永続ボリューム要求を保護する

    複数の障害復旧 (DR) で保護されたワークロードをホストする namespace において、ハブクラスター上の同じ namespace にある DRPlacementControl リソースが、その spec.pvcSelector フィールドを使ってワークロードごとに永続ボリューム要求 (PVC) を指定および分離していない場合、その DRPlacementControl リソースは namespace 内のすべての PVC を保護します。

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

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

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

    (DFBUGS-1749)

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

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

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

    (DFBUGS-325)

  • Regional-DR CephFS ベースのアプリケーションのフェイルオーバーで、サブスクリプションに関する警告が表示される

    アプリケーションがフェイルオーバーまたは再配置されると、ハブサブスクリプションに "Some resources failed to deploy Use View status YAML link to view the details." というエラーが表示されます。これは、バッキングストレージプロビジョナーとして CephFS を使用し、Red Hat Advanced Cluster Management for Kubernetes (RHACM) サブスクリプションでデプロイし、DR で保護されたアプリケーションの永続ボリューム要求 (PVC) がそれぞれの DR コントローラーにより所有されているためです。

    回避策: サブスクリプションステータスのエラーを修正する回避策はありません。ただし、デプロイに失敗したサブスクリプションリソースをチェックして、それらが PVC であることを確認できます。これにより、他のリソースに問題が発生しないようにします。サブスクリプション内のデプロイに失敗した唯一のリソースが DR で保護されているリソースである場合、エラーは無視できます。

    (DFBUGS-253)

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

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

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

    (DFBUGS-665)

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

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

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

    その結果、Monitor がクォーラムを形成して Ceph が再び利用可能になり、IO が再開します。

    (DFBUGS-425)

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

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

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

    (DFBUGS-527)

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

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

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

    (DFBUGS-376)

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

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

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

    (DFBUGS-440)

  • アップグレード後の 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 が安定し、フェイルオーバーアクションが期待どおりに機能します。

    (DFBUGS-561)

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

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

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

    (BZ#2295404)

  • 整合性グループが有効になっている CephFS アプリケーションの DR を無効にすると、一部のリソースが残ってしまう可能性がある

    整合性グループが有効になっている CephFS アプリケーションの DR を無効にすると、一部のリソースが残される可能性があります。このような場合には、手動でのクリーンアップが必要になる場合があります。

    回避策: 以下の手順に従って、リソースを手動でクリーンアップします。

    1. セカンダリークラスターの場合:

      • ReplicationGroupDestination を手動で削除します。 

        $ oc delete rgd -n <namespace>
        Copy to Clipboard Toggle word wrap

      • 次のリソースが削除されたことを確認します。

        • ReplicationGroupDestination
        • VolumeSnapshot
        • VolumeSnapshotContent
        • ReplicationDestination
        • VolumeReplicationGroup

    2. プライマリークラスターの場合:

      • ReplicationGroupSource を手動で削除します。 

        $ oc delete rgs -n <namespace>
        Copy to Clipboard Toggle word wrap

      • 次のリソースが削除されたことを確認します。

        • ReplicationGroupSource
        • VolumeGroupSnapshot
        • VolumeGroupSnapshotContent
        • VolumeSnapshot
        • VolumeSnapshotContent
        • ReplicationSource

        • VolumeReplicationGroup

          (DFBUGS-2950)

  • CephFS を使用している検出対象アプリケーションの場合、フェイルオーバー後に同期が停止する

    CephFS ベースのワークロードの場合、フェイルオーバーまたは再配置後のある時点で、検出対象アプリケーションの同期が停止することがあります。これは、ReplicationSource ステータスで Permission Denied エラーが報告された場合に発生する可能性があります。

    回避策:

    • 検出対象以外のアプリケーションの場合

      • VolumeSnapshot を削除します。 

        $ oc delete volumesnapshot -n <vrg-namespace> <volumesnapshot-name>
        Copy to Clipboard Toggle word wrap

        スナップショット名は通常、PVC 名で始まり、その後にタイムスタンプが続きます。

      • VolSync ジョブを削除します。 

        $ oc delete job -n <vrg-namespace> <pvc-name>
        Copy to Clipboard Toggle word wrap

        ジョブ名は PVC 名と一致します。

    • 検出対象アプリケーションの場合:

      上記と同じ手順を使用しますが、<namespace> は VRG namespace ではなく、アプリケーションワークロード namespace を指します。

    • 整合性グループを使用するワークロードの場合

      • ReplicationGroupSource を削除します。 

        $ oc delete replicationgroupsource -n <namespace> <name>
        Copy to Clipboard Toggle word wrap

      • その namespace 内のすべての VolSync ジョブを削除します。 

        $ oc delete jobs --all -n <namespace>
        Copy to Clipboard Toggle word wrap

        この場合、<namespace> はワークロードの namespace (検出されたかどうかに関係なく) を参照し、<name> は ReplicationGroupSource リソースの名前を参照します。

        (DFBUGS-2883)

  • 仮想マシンページの検出対象アプリケーションに対して DR の削除オプションは使用できない

    Remove DR オプションは、Virtual machines ページにリストされている検出対象アプリケーションでは使用できません。

    回避策:

    1. 不足しているラベルを DRPlacementControl に追加します。 

      {{oc label drplacementcontrol <drpcname> \
odf.console.selector/resourcetype=virtualmachine \
-n openshift-dr-ops}}
      Copy to Clipboard Toggle word wrap

    2. 仮想マシン名を値として PROTECTED_VMS レシピパラメーターを追加します。 

      {{oc patch drplacementcontrol <drpcname> \
-n openshift-dr-ops \
--type='merge' \
-p '{"spec":{"kubeObjectProtection":{"recipeParameters":{"PROTECTED_VMS":["<vm-name>"]}}}}'}}
      Copy to Clipboard Toggle word wrap

      (DFBUGS-2823)

  • Virtual machines ページで検出対象アプリケーションの DR ステータスが表示されない

    Virtual machines ページにリストされている検出対象アプリケーションの DR Status は表示されません。

    回避策:

    1. 不足しているラベルを DRPlacementControl に追加します。 

      {{oc label drplacementcontrol <drpcname> \
odf.console.selector/resourcetype=virtualmachine \
-n openshift-dr-ops}}
      Copy to Clipboard Toggle word wrap

    2. 仮想マシン名を値として PROTECTED_VMS レシピパラメーターを追加します。 

      {{oc patch drplacementcontrol <drpcname> \
-n openshift-dr-ops \
--type='merge' \
-p '{"spec":{"kubeObjectProtection":{"recipeParameters":{"PROTECTED_VMS":["<vm-name>"]}}}}'}}
      Copy to Clipboard Toggle word wrap

      (DFBUGS-2822)

  • フェイルオーバー後に PVC が選択解除されると、セカンダリー VRG 内の古いエントリーがクリーンアップされず、後続の再配置が失敗する

    ワークロードのフェイルオーバー後に PVC が選択解除され、その後に preferredCluster への再配置操作が実行された場合、古い PVC が引き続き VRG に報告される可能性があります。その結果、DRPC は Protected 状態を False として報告し、次のようなメッセージが表示される場合があります。

    VolumeReplicationGroup (/) on cluster is not reporting any lastGroupSyncTime as primary, retrying till status is met.

    回避策:

    この問題を解決するには、古い PVC (つまり、フェイルオーバー後に選択解除されたもの) を VRG ステータスから手動でクリーンアップします。

    1. フェイルオーバー後に選択解除され、保護の対象ではなくなった古い PVC を特定します。

    2. <managed-cluster-name> という名前の ManagedCluster の VRG ステータスを編集します。 

      $ oc edit --subresource=status -n <vrg-namespace> <vrg-name>
      Copy to Clipboard Toggle word wrap

    3. status.protectedPVCs セクションから古い PVC エントリーを削除します。

      古いエントリーが削除されると、DRPC は回復し、健全であると報告されます。

      (DFBUGS-2932)

  • 検出対象アプリケーションの DR 保護が削除されても、セカンダリー PVC が削除されない

    セカンダリークラスターでは、ワークロードにリンクされた CephFS PVC は通常、VolumeReplicationGroup (VRG) によって管理されます。ただし、検出対象アプリケーション機能を使用してワークロードが検出されると、関連付けられた CephFS PVC は VRG 所有としてマークされません。その結果、ワークロードが無効になっている場合、これらの PVC は自動的にクリーンアップされず、孤立してしまいます。

    回避策: 検出対象ワークロードの DR 保護を無効にした後、孤立した CephFS PVC をクリーンアップするには、次のコマンドを使用して手動で削除します。 

    $ oc delete pvc <pvc-name> -n <pvc-namespace>
    Copy to Clipboard Toggle word wrap

    (DFBUGS-2827)

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

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

    回避策:

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

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

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

    変更を保存します。

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

    (DFBUGS-632)

  • クラスターに容量を追加した後、Ceph が警告状態になる

    デバイスの交換または容量の追加後、Ceph が HEALTH_WARN 状態になり、mon が遅い操作を報告していることが観察されます。ただし、クラスターのユーザービリティーには影響しません。

    (DFBUGS-1273)

  • 追加容量時に OSD Pod が再起動する

    クラスターに容量を追加してクラスター拡張を実行した後、OSD Pod が再起動します。ただし、Pod の再起動以外にクラスターへの影響は確認されません。

    (DFBUGS-1426)

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat