IBM Power Systems の一般公開サポート

OpenShift Container Storage が IBM Power Systems を使用してインストールされ、管理できるようになりました。詳細は、IBM Power Systems を使用した OpenShift Container Storage のデプロイ ガイドを参照してください。

IBM Z および LinuxONE の一般公開サポート

OpenShift Container Storage が IBM Z および LinuxONE を使用してインストールされ、管理できるようになりました。詳細は、IBM Z および LinuxONE を使用した OpenShift Container Storage のデプロイ を参照してください。

VMware vSphere 7 の一般公開サポート

OpenShift Container Storage が VMware vSphere 7 を使用してインストールされ、管理できるようになりました。内部クラスターをサポートし、外部クラスターの使用をサポートします。推奨されるバージョンは vSphere 6.7 Update 2 または vSphere 7 です。詳細は、VMware vSphere インフラストラクチャーの要件 について参照してください。

VMware vSphere インストーラーでプロビジョニングされるインフラストラクチャーの一般公開サポート

OpenShift Container Storage は、インストーラーでプロビジョニングされるインフラストラクチャーおよびユーザーによってプロビジョニングされるインフラストラクチャーの両方で、VMware vSphere を使用してインストールされ、管理できるようになりました。詳細は、Deploying OpenShift Container Storage on VMware vSphere を参照してください。

Red Hat Virtualization の一般公開 (GA) のサポート

OpenShift Container Storage が Red Hat Virtualization を使用してインストールできるようになりました。詳細は、Red Hat Virtualization を使用した OpenShift Container Storage のデプロイおよび管理 ガイドを参照してください。

暗号化されたストレージデータ

Red Hat OpenShift Container Storage は、ストレージクラスター内のすべてのディスクについてクラスター全体の暗号化 (保存時の暗号化、encryption-at-rest) をサポートします。これは Multicloud Object Gateway データの暗号化にも使用されます。外部の鍵管理システム (KMS) を使用して、暗号化キーを Red Hat OpenShift Container Storage 4.7 に保存できます。

OpenShift Container Storage クラスターの柔軟なスケーリング

柔軟なスケーリング機能が有効な状態で、デフォルトの 3 つの OSD のセットではなく、YAML ファイルを使用して一度に 1 つ以上の OSD で容量を追加できます。ただし、クラスターのバランスを維持した状態でディスクを追加する必要があります。

オブジェクトバケットクラスのバッキングストア設定の更新

OpenShift Container Storage 4.7 では、OpenShift Web コンソールを使用してバケットクラスのオブジェクトバッキングストア設定を更新できます。

Multicloud Object Gateway CLI および YAML を使用した namespace バケットの追加

Red Hat OpenShift Container Storage 4.7 ドキュメントには、Multicloud Object Gateway コマンドラインインターフェイスおよび YAML を使用して namespace バケットを追加する手順が追加されました。詳細は、ハイブリッドおよびマルチクラウドリソースの管理ガイド を参照してください。

ガイド付きツアー

ガイド付きツアーが OpenShift Container Platform 4.7 Web コンソールの OpenShift Container Storage 4.7 で利用可能になりました。

OpenShift Container Storage の正常なアップグレードを示す表示が改善される

以前のバージョンでは、OpenShift Container Storage のアップグレードが正常に完了したかどうかを判断することは容易ではありませんでした。一部のコンポーネントが新規コンテナーイメージにアップグレードされていない場合でも、コンソールで報告されない場合がありました。今回の更新により、StorageCluster は、すべての管理対象コンポーネントの実行中のコンテナーイメージを確認し、報告するようになりました。これはアップグレードシナリオのトラブルシューティングに役立ちます。

OSD Pod の Disruption Budget (停止状態の予算) の再設計

以前のバージョンでは、デフォルトで OpenShift Container Storage の Pod の Disruption Budget (停止状態の予算)(PDB) には minUnavailable=0 があり、一度に 1 つのノードでの OSD の再起動のみが許可されました。そのため、OCP コンソールは、再起動できないノードについての警告を常に表示しました。今回の更新により、OSD の PDB は以下のように再設計されました。

外部モードでの RGW アドレスの更新

今回の更新により、Multicloud Object Gateway (MCG) が外部モードで RGW バッキングストアで設定されている場合、 MCG に影響を与えることなく RGW アドレスを変更できるようになりました。

RGW の空き領域

以前のバージョンでは、NooB バケットはすべてのバケットについて 1PiB のストレージ容量を示し、RGW の空き領域を表示しませんでした。今回の機能拡張により、Red Hat Ceph クラスターのストレージ容量がステータスフィールドにエクスポートされ、NooBaa Operator はこのステータスフィールドへの変更をリッスンし、すべての RGW ベースのバッキングストアの利用可能な容量を更新するようになりました。

