ユーザーインターフェイス、製品コンポーネント、およびドキュメントのリブランディング

オープンソースの Ceph テクノロジーに基づく OpenShift Container Storage では、導入以来、コンテナー化されたハイブリッドクラウド環境でのスコープおよび基本的なロールを拡大してきました。これらの基本的なインフラストラクチャーの特徴をより適切に反映するために、OpenShift Container Storage は OpenShift Data Foundation になりました。

Multicloud Object Gateway バケットレプリケーション

1 つの MulticloudObject Gateway(MCG) バケットから別の MCG バケットへのデータレプリケーションは、より高い復元力とより優れたコラボレーションオプションを提供します。これらのバケットは、サポート対象のストレージソリューションでサポートされるデータバケットまたは namespace バケットのいずれかになります。

プール圧縮メトリクスを表示する機能

本リリースでは、プール圧縮メトリクスを表示できます。このメトリクスは、保存したストレージ容量、プール圧縮の有効性、および容量消費への影響に関する情報を提供します。本リリースで利用可能なプールごとのメトリクスは、コストを削減し、データをより効率的に消費できるようにする情報を提供します。また、効果がない場合は、圧縮を無効にすることができます。

Multicloud Object Gateway エンドポイント Pod の自動スケーリング

Multicloud Object Gateway エンドポイント Pod 機能の自動スケーリングを使用し、負荷の増減に応じてリソースの調整を自動化できます。これにより、S3 負荷の実稼働リソースを管理するためのパフォーマンスとサービス性が向上します。

プラグ可能な外部ストレージのデプロイメントおよびモニターリングレイヤー (IBM FlashSystem®)

本リリースでは、OpenShift Data Foundation を使用して IBM FlashSystem® ストレージに接続し、これを監視することができます。OpenShift Data Foundation は、基礎となるストレージと OpenShift Data Foundation データ層の両方に単一ビューを提供する一方で、IBM FlashSystem をファイルおよびオブジェクトストレージに拡張します。

ストレージクラスターが満杯になると、データの削除が許可される

以前は、ストレージクラスターが満杯になると、設定ファイルの読み取り中に Ceph Manager がプールパーミッションのチェックでハングしていました。Ceph Metadata Server (MDS) では、Ceph OSD が満杯になると書き込み操作の実行が許可されていなかったため ENOSPACE エラーが発生しました。ストレージクラスターがフル比率に達すると、ユーザーは CephManager ボリュームプラグインを使用して領域を解放するためのデータを削除することができませんでした。

スタンドアロンの Multicloud Object Gateway コンポーネントのデプロイメント

今回のリリースにより、Multicloud Object Gateway コンポーネントのみのスタンドアロンモードで OpenShift Data Foundation をデプロイできるようになりました。このモードでは、StorageCluster に付随する CephCluster がないため、Multicloud Object Gateway は Ceph ベースのストレージボリュームを使用していません。

ノードに障害が発生した際、Core Pod および DB Pod の移行が有効になる

OpenShift Container Platform は、ノードが削除されない限り、そのノードを切断済みとしてマークしません。その結果、ステートフルセットである Core Pod および DB Pod は、このような障害が発生したノードで自動的に削除されません。今回の更新により、ノードに障害が発生した場合、DB Pod および Core Pod はエビクトされ、新しいノードに移行されるようになりました。

別のプールへのボリュームスナップショットの復元

今回の更新により、Persistent Volume Claim(永続ボリューム要求、PVC) のボリュームスナップショットを、親ボリュームとは異なるプールに復元できるようになりました。以前のバージョンでは、ボリュームスナップショットは同じプールにのみ復元できました。

既存のプールで複数のファイルシステムが作成されない

今回の更新で、filesystem.yaml の作成後に、filesystem.yaml を削除または再作成した場合でも、既存のプールを持つ複数のファイルシステムが作成されなくなりました。これにより、データの損失を回避できます。

Vault の秘密鍵/値ストアバージョンの自動検出

今回の機能拡張により、Vault の秘密鍵/値ストアバージョンは自動検出されるようになりました。

HashiCorp Vault の VAULT_BACKEND パラメーターの設定が可能に

今回の更新により、HashiCorp Vault で使用されるバックエンドのタイプを選択するために VAULT_BACKEND パラメーターを設定できるようになりました。HashiCorp Vault によって使用されるバックエンドの自動検出は、常に正しく機能するとは限りません。一般的ではない設定の場合、自動的に検出された設定パラメーターが正しく設定されていない可能性があります。VAULT_BACKEND パラメーターを設定できるようにすることで、一般的ではない設定で特定のタイプのバックエンドを使用するように強制することができます。

