コンパクトなデプロイメント一般公開サポート

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

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

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

ストレージクラスの一般公開サポートによる永続ボリュームの暗号化

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

VMware プラットフォームのプロビジョニングされたストレージの使用

VMware がホストする OpenShift Container Platform のシンプロビジョニングされたストレージに加えて、パフォーマンスとセキュリティーが向上します。OpenShift Container Storage でシックプロビジョニングのストレージを使用するように柔軟性が必要な場合、OpenShift Container Platform で zeroedthick または eagerzeroedthick 形式でストレージクラスを作成する必要があります。OpenShift Container Storage クラスターサービスの作成時に、デフォルトのシンストレージクラスに加えて作成されるストレージクラスを選択するオプションを取得できます。

新しいプール管理ユーザーインターフェイス

新しい管理機能には、シンプルで、ストレージクラスの作成や、自動的にアタッチされたプールの作成や、既存のプールの特性を更新したい場合 (圧縮、レプリカなど) を簡単に使用できます。この機能は、既存のストレージクラス設定の代わりではありません。詳細は、ストレージリソースの管理および割り当てガイドの ブロックプール の章を参照してください。

IBM Power Systems および IBM Z インフラストラクチャーでのエアギャップ (オフライン環境) のサポート

OpenShift Container Storage 4.8 のデプロイメントがエアギャップされた環境で、インターネット接続のない環境で実行できるようになりました。

IBM Power Systems および IBM Z インフラストラクチャーでの Multicloud Object Gateway

IBM Power Systems および IBM Z インフラストラクチャー上の Red Hat OpenShift Container Storage 4.8 では、オブジェクトワークロードにマルチクラウドおよびハイブリッド機能を提供する Noobaa のマルチクラウドオブジェクトサービスのサポートが追加されました。デフォルトで、Multicloud Object Gateway はクラウドネイティブまたは RGW のデフォルトのバッキングストアを使用します。

IBM Power Systems の暗号化されたストレージデータ

管理者は、デプロイメントプロセスの一部として OpenShift Container Storage 4.8 クラスターのすべてのデータを暗号化することを選択できるようになりました。詳細は、データ暗号化オプション を参照してください。

IBM Z インフラストラクチャーでの DASD のサポート

DASD が IBM Z インフラストラクチャーのストレージノードでサポートされるようになりました。

1 つ以上の OSD 要求を処理する時間が長い場合にユーザーに通知を改善するために新規アラートを追加

このアラートは、OpenShift Container Storage の管理者に低速な操作について通知することが重要です。これは、極端の負荷、低速なストレージデバイス、またはソフトウェアのバグを示します。ユーザーは、Ceph のステータスを確認して低速さの有無を確認することができます。

ClusterObjectStoreState アラートメッセージは、RADOS Object Gatewa y(RGW) が利用できない場合に生成されます。

以前のバージョンでは、RADOS Object Gateway (RGW) が利用できないか、または正常ではない場合、ClusterObjectStoreState アラートメッセージは生成されませんでした。OpenShift Container Storage Operator に実装される修正では、RADOS Object Gateway (RGW) が利用できない場合に、または正常ではない場合に ClusterObjectStoreState アラートが表示されるようになりました。

プールで圧縮を有効または無効にする機能

OpenShift Container Storage 4.8 以降では、ユーザーインターフェイスを使用して、プールで圧縮を有効または無効にすることができます。

OpenShift Container Storage ユーザーインターフェイスを使用して namespace バケットを作成する機能を追加

namespace バケットは、OpenShift Container Platform ユーザーインターフェイスを使用して追加できます。namespace バケットは、クラウドまたは S3 と互換性のあるストレージ (オンプレミス) の既存オブジェクトバケットの集計ビューを提供します。ユーザーインターフェイスを使用して namespace バケットを追加する方法の詳細は、OpenShift Container Platform ユーザーインターフェイスを使用した namespace バケットの追加 を参照してください。

初回のデプロイメント時に利用可能なすべてのデバイスの使用およびローカルストレージデバイスのスケールアップ

