4.11 リリースノート

リージョンディザスターリカバリー (Regional-DR)

地域 DR ソリューションは、ブロックボリュームの自動保護、非同期レプリケーションを提供し、地理的な場所で災害が発生したときにビジネス機能を保護します。パブリッククラウドでは、これはリージョン障害からの保護に似ています。

詳細については、計画ガイド および OpenShift Data Foundation ガイドの Regional-DR ソリューション を参照してください。

大都市災害復旧 (Metro-DR)

Metro-DR ソリューションは、複数のクラスターの同期レプリケーションを使用しながら、データを損失することなく、データセンターが使用できなくなったときに保護とビジネスの継続性を確保します。パブリッククラウドでは、これらはアベイラビリティゾーンの障害からの保護に似ています。ほぼゼロの RPO で、ビジネス機能を即座に保護します。

詳細は、計画ガイド および OpenShift Data Foundation ガイドの Metro-DR ソリューション を参照してください。

Red Hat Advanced Cluster Management コンソールでのマルチクラスター監視

マルチクラスター監視は、複数のクラスターにまたがるストレージの正常性と容量の単一の単純化されたビューです。このマルチクラスター監視により、ストレージ容量を管理し、Red Hat Advanced Cluster Management (RHACM) ユーザーインターフェイスから OpenShift Data Foundation クラスターを監視できます。この監視機能は、DR クラスターと非 DR クラスターの両方に適用されます。

詳細は、マルチクラスターストレージの正常性の監視 を参照してください。

OpenShift Data Foundation が Microsoft Azure Government (MAG) にデプロイされている場合、マルチクラウドオブジェクトゲートウェイが間違った URL に API リクエストを送信する

以前は、デフォルトのバッキングストアに障害があり、システム全体の健全性が低下していました。これは、Multicloud Object Gateway (MCG) が、OpenShift Data Foundation がデプロイされたプラットフォームにデフォルトのバッキングストアを作成するためです。Microsoft Azure Government (MAG) の識別に問題があったため、デフォルトのバッキングストアが間違った値で作成されました。

今回の更新により、通常の Azure バッキングストアを作成する代わりに、MAG を識別するときに永続ボリューム (PV) プールが作成され、後で MAG 環境の上にバッキングストアを作成し、その新しいバッキングストアを使用することができます。