Multicloud Object Gateway CLI での時間の出力の人間が判読できる形式

今回のリリースにより、Multicloud Object Gateway(MCG)CLI での時間の出力は、分単位と秒単位ではなく、人間が判読できる形式 (days-hours-minutes-seconds) で表示されるようになりました。

PV 暗号化 - namespace ごとのサービスアカウント

Openshift Data Foundation 4.9 の時点で、サービスアカウントを使用して、テクノロジープレビューとして Vault でテナントを認証できます。詳細は、Persistent volume encryption を参照してください。

オーバープロビジョニングを制御するアラート

今回のリリースにより、オーバープロビジョニングのアラートを取得できるようになりました。これにより、特定のアプリケーション namespace に基づいて、ストレージクラスターから消費される Persistent Volume Claim(永続ボリューム要求、PVC) の量にクォータを定義することができます。詳細は、Overprovision level policy control を参照してください。

Advanced Cluster Management のある Regional-DR

Regional-DR ソリューションは、地域の障害発生時に自動化された "one-click" リカバリーを提供します。保護されたアプリケーションは、別のリージョンで利用可能な OpenShift Data Foundation クラスターのある指定された OpenShift Container Platform に自動的に再デプロイされます。

オブジェクトデータのクォータサポート

Object Bucket Claim(オブジェクトバケット要求、OBC) のクォータオプションを設定して、リソース不足を回避し、製品の使用量を増やすことができるようになりました。カスタムリソース定義 (CRD) の maxObjects および maxSize オプションを使用して、OBC の作成時にクォータを設定します。これらのオプションは、OBC の作成後に更新することもできます。

IPv6 サポート

今回のリリースにより、IPv6 の単一スタックおよびデュアルスタックが、OpenShift Data Foundation で使用できるようになりました。

アンインストール時に削除された Multicloud Object Gateway ストレージクラス

以前のバージョンでは、OpenShift Data Foundation デプロイメントの一部としてデプロイされた Multicloud Object Gateway(MCG) ストレージクラスは、アンインストール時に削除されませんでした。

OpenShift Container Storage のクォーラムが失われた場合の OpenShift Container Platform アラート

以前のバージョンでは、mon クォーラムが失われそうになると、CephMonQuorumAtRisk アラートが発生しましたが、クォーラムを失った後にトリガーされるアラートはありませんでした。このため、mon クォーラムが完全に失われても通知が送信されませんでした。

mon_data_avail_warn を 30 % から 15% に減らす

以前のバージョンでは、mon ストアが 30% 未満で、OpenShift Container Platform のイメージ用ガベージコレクターのしきい値である 15% と一致しなかった場合に、mon_data_avail_warnアラートがトリガーされていました。今回のリリースにより、mon ストアの場所で利用可能なストレージが 15% 未満および 30% 以上の場合に、アラートが表示されるようになりました。

初回のデプロイメントが OpenShift Container Storage 4.4 の場合、OSD Pod は何もログに記録しない

以前のバージョンでは、OpenShift Container Storage 4.4 がデプロイされたときに、Object Storage Daemon (OSD) ログが生成されませんでした。今回の更新により、OSD ログが適切に生成されるようになりました。

Multicloud Object Gateway は、新規デプロイメントで初期化できなかった

以前のバージョンでは、MongoDB から PostgreSQL への内部データベースの変更後に、Multicloud Object Gateway(MCG) が機能していなかったため、一意であるはずの重複エンティティーをデータベースに追加することができました (MongoDB は以前、重複エンティティーを阻止していました)。今回のリリースにより、重複するエンティティーは阻止されるようになりました。

PVC は、暗号化された親に 2 つの異なるバックエンドパスを使用する場合に復元される

以前のバージョンでは、ボリュームスナップショットから異なる暗号化 KMSID を持つ異なるストレージクラスに永続ボリューム要求 (PVC) を復元する際に、復元された PVC は Bound 状態になり、復元された PVC は Pod に割り当てられませんでした。これは、暗号化パスフレーズが親 PVC のストレージクラスの暗号化 KMSID config でコピーされたためでした。今回のリリースにより、復元された PVC の暗号化パスフレーズが、宛先ストレージクラスからの正しい暗号化 KMSID config でコピーされるようになりました。そのため、PVC は、親 PVC とは異なる暗号化 KMSID を持つストレージクラスに正常に復元されます。