割り当てられたモードのデプロイメントですべてのローカルストレージデバイスが、ローカルで利用可能なストレージデバイスをすべて使用するようになりました。同様に、容量を追加してスケールアップする際に、利用可能なストレージデバイスをすべて追加できます。

ノードドレイン (解放) 以外の理由により OSD が停止している場合に、障害ドメインに no-out フラグを追加しないようにします。

ディスク障害により OSD がダウンすると、障害ドメインに no-out フラグが追加されます。これにより、OSD が標準の ceph mon_osd_down_out_interval を使用してマークアウトされないようにします。今回の更新により、ノードのドレイン以外の理由で OSD がダウンすると、pgs が正常でなくなると、他の障害ドメインでブロックする PodDisruptionBudget が作成され、さらにノードがドレインされないようにするようになります。この場合、noout フラグはノードに設定されません。OSD がダウンしているものの、すべての pgs が active+clean の場合、クラスターは完全に正常なものとして処理されます。デフォルトの PodDisruptionBudget (maxUnavailable=1 を使用) は再び追加され、ブロックするものが削除されます。

Arbiter を使用した障害復旧

今回のリリースにより、Red Hat OpenShift Container Storage は、ストレージクラスターの作成時に、3 番目のゾーンを arbiter の場所とした上で、単一クラスターを 2 つのゾーンに展開できるように Metro-DR ストレッドクラスター (arbiter) 機能を提供するようになりました。

マルチネットワークプラグイン (Multus) のサポート

ネットワークの分離によるセキュリティーとパフォーマンスを向上させるためにマルチコンテナーネットワークプラグイン (multus) を使用する機能をサポートします。この機能は、ベアメタルおよび VMWare デプロイメントでのみテストされています。multus の詳細は、Multi network plug-in (Multus) support を参照してください。

ホストグループごとのデータ分離

ワークロードは特定の分離された IO パスを使用し、特定のストレージノードに分散して、部分的なクラスターに障害が発生した場合や、テナントを分離させる場合にの影響を制限できます。

地域による障害復旧

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

オブジェクトストレージデバイスの重みおよび Pod のアフィニティー設定

OpenShift Container Storage 以外のデバイスでパーティション化されたディスクを効率的に使用して、ワークロードをブロックしずに容量の使用率を最大化できるようになりました。オペレーティングシステム用の専用パーティションを持つパーティション化デバイスなど、ホストマシン上のすべてのソリッドステートドライブ (SSD) にオブジェクトストレージデバイス (OSD) を割り当てることができます。同じ物理デバイスを共有するので、効率を向上させるために、OSD の負荷を軽減することができます。負荷を減らすために、OSD の重みおよび Pod のアフィニティーパラメーターを Storage Cluster CR に設定できます。

OpenShift Container Storage コンポーネントのデプロイメントでの柔軟性

コンポーネントデプロイメントの柔軟性により、デプロイメント中に、コンポーネントのマルチクラウドオブジェクトゲートウェイ、RGW、および CephFS を無効にできるようになりました。OpenShift Container Storage の作成後にこれらのコンポーネントを有効または無効にすることもできます。この柔軟性により、Amazon S3 を使用する際にリソースコストを削減できます。

Arbiter と柔軟なスケーリングを同時に有効にすることはできません。

Arbiter と柔軟なスケーリングの両方が有効にされると、ログやエラー arbiter and flexibleScaling both can't be enabled のメッセージが存在する場合でも、ストレージクラスターは READY 状態のままと表示されませんでした。これは、ストレージクラスター CR の正しくない仕様が原因で発生します。今回の更新により、ストレージクラスターは正しいエラーメッセージを出して ERROR の状態になりました。

バケットは、ライブラリーでクリーンアップが必要な場合に常に削除されます。

