4.7 リリースノート

Red Hat OpenShift Container Storage 4.7

機能および拡張機能についてのリリースノート、既知の問題その他重要なリリース情報

概要

以下の Red Hat OpenShift Container Storage 4.7 リリースノートでは、新機能および拡張機能のすべて、主な技術上の変更点、および一般公開バージョンの既知の問題についてまとめています。

第1章 はじめに

Red Hat OpenShift Container Storage は、コンテナー環境向けに最適化されたソフトウェアで定義されるストレージです。これは OpenShift Container Platform の Operator として実行され、コンテナーの統合され、単純化された永続ストレージの管理を可能にします。

Red Hat OpenShift Container Storage は最新の Red Hat OpenShift Container Platform に統合され、プラットフォームサービス、アプリケーションの移植性、および永続性の課題に対応します。これは、Red Hat Ceph Storage、Rook.io Operator、および NooBaa の Multicloud Object Gateway テクノロジーを含む新たなテクノロジースタックに構築された、次世代クラウドネイティブアプリケーション向けの高度にスケーラブルなバックエンドを提供します。

Red Hat OpenShift Container Storage は、数多くの方法でアプリケーションのライフサイクル全体におけるユーザーエクスペリエンスを単純化し、強化する、信頼できるエンタープライズクラスのアプリケーション開発環境を提供します。

  • データベースのブロックストレージを提供します。
  • 継続的な統合、メッセージングおよびデータ集約のための共有ファイルストレージ。
  • クラウドファースト開発、アーカイブ、バックアップ、およびメディアストレージ用のオブジェクトストレージ。
  • アプリケーションとデータの飛躍的なスケーリングが可能です。
  • 永続データボリュームの割り当てと割り当て解除を加速的に実行します。
  • 複数のデータセンターまたはアベイラビリティーゾーンにクラスターを拡張します。
  • 包括的なアプリケーションコンテナーレジストリーを確立します。
  • データアナリティクス、人工知能、機械学習、ディープラーニング、および IoT (モノのインターネット) などの次世代の OpenShift ワークロードをサポートします。
  • アプリケーションコンテナーだけでなく、データサービスボリュームおよびコンテナー、さらに追加の OpenShift Container Platform ノード、Elastic Block Store (EBS) ボリュームおよびその他のインフラストラクチャーサービスを動的にプロビジョニングします。

1.1. 本リリースについて

Red Hat OpenShift Container Storage 4.7(RHSA-2021:2042 および RHSA-2021:2041 )をご利用いただけるようになりました。以下では、OpenShift Container Storage 4.7 に関連する新たな拡張機能、新機能、および既知の問題について説明します。

Red Hat OpenShift Container Storage 4.7 は、Red Hat OpenShift Container Platform バージョン 4.7 でサポートされます。詳細は、『Red Hat OpenShift Container Storage のサポート容易性および相互運用性ガイド』を参照してください。

OpenShift Container Storage 4.7 のリリースで、バージョン 4.4 のライフサイクルは終了します。詳細は、「Red Hat OpenShift Container Platform ライフサイクルポリシー」を参照してください。

第2章 新機能

このセクションでは、Red Hat OpenShift Container Storage 4.7 で導入された新機能について説明します。

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

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

IBM Power Systems での OpenShift Container Storage 4.6 の OpenShift Container Storage 4.7 へのアップグレードはサポートされません。OpenShift Container Storage 4.7 の IBM Power Systems は、グリーンフィールドインストールである必要があります。

IBM Power Systems でサポートされない機能が特定されています。サポートされない機能を確認してください。

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

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

IBM Z および LinuxONE での OpenShift Container Storage 4.6 の OpenShift Container Storage 4.7 へのアップグレードはサポートされません。OpenShift Container Storage 4.7 の IBM Z および LinuxONE は、グリーンフィールドインストールである必要があります。

IBM Z および LinuxONE でサポートされない機能が特定されています。サポートされない機能を確認してください。

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 に保存できます。

クラスター全体の暗号化は、KMS を使用せずに OpenShift Container Storage 4.6 でサポートされますが、KMS の有無にかかわらず OpenShift Container Storage 4.7 でサポートされます。

現時点で、HashiCorp Vault は唯一サポートされている KMS です。OpenShift Container Storage 4.7.0 および 4.7.1 では、HashiCorp Vault Key/Value (KV) シークレットエンジン API (バージョン 1) のみがサポートされます。OpenShift Container Storage 4.7.2 以降では、HashiCorp Vault KV シークレットエンジン API (バージョン 1 および 2) がサポートされるようになりました。

重要

Red Hat はテクノロジーパートナーと連携して、本書をお客様へのサービスとして提供します。ただし、Red Hat では、Hashicorp 製品のサポートを提供していません。この製品に関するテクニカルサポートについては、HashiCorp にお問い合わせください。

詳細は、データ暗号化のオプションを参照し、クラウドまたはオンプレミス環境のデプロイについて OpenShift Container Storage ドキュメントを参照してください。

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

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

柔軟なスケーリングは、internal-attached モードのストレージクラスター作成の場合にのみサポートされます。ストレージクラスターの柔軟なスケーリングは、Red Hat OpenShift Container Storage 4.7 の新規デプロイメントでのみ使用でき、アップグレードされたクラスターでは使用できません。

