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

管理者は、デプロイメントプロセスの一部として OpenShift Container Storage 4.6 クラスターのすべてのデータを暗号化することを選択できるようになりました。詳細は、「Data encryption options」を参照し、OpenShift Container Storage ドキュメントを参照してクラウドまたはベアメタル環境にデプロイすることができます。

アプリケーション向けの柔軟な環境

ユーザーは、カスタムストレージクラスにマップする複数のストレージプールを作成できるようになりました。

Persistent Volume Claim (永続ボリューム要求、PVC) の拡張

OpenShift Container Storage 4.5 では、Persistent Volume Claim（永続ボリューム要求、PVC）をテクノロジープレビュー機能として拡張する機能が導入されました。これにより、永続ストレージリソースの管理の柔軟性が向上します。この機能は、OpenShift Container Storage 4.6 の時点で、Persistent Volume Claim (永続ボリューム要求、PVC) が新規であるか、既存であるかに拘らず、PVC の拡張を完全にサポートします。

マルチクラウドオブジェクトバケットの統合ビュー

オブジェクトバケットを namespace バケットに関連付け、関連付けられたバケット全体ですべてのオブジェクトを表示し、現時点で優先されるストレージプロバイダーへの書き込みのみを行います。詳細は、「Configuring namespace buckets」を参照してください。

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

負荷の増減が生じる場合の自動スケーリングのプロビジョニングにより、S3 の負荷のリソース管理のパフォーマンスおよび保守性が改善されました。

フィルターを使用した自動デバイスの検出

今回のリリースにより、VMware およびベアメタルインフラストラクチャーのローカルストレージデバイスを使用して OpenShift Container Storage のデバイスをデプロイし、追加する際に、UI で利用可能なすべてのストレージデバイスを表示 (またはフィルター) できるようになりました。

障害のあるローカルストレージデバイスを簡単に置き換える方法

今回のリリースにより、UI を使用して VMware およびベアメタルインフラストラクチャーの障害のあるローカルストレージデバイスを置き換えることができるようになりました。ユーザーには、ディスクのステータスを特定し、障害のあるデバイスの交換を実行できるディスクのインベントリー一覧が提供されます。また、ダッシュボードおよびアラート通知により障害のあるディスクの置き換えを開始できます。

ボリュームスナップショット

開発者および管理者は、ボリュームスナップショットを取得できます。ボリュームのスナップショットとは、特定の時点におけるクラスター内のストレージボリュームの状態です。これらのスナップショットは、毎回フルコピーを作成する必要がないので、より効率的にストレージを使用するのに役立ち、アプリケーション開発のビルディングブロックとして使用できます。ボリュームスナップショットは、新規の Persistent Volume Claim（永続ボリューム要求、PVC）として復元できます。

ボリュームのクローン

OpenShift Container Storage 4.6 の永続ボリュームのクローンを作成して、クローン作成したこの永続ボリュームを、別のアプリケーション (RHOCP 4.6 上) での読み取り/書き込み操作に、パフォーマンスやアプリケーションに影響を与えることなく使用します。

RADOS Gateway のステータスおよび正常性

Object Service ダッシュボードでは、RADOS Gateway のステータスおよび正常性についての情報を提供するようになりました。詳細は、「Viewing metrics in the Object Service dashboard」を参照してください。

PV 作成時間の短縮

Ceph CSI ドライバー ceph-csi は、ceph のコマンドラインを呼び出す代わりに、Red Hat Ceph Storage に対してネイティブ Go バインディングを使用するように移行しました。これにより、PV の作成時間が短縮されます。

MDS および RGW 設定は、外部クラスターのインストール後に指定できます。

以前のバージョンでは、MDS および RGW 設定は、外部クラスターの作成時にのみ対応していました。今回の更新により、外部シークレットを更新して、MDS および RGW 設定を後で提供できるようになりました。OpenShift Container Storage Operator は変更を調整して、それに応じてリソースを更新します。詳細は、「Adding file and object storage to an existing external OpenShift Container Storage cluster」を参照してください。

Telemetry

RADOS Block Device (RBD) および Ceph File System (CephFS) についての新たな使用情報が Telemetry 経由で収集されるようになりました。詳細は、「Information collected by Telemetry」を参照してください。

アンインストール方法の強化

ユーザーが使用しやすい方法で、データなどが残されないように OpenShift Container Storage 4.6 をアンインストールします。

一貫性のある総合的なドキュメント

管理関連のガイドが小規模なブックに再編成され、関連する情報を見つけやすくなりました。

OpenShift Container Storage バージョン 4.x からバージョン 4.6 へのシームレスなアップグレードプロセス

OpenShift Container Storage のお客様は、既存のクラスターを OpenShift Container Storage 4.6 に簡単にアップグレードできる方法を使用できるようになりました。詳細は、「Updating OpenShift Container Storage」を参照してください。

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

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

ディスクの交換後も以前の OSD Pod が Terminating の状態のままになる

以前の OSD Pod は、ディスクの交換手順が済んだ後に Terminating の状態のままになることがありました。今回の更新により、rook-ceph-osd Pod が Terminating 状態にある場合、force オプションを使用して Pod を削除できるようになりました。

MAX HPA の値が 1 を超えても警告がトリガーされない

以前の Red Hat OpenShift Container Storage のバージョンでは、Pod の自動スケーリング機能が利用できませんでした。そのため、MAX HPA の値が 1 を超えることができず、この値を超えると、アラートがトリガーされていました。今回の更新により、この機能が有効になり、アラートがトリガーされなくなりました。

