4.13 リリースノート

OpenShift Data Foundation Operator で disableLoadBalancerService フィールドの調整が無視される

以前のリリースでは、OpenShift Data Foundation Operator の調整により、Multicloud Object Gateway (MCG) の disableLoadBalancerService フィールドへの変更はすべてオーバーライドされました。

今回の修正により、disableLoadBalancerService フィールドの調整は OpenShift Data Foundation Operator で無視され、その結果、NooBaa CR のこのフィールドに設定された値は保持され、オーバーライドされません。

(BZ#2186171)

最適化されていないデータベース関連の削除フローのパフォーマンスの向上

以前のバージョンでは、削除時にデータベース関連のフローが最適化されていないと、Multicloud Object Gateway の CPU 使用率が急上昇し、一括削除のシナリオでパフォーマンスが低下していました。たとえば、削除されたオブジェクトバケット要求 (OBC) を再利用します。

今回の修正により、バケットリクレイマープロセスのインデックスが最適化され、データベースクリーナーフローを高速化するために新しいインデックスがデータベースに追加され、オブジェクトのバッチで動作するようにバケットリクレイマーの変更が導入されました。

(BZ#2181535)

エラーを回避するために OpenShift が生成した証明書を MCG 内部フローに使用する

以前のバージョンでは、クライアントの操作に失敗した自己署名証明書が原因で、Multicloud Object Gateway (MCG) の内部フローの一部にエラーが発生していました。これは、MCG コンポーネント間の内部通信で自己署名証明書が使用されることが原因でした。

今回の修正により、OpenShift Container Platform で生成された証明書が MCG コンポーネント間の内部通信に使用されるようになり、内部フローでエラーが発生しなくなりました。

(BZ#2168867)

バイト数のメトリックが Multicloud Object Gateway バケットによって使用される

以前のバージョンでは、Multicloud Object Gateway バケットで使用されるバイト数を表示するメトリックがありませんでした。

今回の修正により、Multicloud Object Gateway バケットによって使用されるバイト数を示す新しいメトリック NooBaa_bucket_used_bytes が追加されます。

(BZ#2168010)

Microsoft Azure Blob ストレージの公開アクセスが無効になっている

以前のリリースでは、Microsoft Azure で作成されたデフォルトのコンテナーはパブリックアクセスが有効になっており、セキュリティーの面で懸念がありました。

今回の修正により、作成されたデフォルトのコンテナーのパブリックアクセスのデフォルト設定が有効化された状態ではなくなっています (AllowBlobPublicAccess は false に設定)。

(BZ#2167821)

レプリケーションルールが設定されている場合でも、Multicloud Object Gateway バケットバケットが削除される

以前のリリースでは、Multicloud Object Gateway バケットにレプリケーションルールが設定されている場合、バケットは削除対象とみなされず、バケットは削除されずに残っていました。今回の修正により、特定のバケットのレプリケーションルールは、バケットが削除されるときに更新されます。その結果、バケットも削除されます。

(BZ#2168788)

データベース init コンテナーの所有権が Kubernetes FSGroup に置き換えられる

以前のリリースでは、MCG データベース (DB) Pod の init コンテナーが所有権の変更に失敗すると、マルチクラウドオブジェクトゲートウェイ (MCG) が起動して機能しなくなっていました。

今回の修正により、DB init コンテナーの所有権が Kubernetes FSGroup に置き換えられます。(BZ#2115616)

cephfs-top が 100 を超えるクライアントを表示できる

以前のリリースでは、100 を超えるクライアントを cephfs-top にロードしようとすると、スペースが少ないか、まったくないために cephfs-top の表示内に収まらず、空白の画面が表示され、ハング状態になることがありました。クライアントは x_coord_map の 計算に基づいて表示されていたため、cephfs-top はディスプレイにこれ以上のクライアントを表示できませんでした。

この問題は、ncurses スクロールとクライアントを表示する新しい方法が cephfs-top に導入されたときに、Ceph の別の BZ の一部として修正されました。x_coord_map の計算も削除されました。そのため、cephfs-top は 200 以上のクライアントを表示するようになりました。

(BZ#2067168)

StagingTargetPath が欠落している場合でも RBD ファイルシステム PVC が拡張される

以前のリリースでは、NodeExpandVolume リモートプロシージャコール (RPC) で StagingTartgetPath が欠落しており、Ceph CSI が拡張するデバイスの詳細を取得できなかった場合、RADOS ブロックデバイス (RBD) ファイルシステム永続ボリューム要求 (PVC) の拡張が成功しませんでした。

今回の修正により、Ceph CSI はすべてのマウント参照を調べて、RBD イメージがマウントされている StageingTargetPath を識別します。その結果、StagingTargetPath が欠落している場合でも、RBD ファイルシステム PVC は正常に拡張されます。

(BZ#2164617)

デフォルトのメモリーと CPU リソースの制限を増加

以前のリリースでは、odf-csi-addons-operator のメモリーリソース制限が低く、その結果 odf-csi-addons-operator Pod が OOMKilled (メモリー不足) になっていました。

今回の修正により、デフォルトのメモリーと CPU リソースの制限が増加し、odf-csi-addons-operator OOMKill は発生しなくなりました。

(BZ#2172365)

セキュアポートとセキュアではないポート向けの 2 つのルート

以前のバージョンでは、openshiftroute の RGW サービスのポートが定義されていなかったため、ルートがセキュアポートを使用することになり、http リクエストの失敗が発生していました。

今回の修正により、既存の OpenShift for RGW のセキュアではないポートが適切に定義され、セキュアなポートが使用されている新しいルートが作成されるため、http リクエストの失敗が回避されます。現在、RGW には 2 つのルートが使用可能です。既存のルートはセキュアでないポートを使用し、新しい別のルートはセキュアなポートを使用します。

(BZ#2104148)

外部モードで Ceph クラスターの正しい状態が反映される

以前のバージョンでは、OpenShift Data Foundation が Ceph クラスターを使用して外部モードでデプロイされている場合、関連付けられている Ceph クラスターが良好な状態であっても、storagecluster ExternalClusterStateConnected などの問題のある状態がストレージクラスターから消去されませんでした。

今回の修正により、Ceph クラスターが良好な状態にある場合は問題のある状態がストレージクラスターから削除され、Ceph クラスターの正しい状態が反映されるようになりました。

(BZ#2172189)

nginx 設定は ConfigMap を通じて追加される

以前のリリースでは、IPv6 がノードのカーネルレベルで無効になっている場合に、odf-console Pod の nginx 設定の IPv6 listen ディレクティブでエラーが発生していました。その結果、OpenShift Data Foundation は odf-console が利用できず、odf-console が CrashLoopBackOff エラーになりました。

今回の修正により、odf-operator で作成された ConfigMapで、nginx 設定がすべて追加されます。

(BZ#2173161)

ユーザーインターフェイスは PVC 名を CR に正しく渡す

以前のリリースでは、ファイルシステムを使用してユーザーインターフェイス (UI) で NamespaceStore を作成するときに、UI は CR の spec.nsfs.pvcName フィールドに渡す必要がある PVC 名だけではなく、永続ボリューム要求 (PVC) オブジェクト全体を CR に渡していました。その結果、UI にエラーが表示されました。

今回の修正により、PVC オブジェクト全体ではなく、PVC 名のみが CR に渡されます。

(BZ#2158922)

OpenShift Data Foundation のアップグレード時に更新ポップアップが表示される

以前のバージョンでは、OpenShift Data Foundation がアップグレードされると、OpenShift Container Platform は変更を認識しないため Refresh ボタンを表示しませんでした。OpenShift は、odf-console Pod に存在する plugin-manifest.json ファイルの version フィールドの変更を把握するためのチェックを実行していませんでした。

今回の修正により、OpenShift Container Platform および OpenShift Data Foundation は、OpenShift Data Foundation ユーザーインターフェイスのマニフェストをポーリングするように設定されます。バージョンの変更に応じて、Refresh ポップアップが表示されます。

(BZ#2157876)

RGW エンドポイントに到達できない場合でも StorageClasses が作成される。以前の OpenShift Data Foundation の外部モードデプロイメントでは、RADOS ゲートウェイ (RGW) エンドポイントに到達できず、Rook が CephObjectStore の設定に失敗した場合に、Python スクリプト (create-external-cluster-resources.py) で密結合されているので RADOS ブロックデバイス (RBD) と CephFS の作成も失敗します。

今回の修正により、Python スクリプトの問題が修正され、失敗したりエラーが表示されたりする代わりに個別の呼び出しが行われ、StorageClasses が作成されます。

(BZ#2139451)

フェイルオーバーアクションは、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

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

ワークロードをピアクラスターにフェイルオーバーまたは再配置すると、フェイルオーバーまたは再配置元のクラスターがクリーンアップされるまで、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.

 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 がスケジュールされ、障害が発生しているノードを再起動します。

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

OpenShift Data Foundation 4.13 を使用した障害復旧ソリューションは、永続ボリューム (PV) データに加えて永続ボリューム要求 (PVC) データを保護および復元します。プライマリークラスターが古い OpenShift Data Foundation バージョン上にあり、ターゲットクラスターが 4.13 に更新されている場合、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"}]'

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

(BZ#2210762)

サブスクリプションベースのワークロードに関連付けられた特定の管理リソースが削除される

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

(BZ#2211643)

ハブの回復後にピアの準備完了ステータスが Unknown と表示される

ゾーン障害とハブの回復後、障害復旧の配置制御 (DRPC) 内のサブスクリプションおよびアプリケーションセットアプリケーションのピア準備完了ステータスが Unknown と表示されることがあります。これは表面上の問題であり、Ramen の通常の機能には影響せず、oc コマンドを使用して表示したときの DRPC 出力の外観に限定されます。

回避策: YAML 出力を使用して、正しいステータスを確認します。

oc get drpc -o yaml

$ oc get drpc -o yaml

(BZ#2211883)

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 が応答しなくなる

arbiter を備えた 2 サイトのストレッチクラスターでは、データゾーン間のネットスプリット中に、Rook Operator が failed to get ceph status というエラーを出力します。これは、ゾーン 1 とゾーン 2、ゾーン 1 と arbiter にネットスプリットが誘導されると、ゾーン 1 が約 20 分間クラスターから切り離されるために発生します。ただし、rook-operator ログにスローされたエラーは関連性がなく、OpenShift Data Foundation は netsplit 状況でも正常に動作することがわかります。

(BZ#2185180)

CephOSDCritallyFull および CephOSDNearFull アラートが期待どおりに起動されない

Ceph が提供するメトリクスで ceph_daemon 値の形式が変更されており、これらのアラートは古い値の形式を使用しているので、CephOSDCritallyFull および CephOSDNearFull のアラートは想定通りに発行されません。

(BZ#2215239)

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

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

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

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

(BZ#2232163)

ハブの復元後に applicationSet ベースのアプリケーションのフェイルオーバーを開始できない

ハブの回復後にプライマリーマネージドクラスターがダウンした場合、最後のアクションが Relocate だった場合は、ユーザーインターフェイス (UI) を使用して applicationSet ベースのアプリケーションのフェイルオーバーをトリガーすることはできません。

回避策: コマンドラインインターフェイス (CLI) からフェイルオーバーをトリガーするには、次のように DRPC.spec.action フィールドを Failover に設定します。

oc edit drpc -n openshift-gitops app-placement-drpc

$ oc edit drpc -n openshift-gitops app-placement-drpc

[...]
spec
  action: Failover
[...]

[...]
spec
  action: Failover
[...]

(BZ#2209288)

トポロジービューが外部モードでは機能しない

外部モードでは、ノードに OCS ラベルが付けられません。その結果、トポロジービューでは最初のレベルのノードを表示できません。

(BZ#2213739)