以前のバージョンでは、OBC の作成に失敗しました。lib-bucket-provisioner は再試行前にクリーンアップ目的で削除要求をプロビジョナーに送信していました。NooBaa プロビジョナーはオブジェクトバケットの回収ポリシーを確認しますが、場合によっては基礎となるバケットは削除されませんでした。今回の更新により、クリーンアップのシナリオにおいて、基礎となるバケットが回収ポリシーに関係なく削除されるようになりました。

アタッチされた各 OSD の設定の収集

以前のバージョンでは、各 OSD の詳細な設定を特定する方法はありませんでした。今回の更新により、must-gather は OSD のすべての設定を収集し、デバッグをさらに改善するようになりました。

gRPC メトリクスがデフォルトで無効になりました

以前のバージョンでは、cephcsi Pod はデバッグ目的でリモートプロシージャーコール (gRPC) メトリクスを公開していました。cephcsi ノードプラグイン Pod は、cephcsi ノードプラグイン Pod が実行されているノードで、CephFS のホストポート 9091 と RBD 用のホストポート 9090 を使用していました。そのため、cephcsi Pod は起動しませんでした。今回の更新により、gRPC メトリクスはデフォルトで無効になり、cephcsi Pod はノードプラグイン Pod が実行されているノードでポート 9091 および 9090 を使用しなくなりました。

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

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

新たに復元された PVC がノードにマウント可能に

以前のバージョンでは、Ceph-CSI ドライバーのバグにより、Red Hat Enterprise Linux バージョンの 8.2 よりも少ないノードで、削除された親スナップショットで新たに復元された PVC をマウントする際に (深いフラット化機能がない)、誤った RBD image not found エラーが発生しました。この問題は、Red Hat Enterprise Linux のバージョンが 8.2 未満のノードにマウントする前に、新たに復元された PVC をフラット化することで修正されました (ディープフラット化機能がない場合)。

信頼性のある mon クォーラム

以前のバージョンでは、mon フェイルオーバー中に Operator が再起動されると、Operator は新しい mon を誤って削除する可能性があります。したがって、Operator が新しい mon を削除した場合、mon のクォーラムはリスクとして必要になります。今回の更新により、Operator は mon フェイルオーバーが進行中の状態を復元し、Operator の再起動後に mon フェイルオーバーを適切に完了するようになりました。ノードのドレインおよび mon フェイルオーバーのシナリオで mon クォーラムがより信頼できるようになりました。

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

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

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

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

CephCluster リソースでのモニターリング仕様がリセットされる

ocs-operator が再起動するか、またはアップグレード時には常に監視仕様は空になります。これは機能への影響はありませんが、モニターリングエンドポイントの詳細が必要な場合は、空にします。

noobaa-db-pg-0 の問題

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

プラグイン Pod が削除されると、ノードの再起動が行われるまでデータはアクセス不可能になります。

この問題は、csi-cephfsplugin Pod が再起動すると、マウントの netns が破棄されるため、csi-cephfsplugin はすべてのマウントされたボリュームをロックします。この問題は、multus を有効にしてクラスターでのみ見られます。

暗号化パスフレーズは、スナップショットからボリュームを復元するためのソース KMS に保存されます。

親と復元された PVC の異なるバックエンドパスを持つ StorageClass が異なる場合、復元された PVC は Bound 状態に行われ、スナップショットから KMS 設定のバックエンドパスに暗号化パスフレーズが作成されます。暗号化パスフレーズの確認は 2 番目の StorageClass パスにリンクされた設定を使用するので、復元された PVC は Pod に割り当てられないようにすることができます。この場合、暗号化パスフレーズはバックエンドパスに見つかりません。

キーは、kv-v2 シークレットエンジンを使用する場合に、暗号化された PVC を削除した後に Vault に一覧表示されます。

HashiCorp Vault は、保存されたキーの削除先である key-value store v2 の機能を追加しました。これにより、削除されたキーのメタデータが別のステップで削除されない場合にコンテンツを回復できます。Hashicorp Vault のシークレットに key-value v2 ストレージを使用する場合に、ボリュームを削除すると、KMS から暗号化パスフレーズのメタデータは削除されません。後で暗号化パスフレーズを復元することが可能です。これらの部分的に削除されたキーは、KMS によって自動的にクリーンアップされません。

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