外部モードについて、サービスモニターポートの設定をデフォルト ceph-mgr Prometheus ポートとは異なる設定にできる

今回の機能拡張により、外部 Red Hat Ceph クラスターがデフォルト以外のポート (9283) でリッスンする ceph-mgr Prometheus モジュールで設定されている場合、OpenShift Container Storage はこれらのメトリクスに接続し、消費できるようになりました。つまり、OpenShift Container Storage はすべてのモニターリングポートを受け入れるようになりました。

ocs-operator は外部モードのモニターリングサービスにデフォルト以外のポートを許可する

以前のバージョンでは、ocs-operator で、デフォルトポート 9283 以外のモニターリング Prometheus サービスのポートは許可されませんでした。このため、モニターリングサービス用にポートが使用できませんでした。今回の更新により、ocs-operator が、予想通りに外部クラスターの JSON 入力およびモニターリングサービスからデフォルト以外のモニターリングポートを受け入れ、伝播できるように有効にされました。

既存のシークレットの使用による新規バッキングストアの作成

今回の機能拡張により、既存のシークレットを使用して Multicloud Object Gateway CLI で新規バッキングストアを作成できるようになりました。

既存の OSD デプロイメントの更新に対して、新規 OSD デプロイメントの作成を優先します。

以前のバージョンでは、Persistent Volume Claim(永続ボリューム要求、PVC) の OSD では、Rook は新規 OSD を作成する前に既存 OSD の更新を暗黙的に推奨し、これにより、OSD の調整が終了するまで新規の容量がクラスターに追加されませんでした。今回の機能拡張により、クラスターは既存 OSD の更新に対して OSD のスケールアップを優先し、ストレージがプロビジョニングされるとすぐに新規の容量が利用可能になり、これにより、クラスターで OSD 数をスケールアップする間に調整を実行でき、調整時間は 15 分から 5-10 分に削減されます。

RGW の公開ルート

今回の更新により、OpenShift Container Storage Operator は Red Hat Ceph Storage の RADOS Object Gateway (RGW) サービスのルートを作成するようになりました。

IBM Cloud 設定の認証情報なしに OpenShift Container Storage を ROKS にデプロイする

今回の更新により、OpenShift Container Storage が ROKS でデプロイされ、デフォルトのバッキングストアとして ROKS を使用するために認証情報が指定されていない場合に IBM Cloud のセットアップのインストールを容易にするために、PV プールのデフォルト BackingStore が作成されます。

OSD 再起動の Prometheus アラート

今回の機能拡張により、OpenShift Container Storage OSD が 5 分間に 6 回以上再起動した場合に通知するように Prometheus アラートが追加されました。アラートメッセージは以下のようになります。

namespace バケットのシステムアラート

Red Hat OpenShift Container Storage 4.7 のリリースでは、namespace バケットおよびリソースについてのシステムアラートが追加され、システムの現在の状態をより明確に把握できるようになりました。

ログメッセージを noobaa-endpoint Pod ログに出力する

以前のバージョンでは、デバッグオプションが設定されていない場合でも、ログメッセージが noobaa-endpoint Pod ログに出力されました。今回のリリースにより、デバッグオプションが設定されている場合にのみ、ログメッセージが noobaa-endpoint Pod ログに出力されるようになりました。

MON がダウンしても MGR Pod が再起動する

以前のバージョンでは、ノードを再起動すると MGR Pod が Pod の初期状態のままになり、新しい永続ボリューム (PV) を作成できませんでした。今回の更新により、MON がダウンしても MGR Pod が再起動するようになりました。

Huge Page が OpenShift Container Platform で有効になっている場合に Multicloud Object Gateway を使用できるようになりました

以前のバージョンでは、Huge Page が有効になっている場合に Postgres が kubernetes での実行に失敗したため、Multicloud Object Gateway (MCG) db Pod がクラッシュしていました。現在の更新では、MCG Postgres Pod の Huge Page が無効になるため、MCG db Pod がクラッシュしなくなりました。

PodDisruptionBudget アラートが継続的に表示されなくなる

以前のバージョンでは、OpenShift Container Platform アラートである PodDisruptionBudget アラートは、オブジェクトストレージデバイス (OSD) について継続的に表示されました。根本的な問題が修正され、アラートが表示されなくなりました。

must-gather ログ収集の失敗

