4.12 リリースノート
機能および拡張機能、既知の問題、その他の重要なリリース情報についてのリリースノート。
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック (英語のみ)
Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があれば、ぜひお知らせください。フィードバックをお寄せいただくには、以下をご確認ください。
特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。
- ドキュメントの表示が Multi-page HTML 形式になっていていることを確認してください。ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
- マウスカーソルを使用して、コメントを追加するテキストの部分を強調表示します。
- 強調表示されたテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される指示に従ってください。
より詳細なフィードバックをお寄せいただく場合は、Bugzilla のチケットを作成してください。
- Bugzilla の Web サイトに移動します。
- Component セクションで、documentation を選択します。
- Description フィールドに、ドキュメントの改善に向けたご提案を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- Submit Bug をクリックします。
第1章 概要
Red Hat OpenShift Data Foundation は、コンテナー環境向けに最適化されたソフトウェア定義のストレージです。このソフトウェアは、OpenShift Container Platform の Operator として実行されるため、コンテナーの永続ストレージ管理を高度に統合し、簡素化できます。
Red Hat OpenShift Data Foundation は、最新の Red Hat OpenShift Container Platform に統合されており、プラットフォームサービス、アプリケーションの移植性、永続性の課題に対応します。また、Red Hat Ceph Storage、Rook.io Operator および NooBaa’s Multicloud Object Gateway などのテクノロジースタックに構築された、次世代のクラウドネイティブアプリケーションに対して、非常にスケーラブルなバックエンドを提供します。OpenShift Data Foundation は、シングルノードの OpenShift クラスター用の Logical Volume Manager Storage もサポートします。詳細は、シングルノード OpenShift クラスター用の論理ボリュームマネージャーストレージの一般公開 を参照してください。
Red Hat OpenShift Data Foundation は、数多くの方法でアプリケーションのライフサイクル全体におけるユーザーエクスペリエンスを単純化し、強化する、信頼できるエンタープライズクラスのアプリケーション開発環境を提供します。
- データベースのブロックストレージを提供します。
- 継続的な統合、メッセージングおよびデータ集約のための共有ファイルストレージ。
- クラウドファースト開発、アーカイブ、バックアップ、およびメディアストレージ用のオブジェクトストレージ。
- アプリケーションとデータの飛躍的なスケーリングが可能です。
- 永続データボリュームの割り当てと割り当て解除を加速的に実行します。
- 複数のデータセンターまたはアベイラビリティーゾーンにクラスターを拡張します。
- 包括的なアプリケーションコンテナーレジストリーを確立します。
- データアナリティクス、人工知能、機械学習、ディープラーニング、および IoT (モノのインターネット) などの次世代の OpenShift ワークロードをサポートします。
- アプリケーションコンテナーだけでなく、データサービスボリュームおよびコンテナー、さらに追加の OpenShift Container Platform ノード、Elastic Block Store (EBS) ボリュームおよびその他のインフラストラクチャーサービスを動的にプロビジョニングします。
1.1. このリリースについて
Red Hat OpenShift Data Foundation 4.12 (RHSA-2023:0550 および RHSA-2023:0551) が利用可能になりました。以下では、OpenShift Data Foundation 4.12 に関連する新たな拡張機能、新機能、および既知の問題について説明します。
Red Hat OpenShift Data Foundation 4.12 は、Red Hat OpenShift Container Platform バージョン 4.12 でサポートされます。詳細は、Red Hat OpenShift Data Foundation Supportability and Interoperability Checker を参照してください。
Red Hat OpenShift Data Foundation のライフサイクル情報は、Red Hat OpenShift Container Platform ライフサイクルポリシー で、階層化された製品 (および依存関係のある製品) ライフサイクルのセクションを参照してください。
第2章 新機能
このセクションでは、Red Hat OpenShift Data Foundation 4.12 で導入された新機能について説明します。
2.1. Metropolitan 障害復旧 (Metro-DR) ソリューションの一般公開
Red Hat Advanced Cluster Management for Kubernetes 2.7 を使用した Metro-DR 機能が、Red Hat OpenShift Data Foundation バージョン 4.12.1 以降から一般公開されました。
Metro-DR ソリューションは、複数のクラスターの同期レプリケーションを使用しながら、データを損失することなく、データセンターが使用できなくなったときに保護とビジネスの継続性を確保します。パブリッククラウドでは、これらはアベイラビリティゾーンの障害からの保護に似ています。このソリューションは、データを失うことなくアプリケーションを迅速に回復します。
詳細は、計画ガイド および OpenShift Data Foundation ガイドの Metro-DR ソリューション を参照してください。
2.2. シングルノード OpenShift クラスター用の論理ボリュームマネージャーストレージの一般公開
論理ボリュームマネージャーストレージは、機能の多様性やデータの復元力よりもリソースの制約が重要なシングルノード OpenShift クラスターに動的なブロックストレージを提供します。ターゲットアプリケーションの 1 つは、テレコミュニケーション市場の無線アクセスネットワーク (RAN) です。詳細は、RHACM を使用した LVM ストレージのインストール を参照してください。
以前のバージョンでは、製品は OpenShift Data Foundation - Logical Volume Manager と呼ばれていました。一般公開に伴い、名前が論理ボリュームマネージャーストレージ (LVM ストレージまたは LVMS) に変更されました。
このリリース以降、動的ストレージに加えて、論理ボリュームマネージャーストレージは次の新機能を提供します。
- ディスクのローカルパスをパスまたは名前で手動で選択して、ボリュームグループを優先ディスクに制御または制限する機能を提供します。詳細は、RHACM を使用した OpenShift Data Foundation Logical Volume Manager Operator のインストール を参照してください。
- 追加のワーカーノードを持つシングルノード OpenShift クラスターに論理ボリュームマネージャーストレージをインストールして使用する機能を提供します。これは、目的のシングルノード OpenShift アーキテクチャーで論理ボリュームマネージャーストレージを使用するのに役立ちます。詳細は、RHACM を使用した OpenShift Data Foundation Logical Volume Manager Operator のインストール および シングルノード OpenShift クラスターのストレージのスケーリング を参照してください。
第3章 機能強化
このセクションでは、Red Hat OpenShift Data foundation 4.12 で導入された主な拡張機能について説明します。
3.1. シングルスタック IPv6 のサポート
シングルスタック IPv6 が Red Hat OpenShift Data Foundation でサポートされるようになりました。詳細は、シングルスタック IPv6 のサポート を参照してください。
3.2. KMIP を使用する KMS プロバイダーのサポート
このリリースでは、認証にクライアント証明書を使用する Key Management Interoperability Protocol (KMIP) を使用する鍵管理システム (KMS) プロバイダーのサポートが導入されています。Thales CipherTrust Manager は OpenShift Data Foundation 4.12 で問題なく動作します。詳細は、CipherTrust Manager を参照してください。
3.3. ログの詳細レベルの調整
ログのデバッグによって消費されるスペースの量は、重大な問題になる可能性があります。今回の更新では、デバッグログによって消費されるスペースが重要な問題になる場合があるため、デバッグログによって消費されるストレージの量を調整して制御できるようになりました。詳細は、ログの詳細レベルの調整 を参照してください。
3.4. 転送中での暗号化
この機能強化により、IPsec フレームワークは、Pod およびサービスに使用される仮想化ネットワークの 転送中の暗号化 を提供します。仮想化ネットワークは、Open Virtual Network (OVN)-Kubernetes Container Network Interface (CNI) プラグインによって提供されます。詳細は、プランニングガイド の 転送中の暗号化 を参照してください。
3.5. Multicloud Object Gateway PV プール Pod のリソース変更のサポート
この機能強化により、Multicloud Object Gateway (MCG) の永続ボリューム (PV) プールをベースとしたバッキングストアのパフォーマンスを微調整できます。これは、PV プールベースのバッキングストアの CPU およびメモリーリソースと制限を変更し、MCG のワークロードのパフォーマンスを向上させる機能を提供します。
詳細は、ローカル永続ボリュームでサポートされるバッキングストアの作成 を参照してください。
3.6. Multicloud Object Gateway のセキュアモードデプロイメント
この機能強化により、マルチクラウドオブジェクトゲートウェイ (MCG) をセキュアモードでデプロイし、外部アクセスを制限できます。これにより、MCG デプロイメントにアクセスできるサブネットをきめ細かく制御できます。詳細は、Multicloud Object Gateway のセキュアモードデプロイメントの有効化 を参照してください。
第4章 テクノロジープレビュー
このセクションでは、テクノロジープレビューのサポート制限に基づいて、Red Hat OpenShift Data Foundation 4.12 で導入されたテクノロジープレビュー機能について説明します。
テクノロジープレビュー機能は、実稼働環境での Red Hat サービスレベルアグリーメント (SLA) ではサポートされておらず、機能的に完全ではない可能性があるため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
テクノロジープレビュー機能は、カスタマーポータルの テクノロジープレビュー機能のサポート範囲 で詳細に説明されているように制限されたサポート範囲で提供されます。
4.1. OpenShift ワークロードの障害復旧ソリューション
OpenShift Data Foundation のディザスターリカバリー (DR) 機能は、複数の OpenShift Container Platform クラスターにわたる DR を可能にし、次のように分類されます。
リージョンディザスターリカバリー (Regional-DR)
地域 DR ソリューションは、ブロックボリュームの自動保護、非同期レプリケーションを提供し、地理的な場所で災害が発生したときにビジネス機能を保護します。パブリッククラウドでは、これはリージョン障害からの保護に似ています。詳細は、計画ガイド および OpenShift Data Foundation ガイドの Regional-DR ソリューション を参照してください。
Red Hat Advanced Cluster Management コンソールでのマルチクラスター監視
マルチクラスター監視は、複数のクラスターにまたがるストレージの正常性と容量の単一の単純化されたビューです。このマルチクラスター監視により、ストレージ容量を管理し、Red Hat Advanced Cluster Management (RHACM) ユーザーインターフェイスから OpenShift Data Foundation クラスターを監視できます。この監視機能は、DR クラスターと非 DR クラスターの両方に適用されます。詳細は、マルチクラスターストレージの正常性の監視 を参照してください。
CephFS ボリュームの非同期 Regional-DR の提供
Regional-DR ソリューションは、Ceph RBD ボリューム上の Regional-DR を使用した OpenShift Data Foundation のエクスペリエンスと同様に、OpenShift コンソールを使用した CephFS ボリュームでのオーケストレーション、フェイルオーバー、再配置など、Regional-DR タスクを追加し、お客様の DR ワークロード機能を拡張します。詳細は、プラインニングガイド と Regional-DR ソリューション ガイドを参照してください。
第5章 開発者向けプレビュー
このセクションでは、Red Hat OpenShift Data Foundation 4.12 で導入された開発者プレビュー機能について説明します。
開発者プレビュー機能は、開発者プレビューのサポート制限の対象となります。開発者プレビューのリリースは、実稼働環境で実行することは意図されていません。開発者プレビュー機能と共にデプロイしたクラスターは開発用クラスターとして考慮され、Red Hat カスタマーポータルのケース管理システムではサポートされません。開発者プレビュー機能に関してサポートが必要な場合には、ocs-devpreview@redhat.com メーリングリストに連絡してください。Red Hat Development Team のメンバーが稼働状況とスケジュールに応じて可能な限り迅速に対応します。
5.1. レプリカ 1 (回復性を持たないプール)
アプリケーションレベルで回復力を管理するアプリケーションは、データの回復力と高可用性なしで、単一のレプリカでストレージクラスを使用できるようになりました。
5.2. ネットワークファイルシステムの新機能
今回のリリースで、OpenShift Data Foundation は、内部または外部のアプリケーションに Network File System (NFS) v4.1 および v4.2 サービスを提供します。NFS サービスは、Red Hat Gluster Storage ファイルシステムから OpenShift 環境へのデータ移行など、任意の環境から OpenShift 環境へのデータ移行を支援します。NFS 機能には、ボリュームの拡張、スナップショットの作成と削除、およびボリュームのクローン作成も含まれます。
詳細は、ネットワークファイルシステムを使用するためのリソース要件 および NFS を使用したエクスポートの作成 を参照してください。
5.3. アップグレード時に rook-ceph-operator-config 環境変数がデフォルト値を変更可能
今回の更新により、OpenShift Data Foundation がバージョン 4.5 から別のバージョンにアップグレードされるときに、rook-ceph-operator-config 環境変数がデフォルトを変更できるようになりました。これは、以前のバージョンでは不可能でした。
5.4. Ceph ターゲットサイズ比率の簡単な設定
今回の更新により、すべてのプールのターゲットサイズ比率を変更できるようになりました。以前のバージョンでは、Ceph クラスターに rook で展開されたプールには、RBD と CephFS データの両方で 0.49 の target_ratio が割り当てられ、RBD プールの PG の割り当て不足と CephFS メタデータプールの PG の割り当て過多が発生することがありました。詳細は、プールのターゲットサイズ比率の設定 を参照してください。
5.5. Pod の一時ストレージ
エフェメラルボリュームのサポートにより、ユーザーは Pod 仕様でエフェメラルボリュームを指定し、PVC のライフサイクルを Pod に関連付けることができます。
5.6. OpenShift Data Foundation での RGW のマルチサイト設定
この機能は、内部または外部の OpenShift Data Foundation クラスターの Zone、ZoneGroup、または Realm などのマルチサイト設定をサポートします。このセットアップは、データを別のサイトにレプリケートし、障害が発生した場合にデータを回復するのに役立ちます。
5.7. 単一ノードクラスターでの Multicloud Object Gateway (MCG)
このリリースでは、単一ノードの OpenShift (SNO) クラスター用に軽量のオブジェクトストレージソリューションが提供されます。MCG を使用し、ローカルストレージの上に階層化された backingstore を使用します。以前は、SNO で実行されているデプロイメントはブロックストレージしか使用できませんでした。
5.8. 信頼済み証明書を使用したトランザクションの安全性とプライバシーの確保
この機能は、エクスターナルモードを使用する場合に、OpenShift Data Foundation と Red Hat Ceph Storage の間のオブジェクトストレージの 転送中 の暗号化を提供します。これにより、転送中および保管中のすべてのデータを暗号化できます。詳細については、信頼できる証明書の使用方法 に関する ナレッジベースの記事 を参照してください。
第6章 バグ修正
このセクションでは、Red Hat OpenShift Data Foundation 4.12 で導入された重要なバグ修正について説明します。
6.1. 障害復旧
asyncレプリケーションを0に設定できなくなりました以前は、
Sync scheduleに任意の値を入力できました。そのため、非同期レプリケーションを0に設定でき、エラーが発生していました。今回の更新で、1 未満の値を許可しない数値入力が導入されました。asyncレプリケーションが正しく機能するようになりました。
アプリケーション削除時に、Pod と PVC が正しく削除されるようになりました
以前は、RHACM コンソールからアプリケーションを削除しても、DRPC が削除されませんでした。DRPC を削除しないと、VRG だけでなく VR も削除されません。VRG/VR が削除されない場合、PVC ファイナライザーリストがクリーンアップされず、PVC が
Terminating状態のままになります。今回の更新により、RHACM コンソールからアプリケーションを削除すると、必要な従属 DRPC と管理対象クラスター上の関連リソースが削除され、必要なガベージコレクションのために PVC も解放されます。
ワークロードがフェイルオーバーまたは再配置された場所から内部
VolumeReplicaitonGroupリソースを削除しても、エラーが発生しなくなりましたディザスターリカバリー (DR) リコンサイラーのバグにより、ワークロードがフェイルオーバーまたは再配置されたマネージドクラスターで内部
VolumeReplicaitonGroupリソースを削除する際に、永続ボリューム要求 (PVC) が保護されていました。結果のクリーンアップ操作は完了せず、アプリケーションのDRPlacementControlのPeerReady条件がFalseであると報告されていました。そのため、フェイルオーバーまたは再配置されたアプリケーションを再配置または再フェイルオーバーすることができませんでした。これは、DRPlacementControlリソースのPeerReady状態がFalseであると報告されていたためです。今回の更新により、内部
VolumeReplicationGroupリソースの削除中に PVC が再度保護されなくなったため、クリーンアップが停止する問題が回避されます。これにより、クリーンアップの自動完了後に、DRPlacementControlのPeerReadyがTrueとレポートされるようになりました。
6.2. Multicloud Object Gateway
StorageClassの作成を待機している間に、StorageClusterがError状態になることはなくなりました。Red Hat OpenShift Data Foundation
StorageClusterが作成されると、基礎となるプールが作成されるのを待ってから、StorageClassが作成されます。この間、プールの準備が整うまで、クラスターは調整リクエストに対してエラーを返します。このエラーにより、StorageClusterのPhaseがErrorに設定されます。今回の更新により、このエラーはプールの作成中にキャッチされ、StorageClusterのPhaseはProgressingに設定されるようになりました。
6.3. CephFS
RHCS 5.1 からそれ以降のバージョンに更新する際のバケットメタデータに関する問題が解決されました
Red Hat Ceph Storage (RHCS) バージョン 5.1 に同梱されている RADOS Gateway (RGW) に、まだ一般提供されていない、マルチサイトレプリケーション設定におけるバケットインデックスの動的再シャーディングのサポートに関連するロジックが誤って含まれていました。このロジックは、RHCS 5.2 から意図的に削除されました。この過程による影響として、RHCS 5.1 にアップグレードしたサイトは RHCS 5.2 にアップグレードできません。これは、バージョン 5.2 のバケットメタデータ処理が RHCS 5.1 の処理と互換性がないためです。この状況は、RHCS 5.3 へのアップグレードで解決されました。その結果、RHCS 5.3 は、5.1 を含む以前のすべてのバージョンで作成されたバケットで動作するようになりました。
6.4. OpenShift Data Foundation Operator
ODF Operator インストール時の Pod セキュリティ違反アラートがなくなりました
OpenShift Data Foundation バージョン 4.11 で、特権付き Pod の実行時に警告を発する新しい POD セキュリティーアドミッション標準が導入されました。ODF Operator のデプロイメントでは、特権アクセスが必要ないくつかの Pod を使用します。このため、ODF Operator がデプロイされた後、Pod セキュリティー違反アラートが発生しました。
今回のリリースより、OLM は、関連する Pod セキュリティーアドミッション標準のために、
openshift-*で始まる namespace に自動的にラベルを付けるようになりました。
第7章 既知の問題
このセクションでは、Red Hat OpenShift Data Foundation 4.12 の既知の問題について説明します。
7.1. 障害復旧
フェイルオーバーアクションは、RPC エラー still in use を表示し、Pod で失敗した RADOS ブロックデバイスのイメージマウントを報告する。
障害復旧 (DR) で保護されるワークロードをフェイルオーバーすると、フェールオーバーしたクラスター上のボリュームを使用している Pod が、RADOS ブロックデバイス (RBD) イメージがまだ使用中であることを報告する時に停止する可能性があります。これにより、Pod が長時間 (最大数時間) 起動できなくなります。
フェイルオーバーアクションは、RPC エラー fsck を表示し、Pod で失敗した RADOS ブロックデバイスのイメージマウントを報告する。
障害復旧 (DR) で保護されるワークロードをフェイルオーバーすると、ボリュームにファイルシステムの整合性チェック (fsck) エラーがあると示すボリュームマウントエラーにより、Pod が起動しない可能性があります。これにより、ワークロードはフェイルオーバークラスターにフェイルオーバーできなくなります。
マネージドクラスターのアプリケーション namespace が作成される
アプリケーション namespace は、Disaster Recovery(DR) 関連の事前デプロイアクションのために RHACM マネージドクラスターに存在する必要があるため、アプリケーションが ACM ハブクラスターにデプロイされるときに事前に作成されます。ただし、アプリケーションがハブクラスターで削除され、対応する namespace がマネージドクラスターで削除された場合、それらはマネージドクラスターに再表示されます。
回避策:
openshift-drは、ACM ハブのマネージドクラスター namespace に namespacemanifestworkリソースを維持します。これらのリソースは、アプリケーションの削除後に削除する必要があります。たとえば、クラスター管理者として、ハブクラスターでoc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mwのコマンドを実行します。
一部のイメージで 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 が有効で、管理対象クラスターでプライマリーとして示されているイメージがミラーリングスケジュールの報告を開始します。
クラスターがストレッチモードの場合、ceph
dfが無効な MAX AVAIL 値を報告するRed Hat Ceph Storage クラスターのクラッシュルールに複数の実行ステップがある場合、
ceph dfレポートは、マップの使用可能な最大サイズを間違って表示します。この問題は、今後のリリースで修正される予定です。
Ceph が Globalnet によって割り当てられたグローバル IP を認識しない
Ceph は Globalnet によって割り当てられたグローバル IP を認識しないため、Globalnet を使用して重複するサービス CIDR を持つクラスター間で障害復旧ソリューションを設定することはできません。このため、サービス
CIDRが重複している場合、障害復旧ソリューションは機能しません。
両方の 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 リソースによって管理されなくなり、操作およびデータの不整合は発生しません。
MongoDB Pod は、
cephrbdボリュームのデータを読み取る許可エラーのため、CrashLoopBackoffになっています異なるマネージドクラスターにまたがる Openshift プロジェクトには、異なるセキュリティーコンテキスト制約 (SCC) があり、特に指定された UID 範囲と
FSGroupsが異なります。これにより、特定のワークロード Pod とコンテナーが、ログ内のファイルシステムアクセスエラーが原因で、これらのプロジェクト内でフェールオーバーの操作または再配置操作を開始できなくなります。回避策: ワークロードプロジェクトが同じプロジェクトレベルの SCC ラベルを持つすべてのマネージドクラスターで作成されていることを確認し、フェイルオーバーまたは再配置時に同じファイルシステムコンテキストを使用できるようにします。Pod は、ファイルシステム関連のアクセスエラーで DR 後のアクションに失敗しなくなりました。
再配置中にアプリケーションが Relocating 状態でスタックする
マルチクラウドオブジェクトゲートウェイでは、同じ名前または namespace の複数の永続ボリューム (PV) オブジェクトを同じパスの S3 ストアに追加できました。これにより、同一の
claimRefを指す複数のバージョンが検出されたため、Ramen は PV を復元しません。回避策: S3 CLI または同等の機能を使用して、重複する PV オブジェクトを S3 ストアからクリーンアップします。タイムスタンプがフェールオーバーまたは再配置の時刻に近いものだけを保持します。
結果: 復元操作が完了し、フェイルオーバーまたは再配置操作が次のステップに進みます。
ゾーンがダウンしている場合、アプリケーションが FailingOver 状態で停止する
フェイルオーバーまたは再配置時に、どの s3 ストアにも到達できない場合、フェイルオーバーまたは再配置プロセスがハングします。DR ログが S3 ストアに到達できないことを示している場合、トラブルシューティングを行い、s3 ストアを操作可能にすることで、DR はフェイルオーバーまたは再配置操作を続行できます。
ワークロードをピアクラスターにフェイルオーバーまたは再配置すると、フェイルオーバーまたは再配置元のクラスターがクリーンアップされるまで、
PeerReady条件がtrueに設定される障害復旧 (DR) アクションを開始した後、ワークロードがピアクラスターにフェールオーバーまたは再配置される間、
PeerReady条件は最初にtrueに設定されます。その後、フェイルオーバーまたは再配置元のクラスターは、今後のアクションのためにクリーンアップされるまで、falseに設定されます。アクションを実行するためにDRPlacementControlステータス条件を見ているユーザーは、この中間的なPeerReady状態を見て、ピアの準備ができていると認識し、アクションを実行する可能性があります。この場合、操作は保留中されるか失敗し、回復するためにユーザーの介入が必要になることがあります。回避策: アクションを実行する前に、
AvailableとPeerReadyの両方の状態を調べます。ワークロードの DR 状態を正常にするために、両方がtrueである必要があります。両方の状態が true のときにアクションを実行すれば、要求された操作が進行します。
障害復旧のワークロードが削除されたままになる
クラスターからワークロードを削除すると、対応する Pod が
FailedKillPodなどのイベントで終了しない場合があります。これにより、PVC、VolumeReplication、VolumeReplicationGroupなどの DR リソースに依存するガベージコレクションで遅延または障害が発生する可能性があります。また、古いリソースがまだガベージコレクションされていないため、クラスターへの同じワークロードの今後のデプロイもできなくなります。回避策: Pod が現在実行中で、終了状態でスタックしているワーカーノードを再起動します。これにより、Pod が正常に終了し、その後、関連する DR API リソースもガベージコレクションされます。
ブロックリスト登録により 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 がスケジュールされ、障害が発生しているノードを再起動します。
- 問題のあるノードを遮断してからドレインします。
- 問題のあるノードを再起動します。
- 問題のあるノードのコードの遮断を解除します。
7.2. CephFS
CephFS でのストレッチクラスターのパフォーマンスが低下する
マルチサイトの Data Foundation クラスターにメタデータサーバー (MDS) を任意に配置するため、小さなメタデータ操作が多数あるワークロードでは、パフォーマンスが低下する可能性があります。
7.3. OpenShift Data Foundation コンソール
アップグレード後に OpenShift Data Foundation ダッシュボードがクラッシュする
OpenShift Container Platform および OpenShift Data Foundation をアップグレードした場合は、ダッシュボードリンクをクリックすると、ストレージセクションの Data Foundation ダッシュボードが 404: ページが見つかりませんというエラーでクラッシュします。これは、コンソールを更新するポップアップが表示されないためです。
回避策: コンソールのハードリフレッシュを実行します。これにより、ダッシュボードが元に戻り、クラッシュしなくなります。
第8章 エラータの非同期更新
8.1. RHSA-2023:4287 OpenShift Data Foundation 4.12.5 バグ修正およびセキュリティー更新
OpenShift Data Foundation リリース 4.12.5 が利用可能になりました。更新に含まれるバグ修正は、RHSA-2023:4287 アドバイザリーに記載されています。
8.2. RHSA-2023:3609 OpenShift Data Foundation 4.12.4 バグ修正およびセキュリティー更新
OpenShift Data Foundation リリース 4.12.4 が利用可能になりました。更新に含まれるバグ修正は、RHSA-2023:3609 アドバイザリーに記載されています。
8.3. RHSA-2023:3265 OpenShift Data Foundation 4.12.3 バグ修正およびセキュリティー更新
OpenShift Data Foundation リリース 4.12.3 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2023:3265 アドバイザリーにリストされています。
8.4. RHBA-2023:1816 OpenShift Data Foundation 4.12.2 のバグ修正とセキュリティー更新
OpenShift Data Foundation リリース 4.12.2 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2023:1816 アドバイザリーにリストされています。
8.5. RHBA-2023:1170 OpenShift Data Foundation 4.12.1 のバグ修正とセキュリティー更新
OpenShift Data Foundation リリース 4.12.1 が利用可能になりました。更新に含まれるバグ修正は RHBA-2023:1170 アドバイザリーに記載されています。
8.5.1. 新機能
Metropolitan 障害復旧 (Metro-DR) ソリューションの一般公開
Red Hat Advanced Cluster Management for Kubernetes 2.7 を使用した Red Hat OpenShift Data Foundation Metro-DR 機能が一般公開されました。
ブロックとファイルの両方に対応する Regional-DR ソリューションは、テクノロジープレビューとして提供され、テクノロジープレビューのサポート制限の対象となります。
詳細は、計画ガイド および OpenShift Data Foundation ガイドの Metro-DR ソリューション を参照してください。
8.5.2. 機能強化
COS によって検出された読み取りパフォーマンスの問題を修正しました
この機能拡張により、Multicloud Object Gateway データベースの読み取り操作のパフォーマンスが改善されました。これを実現するために、データベースに対して実行して必要なデータを提供する一部のクエリーで使用される特定の正規表現が事前にコンパイルされています。これにより、リアルタイムで実行するときに時間を節約できます。(BZ#2149861)
非接続環境のサポートおよび RelatedImages フィールド用の不足していたアノテーションを CSV に追加しました
この機能拡張により、multicluster-orchestrator Operator が、非接続モードのインストールをサポートする Operator に一覧表示されるようになりました。この Operator を表示するために、ユーザーインターフェイス (UI) がこの注釈を使用するときに、非接続モード対応アノテーションが CSV に追加されます。(BZ#2166223)
8.5.3. 既知の問題
ハブコンソールからアプリケーションのフェイルオーバーを開始できない
アクティブ/パッシブのハブ Metro-DR 設定を使用している場合、Ramen リコンサイラーが許容されるレート制限パラメーターを超えた後に実行を停止するという状況が発生することがまれにあります。調整は各ワークロードに固有であるため、そのワークロードのみが影響を受けます。このような場合、Ramen Pod が再起動するまで、そのワークロードに関連するすべての障害復旧オーケストレーションアクティビティーが停止します。
回避策: ハブクラスターで Ramen Pod を再起動します。
$ oc delete pods <ramen-pod-name> -n openshift-operators
アクティブハブゾーンの障害が繰り返し発生すると、コンソールからアプリケーションをフェイルオーバーできない
複数のハブの復旧中に、ハブとマネージドクラスターの両方がダウンするなどの二重の障害が発生すると、最後のアクションが再配置であった場合、RHACM コンソールからフェイルオーバーを開始できないことがあります。
回避策: CLI を使用して DRPC.spec.action フィールドを Failover に設定します。
$ oc edit drpc -n app-1 app-1-placement-1-drpc
spec action: Failover
結果: フェイルオーバークラスターへのワークロードのフェイルオーバーが開始されます。