第7章 既知の問題

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

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

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

(BZ#1947110)

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

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

(BZ#1896810)

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

ocs-operator が再起動するか、またはアップグレード時には常に監視仕様は空になります。これは機能への影響はありませんが、モニタリングエンドポイントの詳細が必要な場合は、空にします。

この問題を解決するには、4.7 から 4.8 にアップグレードした後に rook-ceph-external-cluster-details シークレットを更新し、すべてのエンドポイントの詳細 (active および standby MGRs など) が「MonitoringEndpoint」データキーに更新されます。これは、新規でアップグレードされたクラスターとアップグレードされたクラスターにあるエンドポイントの数が異なるため、今後発生する問題を回避するのに役立ちます。

(BZ#1984735)

noobaa-db-pg-0 の問題

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

(BZ#1783961)

プラグイン Pod が削除されると、ノードの再起動が行われるまでデータはアクセス不可能になります。

この問題は、csi-cephfsplugin Pod が再起動すると、マウントの netns が破棄されるため、csi-cephfsplugin はすべてのマウントされたボリュームをロックします。この問題は、multus を有効にしてクラスターでのみ見られます。

この問題は、削除後に csi-cephfsplugin が再起動したノードを再起動する際に解決されます。

(BZ#1979561)

暗号化パスフレーズは、スナップショットからボリュームを復元するためのソース KMS に保存されます。

親と復元された PVC の異なるバックエンドパスを持つ StorageClass が異なる場合、復元された PVC は Bound 状態に行われ、スナップショットから KMS 設定のバックエンドパスに暗号化パスフレーズが作成されます。暗号化パスフレーズの確認は 2 番目の StorageClass パスにリンクされた設定を使用するので、復元された PVC は Pod に割り当てられないようにすることができます。この場合、暗号化パスフレーズはバックエンドパスに見つかりません。

この問題を防ぐために、PVC はスナップショットを作成し、それらを復元する際に常に同じ KMS 設定を使用する必要があります。

(BZ#1975730)

キーは、kv-v2 シークレットエンジンを使用する場合に、暗号化された PVC を削除した後に Vault に一覧表示されます。

HashiCorp Vault は、保存されたキーの削除先である key-value store v2 の機能を追加しました。これにより、削除されたキーのメタデータが別のステップで削除されない場合にコンテンツを回復できます。Hashicorp Vault のシークレットに key-value v2 ストレージを使用する場合に、ボリュームを削除すると、KMS から暗号化パスフレーズのメタデータは削除されません。後で暗号化パスフレーズを復元することが可能です。これらの部分的に削除されたキーは、KMS によって自動的にクリーンアップされません。

この問題を解決するには、削除されたキーのメタデータを手動で削除します。メタデータで deletion_time が設定されているキーはすべて、キー/値のストレージ v1 が使用され、v2 で利用可能になる際に削除されていると想定されます。

(BZ#1979244)

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

Ceph CSI は、親 PVC よりもサイズが大きい場合にスナップショットの復元やクローンの作成をサポートしません。そのため、サイズが多い Restore Snapshot/Clone 操作により、無限ループが生じます。この問題を回避するには、保留中の PVC を削除します。より大きい PVC を取得するには、仕様しちえる操作に基づいて以下のいずれかを完了する必要があります。スナップショットを使用する場合、既存のスナップショットを復元し、親 PVC と同じサイズのボリュームを作成し、これを Pod に割り当て、PVC を必要なサイズに拡張します。詳細は、「Volume snapshots」を参照してください。Clone を使用する場合、親 PVC のクローンを作成し、親 PVC と同じサイズのボリュームを作成し、これを Pod に割り当て、PVC を必要なサイズに拡張します。詳細は、「ボリュームのクローン作成」を参照してください。

(BZ#1870334)

PVC はスナップショットから復元するか、シックプロビジョニングされた PVC からクローンがプロビジョニングされていません。

シックプロビジョニングされた PVC のスナップショットが thic provisioning のストレージクラスを使用して復元されると、復元されたボリュームはプロビジョニングされません。復元される PVC は、シックプロビジョニングなしで Bound 状態に達します。この問題は、RHCS-5.x が使用される場合にのみ修正できます。以前の Ceph バージョンは、ゼロ入力データブロックのコピーをサポートしません (シックプロビジョニング時に使用)。

現在、RHCS-4.x ベースのデプロイメントで問題を解決するには、プロビジョニングされているボリュームの PVC-cloning および snapshot-restor に上限としてマークを付けることです。新規に作成されたボリュームは、シンプロビジョニングされます。

(BZ#1959793)

プロビジョニングが進行中に保留中の PVC および RBD プロビジョナーリーダー Pod を削除すると、古いイメージと OMAP メタデータが残されます。

RBD PVC がプロビジョニングされている場合、Persistent Volume Claim (永続ボリューム要求、PVC) は Pending 状態になります。RBD プロビジョナーリーダーおよび PVC 自体が削除されても、RBD イメージと OMAP メタデータは削除されません。

この問題に対処するには、プロビジョニングが進行中に PVC を削除しないでください。

(BZ#1962956)

ストレージクラスターの使用が 85% に達するか、PVC を削除した後にも、プロビジョニングは停止しませんでした。

RBD シック PVC がプロビジョニングされている間にストレージクラスターの使用状況が 85% に達すると、プロビジョニングは保留中の PVC を削除して自動的に停止しません。また、保留中の PVC を削除しても RBD イメージは削除されません。

要求されたサイズが利用可能なストレージを超えても、プロビジョニングを開始しないのが最良のアプローチではありません。

(BZ#1965016)

kv-v2 が使用されると、Vault の OSD のキーはアンインストール時に削除されません

キー暗号化キーデータは、Vault K/V Secret エンジンがバージョン 2 の場合に、クラスターの削除時に Vault からソフト削除されます。つまり、任意のバージョンのキーを取得できるため、削除が元に戻されます。メタデータは引き続き表示されるので、鍵を復元できます。これによって不整合が生じても、vault コマンドに「destroy」引数を指定して手動でキーを削除できます。

(BZ#1975323)

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

Multus が有効なクラスターでは、Rook Operator にはネットワークアノテーションがないため、OSD ネットワークにアクセスできません。つまり、プールのクリーンアップ中に「rbd」タイプコマンドを実行すると、OSD と通信できないためコマンドがハングします。回避策として、toolbox を使用して CephBlockPool を手動で削除します。

(BZ#1983756)

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

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

(BZ#1906002)

volumeMode をブロックとして持つ PVC の false 通知

Kubernetes の変更により、OpenShift Container Platform の Prometheus アラートでリグレッションが発生します。この変更は以下に影響があります。

Alert: KubePersistentVolumeFillingUp.

PVC: volumeMode: Block の PVC

namespace の一致する正規表現: "(openshift-.|kube-.|default|logging)"

Metric: kubelet_volume_stats_available_bytes

その結果、アラートの kubelet_volume_stats_available_bytes は PVC の作成時から利用可能なサイズを 0 として報告します。また、正規表現 "(openshift-.|kube-.|default|logging)" に一致する namespace の volumeMode: Block のすべての PVC 似対して false アラートが実行されます。これは、内部および内部接続モードにデプロイされた OpenShift Container Storage の OSD デバイスセット用に作成されたすべての PVC と Amazon Web Services、VMware、ベアメタルなどの異なるインフラストラクチャーに影響を与えます。これは、お客様のワークロード PVC にも影響します。

現在、OpenShift Container Platform 4.8.z の今後のマイナーリリースで修正されるまで、この問題に対する回避策はありません。そのため、OpenShift Container Storage によるストレージ容量に関するアラートに厳密に迅速に対応し、緊急性のあるアラートに対処します。

(BZ#1984817)

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

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

この問題を回避するには、CephCluster を削除する前に CephObjectStore(s) を完全に削除します。

  • CephObjectStore(s)が削除されるのを待機しない場合は、Rook Operator を再起動して (Operator Pod を削除して)、アンインストール後に実行しても問題がなくなります。
  • この問題が発生している場合、Rook Operator を再起動すると、Operator の古い CephObjectStore 接続の詳細をクリアし、Rook Operator を再起動してこれを解決します。

(BZ#1974344)