(BZ#1944572)

デフォルトのバッキングストア noobaa-default-backing-store が作成中状態のままになっている

以前は、Cloud Credentials Operator (CCO) がデフォルトのバッキングストアの作成後に資格情報を変更していました。そのため、使用されるバッキングストアは停止します。本リリースでは、デフォルトのバッキングストアの更新認証情報が修正されました。デフォルトの Multicloud Object Gateway (MCG) バッキングストアは、資格情報の変更中に作成でスタックしません。

(BZ#1992090)

接頭辞の名前が 99 と 990 の場合、S3 リストは無限ループに入ります。

以前は、MCG DB の開始時に照合アルゴリズムが正しく設定されていなかったため、リスト操作のクエリー結果は、Multicloud Object Gateway (MCG) が期待する順序ではありませんでした。

今回の更新により、MCG DB の開始時に新しい展開で照合アルゴリズムが正しく設定されるようになりました。これで、クエリー結果が期待どおりの順序になりました。

(BZ#2068110)

FIPS 対応環境での MD5 の使用は明示的に許可されており、S3 マルチパート操作を完了できる

以前は、FIPS が有効な環境では、暗号化以外の目的で明示的に除外されていない限り、MD5 ダイジェストの使用はデフォルトで許可されていませんでした。このため、S3 の完全なマルチパートアップロード操作中にセグメンテーション違反が発生しました。

この修正により、S3 の完全なマルチパート PUT 操作のための FIPS 対応環境での非暗号化目的での MD5 の使用が明示的に許可され、S3 のマルチパート操作を完了することができます。

(BZ#2086724)

Liveness Probe の障害により、OpenShift Data Foundation Pod が再起動しています

以前は、Pod の liveness プローブによって Ceph Pod が再起動されていました。このリリース更新では、liveness プローブのデフォルトのタイムアウトが増加します。ノードの負荷が高くなり、CPU/メモリーリソースが少なくなるため、Pod が再起動するまでの時間が長くなりました。

(BZ#2091951)

OpenShift Data Foundation 4.10.3 へのアップグレードがローカルボリュームのボリュームグループの非アクティブ化に失敗した後、OSD Pod が CrashLoopBackOff 状態になる

以前は、古い OpenShift Data Foundation リリース (4.3、4.4) の LVM ベースの OSD はバージョン 4.10 と互換性がなく、4.10 にアップグレードするとクラッシュしていました。今回の更新により、古い OpenShift Data Foundation リリースの OSD がクラッシュする代わりに実行されるようになりました。Rook は、これらのレガシー OSD を処理するための正しいフラグを追加して、4.10 で機能するようにします。

(BZ#2097268)

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

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

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

(BZ#2007376)

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

障害復旧 (DR) で保護されるワークロードをフェイルオーバーすると、ボリュームにファイルシステムの整合性チェック (fsck) エラーがあると示すボリュームマウントエラーにより、Pod が起動しない可能性があります。これにより、ワークロードはフェイルオーバークラスターにフェイルオーバーできなくなります。

(BZ#2021460)

各アクションの数分以内にフェイルオーバーと再配置が実行されると、再配置が失敗します

PeerReady 条件ステータスが TRUE になる前に、ユーザーがあるクラスターから別のクラスターへのアプリケーションの再配置を開始すると、DRPC YAML ファイルを介して、または次の oc コマンドを実行することによって、条件ステータスが表示されます。

$ oc get drpc -o yaml -n <application-namespace>

<application-namespace> は、アプリケーションをデプロイするためのワークロードが存在する名前空間です。

ピア (ターゲットクラスター) がクリーンな状態になる前に再配置が開始された場合、再配置は永久に停止します。

回避策: DRPC .Spec.Action を Failover に戻し、PeerReady 条件ステータスが TRUE になるまで待ちます。回避策を適用した後、アクションを 再配置 に変更すると、再配置が有効になります。

(BZ#2056871)

ユーザーは、DR ポリシーの作成中に同期スケジュールとして値を 0 分に設定でき、レプリケーションポリシーとして同期を報告し、地域の DR セットアップで検証されます。

DRPolicyList ページは、sync 間隔の値を使用してレプリケーションタイプを表示します。ゼロに設定されている場合、レプリケーションタイプは、メトロクラスターと地域クラスターの同期 (同期) と見なされます。この問題はユーザーを混乱させます。これは、ユーザーインターフェイスに Async スケジューリングタイプとして表示されている場合でも、バックエンドが Sync を考慮しているためです。

回避策: sync または async を決定するには、DRCluster CR ステータスから Ceph Fsid をフェッチする必要があります。

(BZ#2114501)

アプリケーションを削除すると、Pod は削除されますが、PVC は削除されません

RHACM コンソールからアプリケーションを削除しても、DRPC は削除されません。DRPC を削除しないと、VRG だけでなく VRG も削除されません。VRG/VR が削除されない場合、PVC ファイナライザーリストがクリーンアップされず、PVC が Terminating 状態のままになります。

回避策: 次のコマンドを使用して、ハブクラスターの DRPC を手動で削除します

$ oc delete drpc <name> -n <namespace>

結果:

(BZ#2108716)

両方の 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 リソースによって管理されなくなり、操作およびデータの不整合は発生しません。

(BZ#2111163)

一部のイメージで 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

結果: rbd mirror snapshot schedule status -p ocs-storagecluster-cephblockpool を使用して調べると、DR が有効で、管理対象クラスターでプライマリーとして示されているイメージがミラーリングスケジュールの報告を開始します。

(BZ#2067095)

Ceph が Globalnet によって割り当てられたグローバル IP を認識しない

Ceph は Globalnet によって割り当てられたグローバル IP を認識しないため、Globalnet を使用して重複するサービス CIDR を持つクラスター間で障害復旧ソリューションを設定することはできません。このため、サービス CIDR が重複している場合、障害復旧ソリューションは機能しません。

(BZ#2102397)

ボリュームレプリケーショングループの削除は、削除中に作成された新しいボリュームレプリケーションでスタックします。これは、永続的なボリュームクレームをファイナライザーで更新できないためスタックします。

ディザスターリカバリー (DR) リコンサイラーのバグにより、マネージドクラスターで内部 VolumeReplicaitonGroup リソースの削除中に、ワークロードがフェールオーバーまたは再配置された場所から、persistent volume claim (PVC) が保護されようとします。結果のクリーンアップ操作は完了せず、アプリケーションの DRPlacementControl で PeerReady 状態を報告します。

これにより、アプリケーションはフェイルオーバーまたは再配置され、DRPlacementControl リソースがその PeerReady 状態を false として報告するため、再配置または再フェイルオーバーできなくなります。

回避策: 回避策を適用する前に、VolumeReplicationGroup の削除中に PVC を保護することが原因であるかどうかを次のように判断します。

結果: ハブクラスターの DRPlacementControl は、PeerReady 状態を true として報告し、さらにワークロードの再配置またはフェイルオーバーアクションを有効にします。(BZ#2116605)

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

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

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

(BZ#2114573)

セカンダリークラスターへのフェールオーバー中に、PVC の一部がプライマリークラスターに残る

Kubernetes v1.23 より前の動作では、Kubernetes コントロールプレーンは StatefulSet 用に作成された PVC をクリーンアップしませんでした。これはクラスター管理者または StatefulSet を管理するソフトウェア Operator のままになります。このため、ステートフルセットの PVC は、Pod が削除されたときにそのまま残されていました。これにより、Ramen がアプリケーションを元のクラスターにフェールバックできなくなります。

回避策: ワークロードが StatefulSets を使用している場合は、フェールバックまたは別のクラスターに再配置する前に、次の操作を行います。

結果: ピアクラスターがクリーンアップされ、新しいアクションの準備が整います。(BZ#2118270)

フェイルバック中にアプリケーションが Relocating 状態でスタックする

マルチクラウドオブジェクトゲートウェイでは、同じ名前または名前空間の複数の永続ボリューム (PV) オブジェクトを同じパスの S3 ストアに追加できました。これにより、同一の claimRef を指す複数のバージョンが検出されたため、Ramen は PV を復元しません。

回避策: S3 CLI または同等の機能を使用して、重複する PV オブジェクトを S3 ストアからクリーンアップします。タイムスタンプがフェールオーバーまたは再配置の時刻に近いものだけを保持します。

結果: 復元操作が完了し、フェイルオーバーまたは再配置操作が次のステップに進みます。

(BZ#2120201)

ゾーンがダウンしている場合、アプリケーションが FailingOver 状態で停止する

フェイルオーバーまたは再配置時に、どの s3 ストアにも到達できない場合、フェイルオーバーまたは再配置プロセスがハングします。Openshift DR ログが S3 ストアに到達できないことを示している場合、トラブルシューティングを行い、s3 ストアを操作可能にすることで、OpenShift DR はフェイルオーバーまたは再配置操作を続行できます。

(BZ#2121680)

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

Red Hat Ceph Storage クラスターのクラッシュルールに複数の実行ステップがある場合、ceph df レポートは、マップの使用可能な最大サイズを間違って表示します。この問題は、今後のリリースで修正される予定です。

(BZ#2100920)

rook-ceph-operator-configConfigMap は、OpenShift Container Storage がバージョン 4.5 から他のバージョンにアップグレードされると更新されない

ocs-operator は rook-ceph-operator-config ConfigMap を使用して、rook-ceph-operator 動作を設定しますが、作成は 1 回だけで、調整は行いません。これにより、製品が進化してもデフォルト値が更新されないという問題が発生します。

回避策： 管理者は rook-ceph-operator-config の値を手動で変更できます。

(BZ#1986016)

ストレージシステムのインストール時に、ストレージクラスターおよびストレージシステムの ocs-storagecluster が数分間エラー状態になる

ストレージクラスターの作成中、正常な状態または準備完了状態に移行する前にエラー状態が表示されるわずかな時間枠があります。これは断続的な状態であるため、通常は自然に解決され、成功または準備完了になります。

回避策: 詳細については、ステータスメッセージまたはログを待ち、監視します。

(BZ#2004027)

Ceph OSD スナップトリミングが実行中のスクラブによってブロックされなくなりました

以前は、実行中のスクラブによってブロックされた OSD スナップトリミングは再開されませんでした。その結果、OSD がリセットされるまでトリミングは実行されませんでした。このリリースでは、スクラブとスナップのトリミングが期待どおりに機能した後にブロックされた場合のトリミングの再開の処理が修正されています。

(BZ#2067056)

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

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

(BZ#1982116)

親 PVC が展開されている場合、スナップショットの復元がサイズ制限で失敗する

ボリュームスナップショットと同じサイズのボリュームスナップショットから新しい復元された persistent volume claim (PVC) を作成する場合、ボリュームスナップショットを取得した後、復元された新しい PVC を作成する前に親 PVC のサイズが変更されると、失敗します。

回避策: 次の回避策のいずれかを使用できます。

(BZ#2120730)

OpenShift Data Foundation Operator がインストールされると、PodSecurityViolation アラートが発生し始める

OpenShift は、Pod Security Admission を導入して、OpenShift 4.11 が特権を適用する (4.10 と同じ) 監査および警告イベントを行うように、スケジュールされたときに Pod にセキュリティー制限を適用します。

その結果、openshift-storage 名前空間には Pod セキュリティーアドミッションに必要な適用ラベルがないため、イベントに警告が表示されます。

(BZ#2110628)