ストレージクラスターが満杯になると、データの削除が許可される

以前は、ストレージクラスターが満杯になると、設定ファイルの読み取り中に Ceph Manager がプールパーミッションのチェックでハングしていました。Ceph Metadata Server (MDS) では、Ceph OSD が満杯になると書き込み操作の実行が許可されていなかったため ENOSPACE エラーが発生しました。ストレージクラスターがフル比率に達すると、Ceph Manager および ceph-volume プラグインを使用して、データを削除して領域を解放できませんでした。

キーは、kv-v2 シークレットエンジンの使用時に、暗号化された永続ボリューム要求 (PVC) を削除した後に Vault で完全に破棄される

HashiCorp Vault は、キー/値のストア v2 に機能を追加しました。この機能では、保存されたキーを削除すると、削除されたキーのメタデータが別の手順で削除されない場合にコンテンツを復元できます。Hashicorp Vault のシークレットにキー/値 v2 ストレージを使用する場合、ボリュームを削除しても、暗号化パスフレーズのメタデータは KMS から削除されませんでした。

Multicloud Object Gateway オブジェクトバケットの作成が Pending フェーズに進む

以前のバージョンでは、内部データベースを MongoDB から PostgreSQL へ変更した後に、一意であるはずの重複エントリーをデータベースに追加することができました (MongoDB は以前、重複エントリーを阻止していました)。その結果、バケット、バッキングストアなどの新規リソースの作成に失敗しました。今回のリリースにより、重複するエントリーは阻止されるようになりました。

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

以前のバージョンでは、Multus が有効になっているクラスターでは、Rook Operator はネットワークアノテーションがないため、Object Storage Daemon (OSD) ネットワークにアクセスできませんでした。その結果、OSD と通信できないため、プールのクリーンアップ中に rbd type コマンドがハングアップしていました。

スタンドアロンの Multicloud Object Gateway が接続に失敗する

以前は、内部 DB が MongoDB から PostgreSQL に変更されたため、Multicloud Object Gateway(MCG)CR が適切に更新されていませんでした。これにより、特定のフローで問題が発生しました。その結果、MCG コンポーネントは相互に通信できず、アップグレード時に MCG に障害が発生していました。

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

以前のバージョンでは、OpenShift Container Storage がアップグレードされると、モニターリングエンドポイントは外部の CephCluster のモニターリング仕様でリセットされていました。これは予想された動作ではなく、モニターリングエンドポイントが CephCluster に渡される方法が原因でした。今回の更新で、エンドポイントを渡す方法が変更になりました。CephCluster を作成する前に、エンドポイントは JSON シークレットである rook-ceph-external-cluster-details から直接アクセスされ、CephCluster 仕様が更新されます。その結果、OpenShift Container Storage のアップグレード後も、CephCluster のモニターリングエンドポイント仕様が適切な値で適切に更新されます。

hugepagesを有効にする際の noobaa-db-pg-0 Pod の CrashLoopBackOff 状態

以前のバージョンでは、OpenShift Container Platform クラスターで hugepages を有効にすると、Multicloud Object Gateway(MCG) データベース Pod が CrashLoopBackOff 状態になりました。これは、PostgreSQL の初期化が間違っていたことが原因でした。今回のリリースにより、MCG データベース Pod の PostgreSQL の初期化が修正されました。

Multicloud Object Gateway が新規の Object Bucket Claim(オブジェクトバケット要求) を作成できない

以前は、Multicloud Object Gateway(MCG)DB に対して作業する際のパフォーマンスの低下により、すべての MCG コンポーネントにバックプレッシャーが発生し、設定フローや I / O フローなどのシステム内のフローの実行に失敗していました。

割り当てられたリソースの確認に関する問題が原因でバケットが作成時に失敗する

以前のバージョンでは、作成時にバケットに割り当てられたリソースをチェックする問題が原因で、バケットの作成に失敗していました。バケット作成時のリソース検証の条件が修正され、バケットが想定どおりに作成されます。

NooBaa Operator は、アップグレード後も noobaa-db サービスを引き続き確認する

