第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)