第7章 既知の問題

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

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' がクラスターから欠落します。

回避策:グラフィカルユーザーインターフェイス (GUI) またはバックエンドから odf-operator をインストールします。バックエンドを使用して作成する場合は、サブスクリプション名が odf-operator であることを確認します。

(BZ#2050251)

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

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

(BZ#1970123)

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

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

この問題を回避するには、CephCluster を削除する前に CephObjectStores を完全に削除します。CephObjectStores の削除を待ちたくない場合は、アンインストール後に問題が発生しないように、(Operator Pod を削除して)Rook Operator を再起動してください。この問題が発生している場合、古い CephObjectStore 接続の詳細 の Operator のメモリーをクリアし、Rook Operator を再起動してこの問題を解決してください。

(BZ#1974344)

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

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

(BZ#1982116)

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

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

回避策:管理者は rook-ceph-operator-config の値を手動で変更できます。

(BZ#1986016)

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

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

回避策:prometheus-user を手動で作成し、ストレージクラスターの作成後に適切なパーミッションを提供します。詳細は、ナレッジベースの記事 https://access.redhat.com/articles/6541861 の前提条件を参照してください。

(BZ#1999952)

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

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

回避策:詳細については、ステータスメッセージまたはログを待ち、監視します。

(BZ#2004027)

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

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

回避策:KMS プロバイダーオプションにはキャメルケースフォーマットを使用します。

(BZ#2005801)

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

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

(BZ#2005919)

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

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

(BZ#2007376)

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

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

(BZ#2019931)

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

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

(BZ#2021460)

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

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

(BZ#2024545)