ceph-mgr が原因のエラーが要求時に発生しなくなる

以前のバージョンでは、一部の ceph-mgr モジュール (fs) が、最初の ceph-mgr Pod 作成の一貫として渡された MON に常に接続されていました。これが原因で、MON エンドポイントが変更されると、これらのモジュールは、Red Hat Ceph Storage クラスターに接続して CephFS のプロビジョニングやステージングなどの各種要求に対応できず、エラーが発生していました。今回の更新により、ceph-mgr が変更されると MON エンドポイントも更新され、Pod 作成時に渡された最初の MON アドレスだけに依存しないように修正され、ceph-mgr 操作が想定通りに機能するようになりました。

RGW エンドポイントが http モードで実行しなくなる

以前のリリースでは、外部の Python スクリプトは、指定の RGW エンドポイントが到達できるかどうか常に確認しようとしていましたが、TLS が有効な https URL はサポート対象外でした。これが原因で、ユーザーが強制的に RGW エンドポイントを http モードで実行するため、セキュリティーが侵害されていました。外部スクリプトが修正され、https の URL 到達性チェックが含まれるようになりました。

破損したリンクを UI から削除

以前のバージョンでは、Multicloud Object Gateway ドキュメントが古くなったことが原因で UI のリンクが破損していました。これらのリンクが削除され、すべての情報が OpenShift Container Storage ドキュメントに含まれるようになりました。

OpenShift Container Storage Pod が OpenShift Container Storage のラベルが付けられていないノードでスケジュールされなくなる

以前のバージョンでは、OpenShift Container Storage Pod の内、ラベルがついたノードに所属しているにも拘らず、OpenShift Container Storage のラベルが指定されていないノードでスケジュールされているものがありました。今回の修正により、これらの Pod に適切な NodeAffinity が追加され、この問題は解決されました。

CSI ドライバーおよびその他のリソースが想定外に非表示にならなくなる

以前のバージョンでは、CSI ドライバーの Rook には無効な所有者の参照がありました。そのため、OpenShift Container Platform は openshift-storage namespace の CSI ドライバーおよび他のリソースを定期的に誤ってガベージコレクションしていたため、リソースが想定外に非表示になっていました。CSI ドライバーに対する Rook の無効な所有者参照が削除され、CSI ドライバーおよび他のリソースが消えなくなりました。

MON PDB が調整されてノードのドレイン (解放) が可能に

以前のリリースでは、MON の PodDisruptionBudget のリコンサイラーは静的でした。PDB は MON 数に基づいて 1 回のみ作成されますが、MON 数が変更されても更新されません。OpenShift Container Storage バージョン 4.3 および 4.4 では、クラスターのノード数が 5 つの場合には、デフォルトの MON 数は 5 に増加していました。OpenShift Container Storage バージョン 4.5 以降では、ノード数が異なる場合でも、MON 数が 3 に保たれるようになりました。OpenShift Container Storage バージョン 4.3 および 4.4 から 4.5 以降にアップグレードすると、ALLOWED DISRUPTIONS は ０ になります。これにより、ノードのドレイン (解放) が不可能でした。今回の更新により、MON PDB リコンサイラーが、MON 数が変更されると、 MON の PDB が新規作成するようになりました。そのため、ALLOWED DISRUPTIONS は常に 1 で、ノードのドレインが可能です。

パブリックアクセスポリシーのバケットへの設定時の問題解決

以前のリリースでは、バケットにパブリックアクセスポリシーを設定すると、変換で問題が発生し、希望のポリシーが正しく設定されませんでした。この変換の問題は修正され、必要なポリシーが正しく設定され、パブリックアクセスを設定できます。

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

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

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

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

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 のデプロイおよび管理』ガイドを参照してください。

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

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

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

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

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

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

nooba-db の問題

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

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

OpenShift Container Platform アラートであるPodDisruptionBudget アラートは、オブジェクトストレージデバイス (OSD) について継続的に表示されます。このアラートは無視できます。Red Hat Openshift Container Platform ドキュメントの「 クラスターアラートの管理」セクションの手順に従ってこのアラートをサイレンスにすることができます。

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

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

Prometheus はポート 9283 でのみリッスンする

外部クラスターにある ceph-mgr の Prometheus サービスは、ポート 9283 をリッスンするように想定されています。他のポートはサポート対象外です。Red Hat Ceph Storage の管理者は、Prometheus エクスポーターにはポート 9283 だけを使用する必要があります。

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

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

volume snapshotclass がない場合に PVC を volume snapshot から PVC を作成できない

volume snapshotclassを削除すると、volume snapshot status が Error に変わります。そのため、volume snapshot から PVC を復元できません。この問題を回避するには、volume snapshotclass をもう一度作成します。

ローカルストレージベースのデプロイメントのデバイス検出ウィザードでは、テイントのマークが付けられたノードを検出できない

Openshift Container Platform v4.6 のユーザーインターフェースを使用してローカルストレージベースのデプロイメントが可能になりました。ストレージクラスターの作成時に、Red Hat OpenShift Container Storage ノードにテイントの node.ocs.openshift.io/storage="true":NoSchedule が localvolumeset とマークされており、localvolumediscovery のカスタムリソースに、必要な容認 (toleration) が含まれていない場合には、ノードを検出できません。回避策は、「Red Hat ナレッジベースソリューション」を参照してください。

デバイス置き換えのアクションは、暗号化された OpenShift Container Storage クラスターについて UI で実行できません。

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