柔軟なスケーリングを有効にするには、3 未満のアベイラビリティーゾーンで 3 つ以上のノードを含むクラスターを作成します。OpenShift Web コンソールは、3 未満のアベイラビリティーゾーンに分散している 3 つ以上ノードを検出し、柔軟なスケーリングを可能にします。

詳細は、スケーリングについてのガイドを参照してください。

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

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 で利用可能になりました。

ツアーは、コンソールで階層化されたガイダンスを提供する新しい機能です。ガイド付きツアーは、コンソールの右上にある Overview セクションの Quick Starts で利用できます。

Quick Starts は、お客様が OpenShift Container Storage を検出および有効にするのに役立ち、ユーザーに OpenShift Container Storage 機能を最大限に使用する方法を示し、新規ユーザーのオンボーティングの時間を短縮します。

Quick Starts では、以下のさまざまなトピックについて説明します。

  • OpenShift Container Storage Operator のインストール
  • OpenShift Container Storage の使用開始
  • OpenShift Container Storage の設定と管理

第3章 機能拡張

ここでは、Red Hat 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 は以下のように再設計されました。

  • 初期の状態では OSD PDB が 1 つあります。これにより、1 度に 1 つの OSD のみがダウンします。
  • OSD がダウンすると、その障害ドメインが判別され、他の障害ドメインについて障害となる OSD PDB が作成されます。
  • 作成済みの元の OSD PDB は削除されます。これにより、すべての OSD が失敗ドメインでダウンする可能性があります。

新たな設計により、ユーザーは同じ失敗ドメインで複数のノードをドレイン (解放) できるようになりました。

外部モードでの 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 アラートが追加されました。アラートメッセージは以下のようになります。

 Storage daemon osd.x has restarted 5 times in the last 5 minutes. Please check the pod events or ceph status to find out the cause.

ここで、x は OSD 番号を表します。

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

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

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

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

第4章 バグ修正

このセクションでは、Red Hat OpenShift Container Storage 4.7 で導入された主なバグ修正について説明します。

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

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

(BZ#2005515)

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 がクラッシュしなくなりました。

(BZ#1968438)

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

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

(BZ#1788126)

must-gather ログ収集の失敗

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

(BZ#1884546)

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

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

(BZ#1902711)

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

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

(BZ#1904917)

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

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

(BZ#1908678)

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

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

(BZ#1922421)

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

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

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

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

(BZ#1935065)

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

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

(BZ#1937245)

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

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

(BZ#1939272)

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

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

(BZ#1904302)

第5章 テクノロジープレビュー

このセクションでは、Red Hat OpenShift Container Storage 4.7 で導入されたテクノロジープレビュー機能について説明します。

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

デバイスの暗号化キーを保存するために外部の鍵管理システム (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 Platform を設定するには、3 ノードクラスターの設定について、またエッジデプロインメントの 3 ノードアーキテクチャーの提供について参照してください。

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

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

第6章 Developer プレビュー

このセクションでは、Red Hat OpenShift Container Storage 4.7 で導入された Developer プレビュー機能について説明します。

Developer プレビュー機能は、Developer プレビューのサポート制限の対象となります。Developer プレビューのリリースは、実稼働環境で実行することは意図されていません。Developer プレビュー機能と共にデプロイしたクラスターは開発用クラスターとして考慮され、Red Hat カスタマーポータルのケース管理システムではサポートされません。Developer プレビュー機能に関してサポートが必要な場合には、ocs-devpreview@redhat.com メーリングリストに連絡してください。Red Hat Development Team のメンバーが稼働状況とスケジュールに応じて可能な限り迅速に対応します。

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

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 を使用してパフォーマンスを強化できます。

第7章 既知の問題

このセクションでは、Red Hat OpenShift Container Storage 4.7 の既知の問題について説明します。

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

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

Red Hat OpenShift Container Storage 4.7 の場合、回避策は以下のようになります。

外部 RHCS がアクティブな MGR を戻すと、python スクリプト ceph-external-cluster-details-exporter.py を再度実行して JSON 出力ファイルを収集します。OCP 側で、先に収集した JSON ファイルの出力で rook-ceph-external-cluster-details という名前の外部シークレットを更新します。これにより調整がトリガーされ、OCP はメトリクスを再度取得し始めます。

(BZ#1908238)

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

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

回避策: vault kv metadata delete コマンドを使用して、キーのメタデータを手動で削除します。

(BZ#1975323)

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

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

(BZ#1944148)

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

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

(BZ#1946595)

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

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

(BZ#1947110)

noobaa-db-pg-0 の問題

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

(BZ#1783961)

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

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

  • スナップショットを使用する場合、既存のスナップショットを復元し、親 PVC と同じサイズのボリュームを作成し、これを Pod に割り当て、PVC を必要なサイズに拡張します。詳細は、「ボリュームスナップショット」を参照してください。
  • Clone を使用する場合、親 PVC のクローンを作成し、親 PVC と同じサイズのボリュームを作成し、これを Pod に割り当て、PVC を必要なサイズに拡張します。詳細は、「ボリュームのクローン作成」を参照してください。

(BZ#1870334)

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

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

(BZ#1896810)

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

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

(BZ#1906002)

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

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

(BZ#1956232)

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

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

  1. OpenShift Container Platform Web コンソール → Administrator をクリックします。
  2. HomeSearch をクリックします。
  3. resources dropdown で、TemplateInstance を検索します。
  4. TemplateInstance を選択し、openshift-storage namespace を選択するようにしてください。
  5. すべてのテンプレートインスタンスを削除します。

(BZ#1958875)