以前のバージョンでは、OpenShift Container Storage がバージョン 4.6 から更新された際、移行目的で新旧の noobaa-db StatefulSets を保持する必要がありました。コードは引き続きセットの両方の名前をサポートします。コードの小さな問題が原因で、古い noobaa-db StatefulSet に失敗のメッセージが生成されました。これにより、Operator は、関連性がなくなったにもかかわらず、古い noobaa-db StatefulSet のステータスを確認していました。

Multicloud Object Gateway(MCG)DB Pod の設定マップへの変更がアップグレード後に調整されない

以前のバージョンでは、MCG DB Pod の設定マップへの変更は、アップグレード後には適用されませんでした。DB Pod の設定マップから変数を適切に取得するようにフローが修正されました。

OpenShift Container Storage をバージョン 4.8 から 4.9 にアップグレードすると、odf-operator が見つからない

現在、ocs-operator のアップグレード中に、odf-operator をインストールせずに OpenShift Container Storage サブスクリプションのチャネルを変更すると、クラスターには OpenShift Data Foundation と Multicloud Object Gateway (MCG) のみがインストールされ、odf- operator' がクラスターから欠落します。

Multicloud Object Gateway の安全でないストレージアカウントは、TLS1.2 をサポートしない

Multicloud Object Gateway(MCG) は、Transport Layer Security(TLS)1.2 で設定された Microsoft Azure ストレージアカウントをサポートしません。その結果、1.2 のみのポリシーを持つストレージアカウントに、デフォルトのバッキングストアまたは新規のバッキングストアを作成することはできません。

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

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

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

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

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

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

Object Bucket Claim(オブジェクトバケット要求) メトリクスコレクターの cephobjectstoreuser の作成の自動化

現時点で、 ocs-metrics-exporter は prometheus-user という名前の Ceph オブジェクトストアユーザーを想定するため、Object Bucket Claim(オブジェクトバケット要求) メトリクスコレクションは失敗します。

StorageCluster および StorageSystem ocs-storagecluster は、StorageSystem のインストール時に数分間エラー状態になる

StorageCluster の作成中、ステータスが successful/ready 状態に移行する前に、エラー状態で表示される時間枠が少々あります。これは断続的ですが、想定される動作であり、通常は自動的に解決されます。

キーが大文字で指定されている場合には、テナント設定はバックエンドパスをオーバーライドしない

テナント namespace で設定される Key Management Service(KMS) プロバイダーオプションは、OpenShift Container Storage ユーザーインターフェイスがサポートするキー/値よりも高度なものです。そのため、テナント namespace に設定された KMS プロバイダーの設定オプションは、大文字ではなくキャメルケースとしてフォーマットする必要があります。openshift-storage namespace のオプションは大文字であるのに対して、テナント namespace のオプションはキャメルケースであることから、openshift-storage namespace の KMS プロバイダー設定およびテナント namespace の設定にアクセスできるユーザーは混乱する可能性があります。

フェイルオーバーされ、後で再配置された保護されたアプリケーションを削除しても、セカンダリーサイトまたはフェールオーバーサイトの RADOS ブロックデバイスイメージは削除されない

障害復旧 (DR) で保護されたワークロードを削除すると、セカンダリー DR クラスターで RADOS ブロックデバイス (RBD) イメージがリークされる可能性があります。削除されたイメージは、セカンダリークラスターで領域を占有します。この問題を解決するには、toolbox Pod を使用して、DR 保護に使用されなくなったセカンダリークラスターでイメージを検出し、クリーンアップします。この回避策により、セカンダリークラスターでの領域の回収が確保されます。

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

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

アクションを再配置すると、PVC は Termination 状態になり、ワークロードは優先クラスターに移動されない

障害復旧 (DR) で保護されたワークロードを再配置している間、ワークロードは現在のプライマリークラスターで停止せず、ワークロードの PVC は終了状態のままになります。これにより、Pod および PVC が優先クラスターに再配置されることを防ぎます。問題を回復するには、フェールオーバーアクションを実行して、ワークロードを優先クラスターに移動します。ワークロードは優先されるクラスターで復元されますが、アクションがフェイルオーバーであるため、データが損失されている場合があります。

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

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

Overprovision Level Policy Control はカスタムストレージクラスをサポートしません。

OpenShift Data Foundation は、overprovision-control の許可されるストレージクラスを Ceph サブタイプのみに制限します。その結果、ユーザー定義のストレージクラスが overprovision-control で使用されている場合、StorageCluster CRD は無効として定義され、そのストレージクラスには overprovision-control を持つことができません。