Ceph CSI は、親 PVC よりもサイズが大きい場合にスナップショットの復元やクローンの作成をサポートしません。そのため、サイズが多い Restore Snapshot/Clone 操作により、無限ループが生じます。この問題を回避するには、保留中の PVC を削除します。より大きい PVC を取得するには、仕様しちえる操作に基づいて以下のいずれかを完了する必要があります。スナップショットを使用する場合、既存のスナップショットを復元し、親 PVC と同じサイズのボリュームを作成し、これを Pod に割り当て、PVC を必要なサイズに拡張します。詳細は、Volume snapshots を参照してください。Clone を使用する場合、親 PVC のクローンを作成し、親 PVC と同じサイズのボリュームを作成し、これを Pod に割り当て、PVC を必要なサイズに拡張します。詳細は、ボリュームのクローン作成を参照してください。

PVC はスナップショットから復元するか、シックプロビジョニングされた PVC からクローンがプロビジョニングされていません。

シックプロビジョニングされた PVC のスナップショットが thic provisioning のストレージクラスを使用して復元されると、復元されたボリュームはプロビジョニングされません。復元される PVC は、シックプロビジョニングなしで Bound 状態に達します。この問題は、RHCS-5.x が使用される場合にのみ修正できます。以前の Ceph バージョンは、ゼロ入力データブロックのコピーをサポートしません (シックプロビジョニング時に使用)。

プロビジョニングが進行中に保留中の PVC および RBD プロビジョナーリーダー Pod を削除すると、古いイメージと OMAP メタデータが残されます。

RBD PVC がプロビジョニングされている場合、Persistent Volume Claim (永続ボリューム要求、PVC) は Pending 状態になります。RBD プロビジョナーリーダーおよび PVC 自体が削除されても、RBD イメージと OMAP メタデータは削除されません。

ストレージクラスターの使用が 85% に達するか、PVC を削除した後にも、プロビジョニングは停止しませんでした。

RBD シック PVC がプロビジョニングされている間にストレージクラスターの使用状況が 85% に達すると、プロビジョニングは保留中の PVC を削除して自動的に停止しません。また、保留中の PVC を削除しても RBD イメージは削除されません。

kv-v2 が使用されると、Vault の OSD のキーはアンインストール時に削除されません

キー暗号化キーデータは、Vault K/V Secret エンジンがバージョン 2 の場合に、クラスターの削除時に Vault からソフト削除されます。つまり、任意のバージョンのキーを取得できるため、削除が元に戻されます。メタデータは引き続き表示されるので、鍵を復元できます。これによって不整合が生じても、vault コマンドに destroy 引数を指定して手動でキーを削除できます。

CephBlockPool の削除がスタックし、新規プールの作成をブロックします。

Multus が有効なクラスターでは、Rook Operator にはネットワークアノテーションがないため、OSD ネットワークにアクセスできません。つまり、プールのクリーンアップ中に rbd タイプコマンドを実行すると、OSD と通信できないためコマンドがハングします。回避策として、toolbox を使用して CephBlockPool を手動で削除します。

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

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

volumeMode をブロックとして持つ PVC の false 通知

Kubernetes の変更により、OpenShift Container Platform の Prometheus アラートでリグレッションが発生します。この変更は以下に影響があります。

ストレージクラスターの再インストール中に cephobjectstore の ceph オブジェクトが作成されると、Arbiter ストレージクラスターのインストール後に重大なアラート通知が送信されます。

CephCluster および 1 つ以上の CephObjectStores を含むストレージクラスターでは、CephCluster リソースがすべて CephObjectStore リソースを完全に削除する前に削除しても、Rook Operator はメモリー内の CephObjectStore(s) に関する接続の詳細を保持できます。同じ CephCluster および CephObjectStore(s) が再作成されると、CephObjectStore(s) は Failed の状態になる可能性があります。