4.14 リリースノート

ブロックリストに登録しても 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)

Ceph は Globalnet によって割り当てられたグローバル IP を認識するようになりました

以前のリリースでは、Ceph は Globalnet によって割り当てられたグローバル IP を認識しなかったため、Globalnet を使用して重複するサービス CIDR を持つクラスター間で Disaster Recovery ソリューションを設定できませんでした。この問題は修正され、サービス CIDR が重複した場合に Disaster Recovery ソリューションが機能するようになりました。

(BZ#2104971)

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

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

今回の修正により、クラスターがクリーンアップされるまで、失敗したワークロードまたは再配置されたワークロードで PeerReady 状態が true に設定されなくなり、ユーザーが混乱しなくてすみます。

(BZ#2138855)

災害後に ACM ハブが回復されたときに、アプリケーションがクリーンアップ状態に留まらなくなりました

以前のリリースでは、災害時に ACM ハブが失われ、バックアップを使用して復元された場合、VRG ManifestWork および DRPC ステータスは復元されませんでした。これにより、アプリケーションはクリーンアップ状態のままになりました。

今回の修正により、Ramen は VRG ManifestWork が ACM バックアップの一部であることを確認し、ハブの回復後に DRPC ステータスが空の場合に DRPC ステータスを再構築して、アプリケーションがフェイルオーバークラスターに正常に移行するようになりました。

(BZ#2162469)

STS ベースのアプリケーションを期待どおりに再配置できるようになりました

以前のリリースでは、STS ベースのアプリケーションの再配置は、根本的なバグにより失敗していました。このバグは修正され、STS ベースのアプリケーションの再配置が期待どおりに機能するようになりました。

(BZ#2224325)

ハブ復旧後に Ramen が想定どおりに調整されます

以前のリリースでは、アクティブ/パッシブのハブ Metro-DR 設定を使用している場合、Ramen リコンサイラーが許容されるレート制限パラメーターを超えた後に実行を停止するという状況が発生することがまれにありました。調整は各ワークロードに固有であるため、そのワークロードのみが影響を受けました。このような場合、Ramen Pod が再起動するまで、そのワークロードに関連するすべての障害復旧オーケストレーションアクティビティーが停止していました。

この問題は修正され、Ramen はハブの復元後に想定どおりに調整されるようになりました。

(BZ#2175201)

ハブの回復中に管理対象リソースが削除されなくなりました

以前は、ハブのリカバリー中に、OpenShift Data Foundation で Red Hat Advanced Cluster Management バージョン 2.7.4 (またはそれ以降) の既知の問題が発生し、サブスクリプションベースのワークロードに関連付けられた特定のマネージドリソースが意図せず削除される可能性がありました。

この問題は修正されており、ハブの回復中に管理リソースは削除されなくなりました。

(BZ#2211643)

仮想ホストスタイルが NooBaa バケットで利用可能になりました

以前のバージョンでは、NooBaa エンドポイントとコアが DNS 設定のポートを認識していなかったため、仮想ホストスタイルは NooBaa バケットでは機能しませんでした。

今回の更新により、NooBaa Operator は DNS のポートをコアおよびエンドポイントに渡して、Virtual-host スタイルを利用できるようになりました。

(BZ#2183092)

ダミーの認証情報がログに出力されなくなりました

以前のリリースでは、ダミーの認証情報がログに出力され、混乱を招く可能性がありました。このバグは修正され、認証情報が出力されなくなりました。

(BZ#2189866)

NooBaa は、制限時間内に認証情報が提供されない場合、pv-pool タイプのバッキングストアの使用にフォールバックするようになりました。

NooBaa のインストール前などに、クラウド認証情報のリクエストが作成されてから、クラウド認証情報 Operator はシークレットを提供できない、または提供に失敗すると、クラウド認証情報 Operator モードが手動モードに設定され、必要な追加アクションが実行されませんでした。提供されるシークレットには、デフォルトのバッキングストアのターゲットバケットの作成に必要な認証情報が含まれます。これは、デフォルトのバッキングストアが作成されておらず、Noabaa が設定段階でスタックしていることを意味します。

この修正により、クラウド認証情報リクエストが送信され、定義された制限時間 (10 分) 内にシークレットを取得できなかった場合、NooBaa は pv-pool タイプのバッキングストアの使用にフォールバックします。つまり、システムのステータスが Ready であり、デフォルトのバッキングストアのタイプが pv-pool である必要があります。

(BZ#2242854)

Postgresql DB パスワードがコアログとエンドポイントログにクリアテキストで表示されなくなりました

以前のリリースでは、noabaa-core の内部 Postgresql クライアントは接続パラメーターオブジェクトをログに出力し、このオブジェクトには Postgresql DB に接続するためのパスワードが含まれていました。

今回の修正により、ログに出力される接続オブジェクトからパスワード情報が省略され、ログへのメッセージには機密性のない接続の詳細のみが含まれます。

(BZ#2240778)

CSI CephFS および RBD ホルダー Pod はアップグレード後に古い cephcsi イメージを使用しなくなります

以前のリリースでは、CSI CephFS および RBD ホルダー Pod は古い cephcsi イメージを使用していたため、アップグレード後に更新されませんでした。

今回の修正により、CSI CephFS および RBD ホルダーの daemonset オブジェクトもアップグレードされ、CSI ホルダー Pod は最新の cephcsi イメージを使用するようになりました。

(BZ#2219536)

再起動プロセスの信頼性が向上し、制御されるようになりました

以前のリリースでは、resync コマンドが効果的にトリガーされず、同期の問題が発生し、イメージミラーリングを無効にできなくなりました。これは、CephCSI が resync コマンドを発行するためにイメージミラーの状態に依存しており、状態が予測できず変化し、信頼性が低くなっていたことが理由です。

この修正により、ボリュームが降格されるときに、CephCSI はイメージ作成のタイムスタンプを保存します。resync コマンドが発行されると、CephCSI は保存されたタイムスタンプと現在の作成タイムスタンプを比較し、タイムスタンプが一致する場合にのみresync が続行されます。また、CephCSI はイメージの状態と最後のスナップショットのタイムスタンプを調べて、再同期が必要かどうか、またはエラーメッセージを表示する必要があるかどうかを判断します。これにより、より信頼性が高く、再同期プロセスを制御できます。

(BZ#2165941)

S3 クライアントが同じゾーン内の RGW と通信できないため、不必要なネットワーク遅延がなくなりました。

以前のリリースでは、Ceph オブジェクトストアを使用し、別のゾーンへの転送をリクエストしているときに、S3 クライアントが同じゾーン内の RGW と通信できなかったため、不要なネットワーク遅延が発生していました。

今回の修正により、リクエストが同じゾーン内の RGW サーバーにルーティングされるように、アノテーション service.kubernetes.io/topology-mode が RGW サービスに追加されます。その結果、Pod は最も近い RGW サービスにルーティングされます。

BZ#977778

ボリューム種別のドロップダウンがユーザーインターフェイスから削除されました

以前のリリースでは、OpenShift Data Foundation の内部インストールでディスクが SSD であると想定されていたとしても、ユーザーインターフェイスには既存のクラスターのボリューム種別ドロップダウンに HDD、SSD、またはその両方が表示されていました。

この修正により、ボリューム種別のドロップダウンがユーザーインターフェイスから削除され、想定として常に SSD が使用されるようになりました。

(BZ#2239622)

OpenShift Data Foundation トポロジー rook-ceph-operator デプロイメントで正しいリソースが表示されるようになりました

以前は、CSI Pod およびその他の Pod の所有者参照が rook-ceph-operator に設定されていたため、マッピングではこれらの Pod もデプロイメントの一部として表示されていました。

今回の修正により、Pod のマッピングアプローチが上から下ではなく、下から上方向に変更され、デプロイメントに関連する Pod のみが表示されるようになります。

(BZ#2209251)

CSS プロパティーは、ウィンドウサイズの変化に合わせてリソースリストの高さを動的に調整するように設定されます

以前のリリースでは、CSS プロパティーがサイドバーに適切に適用されなかったため、トポロジービューのリソースリストのサイドバーはウィンドウサイズに基づいて長さが調整されませんでした。

今回の修正により、リソースリストの高さを動的に調整するように CSS プロパティーは、全画面モードと通常画面モードの両方でウィンドウサイズの変更に動的に調整されるようになりました。

(BZ#2209258)

LSO からデフォルトのストレージクラスに移行するときに、容量の追加操作が失敗しなくなりました

以前のリリースでは、LSO からデフォルトのストレージクラスに移動するときに、拡張用の永続ボリューム (PV) が正しく作成されなかったため、容量の追加操作が失敗していました。

今回の修正により、LSO ベースのストレージクラスを使用してストレージクラスターが最初に作成される場合に、LSO 以外のストレージクラスを使用した容量の追加操作は使用できなくなります。

(BZ#2213183)

OpenShift Data Foundation トポロジーのリソース使用率がメトリクスと一致するようになりました

以前のリリースでは、ノードとデプロイメントのリソースリストのサイドバーで使用されるメトリクスクエリーが異なっていたため、OpenShift Data Foundation トポロジーのリソース使用率はメトリクスと一致しませんでした。

この修正により、メトリクスクエリーが同じになり、その結果、両方の場所で値が同じになります。

(BZ#2214033)

外部モードのトポロジービューが無効になりました

以前のリリースでは、トポロジービューで外部モードがサポートされていないため、トポロジービューに空白の画面が表示されていました。

今回の修正により、外部モードが無効になり、空白の画面の代わりにメッセージが表示されるようになりました。

(BZ#2216707)

トポロジーにはすべてのノードで rook-ceph-operator が表示されなくなりました

以前は、Rook-Ceph Operator のデプロイメントが実際には関連していない複数の Pod の所有者であるため、トポロジービューではすべてのノードに Rook-Ceph Operator のデプロイメントが表示されていました。

この修正により、トポロジービューのノードへのデプロイメントのマッピングメカニズムが変更され、その結果、Rook-Ceph Operator のデプロイメントが 1 つのノードにのみ表示されます。

(BZ#2233027)

コンソールのユーザーインターフェイスに OVN ではなく SDN が表示されなくなりました

以前のバージョンでは、OpenShift Container Platform が SDN から OVN に移行したにもかかわらず、コンソールのユーザーインターフェイスには OVN ではなく SDN が表示されていました。

今回の修正により、テキストが SDN から OVN に変更され、その結果、ネットワーク管理のテキストに OVN が表示されるようになりました。

(BZ#2233731)

リソース名は、小文字または数字で始まり、小文字で終わるというルールに従う必要があります。ルールに従わない場合は正規表現でエラーが返されます

以前のリリースでは、オブジェクトバケットクレーム (OBC)、バッキングストア、ブロッキングプール、namespace ストア、およびバケットクラスの入力名の正規表現検証が無効であったため、名前の最初に記号または大文字が使用されている場合、"starts and ends with a lowercase letter or number" のルールに違反していました。

今回のリリースでは、この問題は修正されており、リソース名が小文字または数字で始まり小文字で終わるというルールに従っていない場合、正規表現はエラーを返します。

(BZ#2193109)

ODF モニタリングでメトリクス値が欠落することがなくなりました

以前のリリースでは、ceph-exporter のサービスモニター用のポートが欠落していました。これは、Ceph デーモンのパフォーマンスメトリクスが欠落していることを意味します。

今回の修正により、ceph-exporter サービスモニターのポートが追加され、Ceph デーモンのパフォーマンスメトリクスが prometheus で表示されるようになりました。

(BZ#2221488)

ネットワークの問題がある場合の OSD Pod はフラッピングを継続しなくなりました

以前のリリースでは、ネットワークの問題により OSD Pod がフラッピングを開始すると、フラッピングが継続していました。これはシステムに悪影響を及ぼす可能性があります。

今回の修正により、フラッピング OSD Pod は一定時間後に down とマークされ、システムに影響を与えなくなりました。

(BZ#2223959)

MDS が不必要に再起動されなくなりました

以前は、liveness プローブが ceph fs dump をチェックせずに MDS を再起動したため、MDS Pod が不必要に再起動されました。

今回の修正により、liveness プローブは ceph fs dump 内の MDS を監視し、ダンプ出力に MDS が見つからなかった場合にのみ MDS を再起動します。

BZ#977778

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

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

(BZ#2007376)

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

クラスターがストレッチモードの場合、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#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)

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

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

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

(BZ#2159791)

マネージドクラスターが OpenShift Container Platform と OpenShift Data Foundation の異なるバージョン上にある場合、アプリケーションのフェイルオーバーが Failover 状態でハングする

OpenShift Data Foundation 4.14 を使用した障害復旧ソリューションは、永続ボリューム (PV) データに加えて永続ボリューム要求 (PVC) データを保護および復元します。プライマリークラスターが古い OpenShift Data Foundation バージョン上にあり、ターゲットクラスターが 4.14 に更新されている場合、S3 ストアに PVC データがないため、フェイルオーバーが停止します。

回避策: Disaster Recovery クラスターをアップグレードする場合は、最初にプライマリークラスターをアップグレードしてから、アップグレード後の手順を実行する必要があります。

(BZ#2214306)

DRPolicy が同じ namespace 内の複数のアプリケーションに適用されると、ボリュームレプリケーショングループが作成されない

namespace 内の他のアプリケーションと同じ場所に配置されているアプリケーション用に DRPlacementControl (DRPC) が作成される場合、DRPC にはアプリケーション用のラベルセレクターセットがありません。その後ラベルセレクターに変更が加えられた場合、OpenShift Data Foundation Hub コントローラーの検証アドミッション Webhook は変更を拒否します。

回避策: アドミッション Webhook がそのような変更を許可するように変更されるまでは、DRPC validatingwebhookconfigurations にパッチを適用して Webhook を削除できます。

$ oc patch validatingwebhookconfigurations vdrplacementcontrol.kb.io-lq2kz --type=json --patch='[{"op": "remove", "path": "/webhooks"}]'

(BZ#2210762)

c1 クラスターから c2 クラスターへのアプリのフェイルオーバーがフェイルオーバーでハングする

S3 ストアの設定ミスによりデータが S3 ストアにアップロードされない場合でも、Ramen は、フェイルオーバーアクションを無効にしないので、フェイルオーバー中にフェイルオーバークラスターでクラスターデータが利用できません。そのため、フェイルオーバーを完了できません。

回避策: 初期デプロイ後に Ramen ログを調べて、s3 設定エラーが報告されていないことを確認します。

$ oc get drpc -o yaml

(BZ#2248723)

ハブ復旧後のデータ損失の潜在的なリスク

孤立したリソースをクリーンアップするように設計されたエビクションルーチンにより、ハブの回復後に潜在的なデータ損失のリスクが存在します。このルーチンは、コレクション用の対応する ManifestWorks が欠如している AppliedManifestWorks インスタンスを識別し、マークします。1 時間のハードコーディングされた猶予期間が提供されます。この期間が経過すると、AppliedManifestWork に関連付けられたすべてのリソースがガベージコレクションの対象になります。

ハブクラスターが最初の 1 時間以内に対応する ManifestWorks を再生成できなかった場合は、データ損失が発生する可能性があります。これは、データ損失のリスクを最小限に抑えるために、ManifestWorks の ハブ後のリカバリーの再作成を妨げる可能性がある問題に迅速に対処することの重要性を強調しています。

(BZ-2252933)

CephFS でのストレッチクラスターのパフォーマンスが低下する

マルチサイトの Data Foundation クラスターにメタデータサーバー (MDS) を任意に配置するため、小さなメタデータ操作が多数あるワークロードでは、パフォーマンスが低下する可能性があります。

(BZ#1982116)

非常に多くのファイルによる SELinux の再ラベル付けの問題

Red Hat OpenShift Container Platform でボリュームを Pod にアタッチすると、Pod が起動しないか、起動に過度に時間がかかることがあります。この動作は一般的なもので、Kubelet による SELinux の再ラベル付けの処理方法に関係しています。この問題は、ファイル数が非常に多いファイルシステムベースのボリュームで発生します。OpenShift Data Foundation では、非常に多くのファイルがある CephFS ベースのボリュームを使用すると、この問題が発生します。この問題の回避にはさまざまな方法があります。ビジネスニーズに応じて、ナレッジベースソリューション https://access.redhat.com/solutions/6221251 から回避策の 1 つを選択できます。

(Jira#3327)

クラッシュまたはシャットダウンテストの実行後、Ceph にアクセスできなくなります

ストレッチクラスターでは、モニターが復活し、他のモニターが MonitorMap や OSDMap などの最新情報を受信するためのプローブ段階にある場合に、プローブ段階では stretch_mode に入ることができません。これにより、elector の disallowed_leaders リストを正しく設定できなくなります。

復活したモニターのスコアが実際に一番高いと仮定すると、現在の選出でリーダーに最適であると認識し、自身がリーダーに適していると提案し、生存しているモニターにより disallowed_leaders リストをもとに拒否され続けるため、モニターの選出フェーズを停止させる原因になります。これにより、モニターが選択中に停止し、最終的に Ceph が応答しなくなります。

この問題を回避するには、選択中にスタックして Ceph が応答しなくなったときに、次のコマンドを使用して各モニターの接続スコアをリセットします。

`ceph daemon mon.{name} connection scores reset`

これが機能しない場合は、モニターを 1 つずつ再起動します。その後、選出の停滞が解消され、モニターがリーダーを選出して定足数を形成できるようになり、Ceph は再び応答できるようになります。

(BZ#2241937)

Ceph がワークロードのデプロイ後に アクティブなマネージャーを報告しません

ワークロードのデプロイメント後に、Ceph マネージャーは MON への接続を失うか、liveness プローブに応答できなくなります。

これが原因で、ODF クラスターのステータスがアクティブなマネージャーが存在しないと報告し、また、Ceph マネージャーを使用してリクエスト処理を行う複数の操作が失敗します。たとえば、ボリュームのプロビジョニング、CephFS スナップショットの作成などです。

ODF クラスターのステータスを確認するには、コマンド oc get cephcluster -n openshift-storage を使用します。クラスターにこの問題がある場合、ステータス出力の status.ceph.details.MGR_DOWN フィールドに "no active mgr" というメッセージが表示されます。

この問題を回避するには、以下のコマンドを使用して Ceph Manager Pod を再起動します。

# oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=0

# oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=1

これらのコマンドを実行すると、ODF クラスターのステータスは正常なクラスターを報告し、MGR_DOWN に関する警告やエラーは表示されません。

(BZ#2244873)

StorageCluster でカスタム deviceClass が使用されている場合に CephBlockPool の作成が失敗します

既知の問題により、StorageCluster でカスタム deviceClass が使用されると、CephBlockPool の作成に失敗します。

(BZ#2248487)

スナップショットの自動フラット化が機能しない

一般的な親 RBD PVC が 1 つあり、ボリュームスナップショット、復元、およびスナップショットが 450 回以上連続して実行する場合は、ボリュームスナップショットまたは共通の親 RBD PVC のクローンを取得することはできません。

この問題を回避するには、順番にボリュームスナップショット、復元、および削除を行う代わりに、PVC を使用して PVC のクローンを作成することで、この問題を完全に回避できます。

この問題が発生した場合は、カスタマーサポートに連絡して、最終復元 PVC の手動フラット化を実行し、共通の親 PVC のボリュームスナップショットまたはクローンを再度取得してください。

(BZ#2232163)

NodeStageVolume RPC 呼び出しが見つからないため、新しい Pod が実行状態にならないようにブロックされます

NodeStageVolume RPC 呼び出しが発行されていないため、一部の Pod が Running 状態になりません。新規 Pod は永久に Pending で停止します。

この問題を回避するには、影響を受けるすべての Pod を一度にスケールダウンするか、ノードを再起動します。回避策を適用した後、すべての Pod が Running 状態になるはずです。

(BZ#2244353)

バックアップでデータの転送に失敗します

状況によっては、バックアップがデータの転送に失敗し、スナップショット PVC が保留状態のままになることがあります。

(BZ#2248117)