以前のバージョンでは、コピー Pod は一定間隔でデータの再フラッシュを試行しませんでした。そのため、デフォルトの 10 分のタイムアウト後に must-gather コマンドが失敗しました。今回の更新により、コピー Pod は must-gather コマンドで生成される定期的な間隔でデータの収集を試行し続け、must-gather コマンドが完了するまで実行されるようになりました。

volumesnapshotclass がない場合に PVC をボリュームスナップショットから PVC を作成できない

PVC は、volumesnapshotclass がない場合にボリュームスナップショットから作成することはできません。この問題は、ボリュームスナップショットのステータスが volumesnapshotclass の削除時に not ready 状態に変更されるために生じます。この問題は OCP 4.7.0 以降で修正されています。

プロセスのクラッシュ時に、コアダンプは伝播しない

以前のバージョンでは、プロセスがクラッシュした場合にコアダンプが伝播されませんでした。今回のリリースにより、メインの ceph デーモンの次に実行されるサイドカーの log-collector が導入されました。ここでは ShareProcessNamespace フラグが有効になり、このフラグを使用すると、シグナルをコンテナー間でインターセプトでき、コアダンプを生成できます。

複数の OSD 削除ジョブが失敗しなくなる

以前のバージョンでは、複数の OSD の削除についてのジョブをトリガーする場合、テンプレートにはジョブ名に含まれる OSD ID と共にコンマが含まれていました。これにより、ジョブテンプレートが失敗しました。今回の更新により、有効な形式を維持するために、OSD ID がジョブ名から削除されました。ジョブ名が ocs-osd-removal-${FAILED_OSD_IDS} から ocs-osd-removal-job に変更になりました。

mon フェイルオーバータイムアウトの増加

今回の更新により、IBM Cloud での mon のフェイルオーバーのタイムアウトが 15 分に増えました。以前のバージョンでは、mons は稼働中の場合でもフェイルオーバーを開始していました。

Rook は、以前の OpenShift Container Storage インストールから不完全なディスクを検出すると、メッセージを出して OSD のデプロイを拒否します。

以前のバージョンでは、OpenShift Container Storage の以前のインストールから消去されていないディスクを再利用すると、Rook は突然失敗しました。今回の更新により、Rook はディスクが別のクラスターに属することを検知し、エラーメッセージを出してそのディスクでの OSD のデプロイを拒否するようになりました (BZ#1922954)

mon フェイルオーバーにより Ceph がアクセス不可能になる

以前のバージョンでは、mom が別の mon がフェイルオーバーしている間にダウンした場合、mom のクォーラム (定足数) が失われました。mom がクォーラム (定足数) を失うと Ceph はアクセス不可能なります。今回の更新により、mon がフェイルオーバーしている間に、任意の mon のドレイン (解放) が阻止され、Ceph がアクセス不可能になりました。

cpehcsi ノードプラグイン Pod が GRPC メトリクスのためにポートを占有する

以前のバージョンでは、cephcsi Pod はデバッグ目的で GRPC メトリクスを公開するため、cephcsi ノードプラグイン Pod は RBD にポート 9090 を使用し、CephFS にポート 9091 を使用しました。その結果、cephsi Pod はポートが利用できないために起動しませんでした。今回のリリースにより、GRPC メトリクスはデバッグの目的でのみ必要とされるためにデフォルトで無効になり、cephcsi はノードプラグイン Pod が実行されているノードでポート 9091 および 9090 を使用しなくなりました。

rook-ceph-mds はモニターサーバーに Pod IP を登録しない

以前のバージョンでは、rook-ceph-mds はモニターサーバーで Pod IP を登録しないため、ファイルシステム上のすべてのマウントがタイムアウトになり、PVC はプロビジョニングできず、CephFS ボリュームのプロビジョニングが失敗しました。今回のリリースにより、ホストネットワークが有効でない場合に引数 --public-addr=podIP が MDS Pod に追加されるようになりました。したがって、CephFS ボリュームのプロビジョニングは失敗しなくなりました。

ルール評価の失敗による must gather のエラー

以前のバージョンでは、記録ルールのレコード cluster:ceph_disk_latency:join_ceph_node_disk_irate1m は、many-to-many 一致が Prometheus で許可されないために評価されませんでした。このルール評価の失敗により、エラーが must gather とデプロイメントに生じました。今回のリリースにより、記録ルールのクエリーが更新され、many-to-many 一致のシナリオが排除され、これにより Prometheus ルール評価が失敗せず、デプロイメントでエラーが確認されなくなりました。

ストレージクラスを使用した永続ボリュームの暗号化

デバイスの暗号化キーを保存するために外部の鍵管理システム (KMS) を使用して、ストレージクラスの暗号化で永続ボリューム (ブロックのみ) を暗号化できます。永続ボリュームの暗号化は RADOS Block Device (RBD) 永続ボリュームでのみ利用できます。ストレージクラスの暗号化は OpenShift Container Storage 4.7 以降でサポートされます。詳細は、永続ボリュームの暗号化を使用したストレージクラスの作成方法 について参照してください。

Arbiter を使用した障害復旧

Red Hat OpenShift Container Storage は、metro 障害復旧 (展開されるクラスター - Arbiter) 機能を提供するようになりました。この機能により、ストレージクラスターの作成時に、3 番目のゾーンを Arbiter の場所とした上で、単一クラスターを 2 つのゾーンに展開できます。詳細は、デプロイメントプランニングガイドの 障害復旧 について参照してください。

オブジェクトバケットのキャッシュポリシー

Red Hat OpenShift Container Storage の Multicloud Object Gateway では、キャッシュバケットを作成できるようになりました。キャッシュバケットは、ハブのターゲットとキャッシュターゲットが指定された namespace バケットです。詳細は、オブジェクトバケットのキャッシュポリシー について参照してください。

Red Hat OpenStack Platform のテクノロジープレビュー機能のサポート

OpenShift Container Storage が Red Hat OpenStack Platform にインストールされ、管理できるようになりました。詳細は、Red Hat OpenStack Platform を使用した OpenShift Container Storage のデプロイおよび管理 ガイドを参照してください。

最小デプロイメントのテクノロジープレビューのサポート

OpenShift Container Storage は、標準のデプロイメントリソース要件を満たしていない場合に、最小の設定でデプロイできるようになりました。詳細は、プランニングガイドの デプロイメントリソースの最小要件 について参照してください。

コンパクトデプロイメントのテクノロジープレビューのサポート

OpenShift Container Storage は、3 ノードの OpenShift のコンパクトなベアメタルクラスターにインストールできるようになりました。ここでは、すべてのワークロードが 3 つの強力なマスターノードで実行されます。ワーカーノードまたはストレージノードは含まれません。

追加デバイスを使用したストレージ容量の拡張

管理者は、デプロイメント時に定義されるストレージクラス以外のストレージクラスを使用してストレージ容量をスケールアップできるようになりました。まず既存のストレージクラスに基づいて新規ストレージクラスを定義し、OpenShift Container Storage 容量の拡張が必要な場合にストレージクラスを選択します。詳細は、ストレージのスケーリング について参照してください。

新規の読み取り専用のアクセスモードでのスナップショットのクローン作成または復元

Red Hat OpenShift Container Storage 4.7 では、読み取り専用 (RXO) アクセスモードでクローンを作成したり、ボリュームスナップショットを復元したりできます。詳細は、新規 ROX アクセスモードでのクローンの作成またはスナップショットの復元 について参照してください。

マルチクラスターの障害復旧

Red Hat OpenShift Container Storage は、 2 つの kubernetes クラスターを提供する 2 つの Openshift Container Storage クラスター全体でのストレージボリュームのマルチクラスターの非同期レプリケーションを提供します。ステートレスアプリケーションを含むステートフルなアプリケーションには、ピアクラスターに同じものをデプロイする前に準備が必要です。

メディアタイプに基づく異なるストレージクラスの可用性

ユーザーは、クラスターで混合メディアを使用してコストを削減でき、重要なワークロードにはパフォーマンスの良いデバイスを、他のワークロードには低速なデバイスを指定できるようになりました。

柔軟なデバイス

ユーザーは、使用可能なデバイスを柔軟に判断できるようになりました。Red Hat は、開発プレビューでベアメタルのインストールへの設定変更なしに、最大 16TB のドライブサイズをサポートします。

OSD の write-ahead ロギング PVC のサポート

OpenShift Container Storage は、Bluestore の rocksdb データベースと rocksdb write-ahead ログを複数の異なるデバイスに分離する際に OSD のデプロイをサポートするようになりました。OSD の HDD でのパフォーマンスは、その最小 IOPS により、SSD と比較して低くなります。このため、ユーザーは HDD の特定の OSD のメタデータに SSD を使用してパフォーマンスを強化できます。

RHCS クラスターでアクティブな mgr が変更されると、RGW メトリクスが利用できなくなる

アクティブな MGR が外部クラスターモードでダウンすると、OpenShift Container Platform (OCP) は、MGR が再びオンになった場合でも Red Hat Ceph Storage (RHCS) クラスターからの追加のメトリクスの収集を停止します。つまり、RADOS Object Gateway (RGW) メトリクスは、現在の MGR への接続が失われた場合に収集されなくなりました。

Vault の OSD キーは、OpenShift Container Storage クラスターのアンインストール時に削除されません。

現在、OSD のキー暗号化キーは、Vault Key/Value(K/V) シークレットエンジン API バージョン 2 が、KMS によるクラスター全体の暗号化に使用されている場合に、Openshift Container Storage クラスターの削除中に Vault からソフト削除されます。これは、キーのメタデータが依然として表示され、キーのバージョンをすべて取得できることを意味します。

MDS レポートがサイズの大きいキャッシュを報告する

以前のバージョンでは、Rook はアップグレード時に mds_cache_memory_limit を適用していませんでした。つまり、そのオプションが適用されていない OpenShift Container Storage 4.2 クラスターは正しい値 (通常は Pod のメモリー制限のサイズの半分) で更新されませんでした。そのため、standby-replay の MDS は、サイズの大きいキャッシュを報告する可能性があります。

柔軟なスケーリングと Arbiter の両方が有効になると、ストレージクラスターのフェーズは Ready になります。

Arbiter および柔軟なスケーリングが有効にされている場合、ストレージクラスター CR の仕様は正しくありせん。つまり、arbiter and flexibleScaling both can not be enabled というエラーについてのログやメッセージがある場合でも、ユーザーには READY 状態のストレージクラスターが表示されます。これは機能には影響しません。

Arbiter ノードに OpenShift Container Storage ノードラベルでラベル付けできない

Arbiter ノードは、OpenShift Container Storage ノードラベル cluster.ocs.openshift.io/openshift-storage でラベル付けされた場合に、有効な Arbiter 以外のノードとみなされます。これは、Arbiter 以外のリソースの配置が確定されないことを意味します。この問題を回避するには、Arbiter リソースのみが Arbiter ノードに配置されるように Arbiter ノードに OpenShift Container Storage ノードラベルを付けないようにします。

noobaa-db-pg-0 の問題

noobaa-db-pg-0 は、ホストしているノードがダウンしても他のノードに移行しません。NooBaa は、ノードがダウンすると noobaa-db-pg-0 Pod の移行がブロックされるために機能しません。

親 PVC よりもサイズが大きい Restore Snapshot/Clone 操作により無限ループが生じる

Ceph CSI は、親 PVC よりもサイズが大きい場合にスナップショットの復元やクローンの作成をサポートしません。そのため、サイズが多い Restore Snapshot/Clone 操作により、無限ループが生じます。この問題を回避するには、保留中の PVC を削除します。よりサイズの大きな PVC を取得するには、使用中の操作に基づいて以下のいずれかを実行します。

Ceph のステータスは、ディスクの交換後の HEALTH_WARN です。

ディスクの交換後に、すべての OSD Pod が稼働している場合でも、1 daemons have recently crashed 警告が見られます。この警告により、Ceph のステータスが変更されます。Ceph のステータスは、HEALTH_WARN ではなく HEALTH_OK である必要があります。この問題を回避するには、rsh を ceph-tools に実行し警告を非表示にすると、Ceph の正常性は HEALTH_OK に戻ります。

デバイス置き換えのアクションは、暗号化された OpenShift Container Storage クラスター用のユーザーインターフェイスから実行できません。

暗号化された OpenShift Container Storage クラスターでは、検出の結果 CR は Ceph OSD (Object Storage Daemon) がサポートするデバイスを検出します。これは、Ceph アラートで報告されるデバイスとは異なります。アラートをクリックすると、ユーザーには Disk not found というメッセージが表示されます。不一致があるため、コンソール UI は OpenShift Container Storage ユーザー用にディスク置き換えオプションを有効にすることはできません。この問題を回避するには、デバイスの置き換え ガイドにあるように、障害のあるデバイスの置き換えに CLI 手順を使用します。

新たに復元された PVC をマウントできない

一部の OCP ノードが 8.2 よりも前のバージョンの Red Hat Enterprise Linux で実行され、PVC が復元されたスナップショットが削除される場合、新たに復元された PVC はマウントできません。この問題を回避するには、復元された PVC が削除されるまで PVC を復元するスナップショットを削除しないでください。

start replacement をクリックする前のディスクのステータスは、replacement ready です。

ユーザーインターフェイスは、両方のディスクの名前が同じ場合に、異なるノードまたは同じノードで生じる新たな障害と、以前に発生したディスクの障害を区別することができません。同じ名前である生じる問題により、ユーザーインターフェイスではこの新たに障害が生じたディスクはすでに置き換えられていると見なされるため、ディスクの置き換えはできません。この問題を回避するには、以下の手順に従います。