storagePrefixの変更後に「could not find qtree」が発生し、Trident Protectのバックアップに失敗する
環境
- NetApp Trident Protect
- NetApp Trident
問題
ontap-nas-economyドライバでプロビジョニングされた永続ボリューム要求（PVC）に対して、Trident Protectのバックアップが失敗する
警告 ProvisioningFailed … バックエンド <backend-name> でクローンボリューム pvc-<uuid> の作成に失敗しました：qtree trident_pvc_<uuid> が見つかりませんでした
- バックアップPVCは
Pendingのままです - アプリケーションのバックアップが次のエラーで失敗します：
PVC is not bound within the specified timeout- VolumeSnapshot同じソースPVCに対する作成は引き続き成功する場合があります。
- 一部の環境では、関連するバックアップまたはスナップショット処理中に、オペレーターがストレージスナップショット制限エラーを目にすることもあります。
Failed to create Snapshot copy ... Reason: cannot exceed maximum number of snapshot copies, code: 135原因
|
警告
|
storagePrefixは、アプリケーションのPVCがすでにプロビジョニングされた後に、既存のTridentバックエンドで変更されます。
問題を再現する手順：
- バックエンドは
storagePrefixを設定して作成されます（例：dev） - アプリケーションPVCがプロビジョニングされ、qtreeとエコノミープールFlexVolsはそのプレフィックスを使用して作成されます
storagePrefixは後で（例えばtridentに）TridentBackendカスタムリソースにパッチを適用してTridentコントローラを再起動することで変更されます
解決策
以下のサポートされているオプションのいずれかを使用してください。
- 別のプレフィックスが必要な場合に推奨されます
- 目的の
storagePrefixを使用して新しい Trident バックエンドを作成する - ワークロードをそのバックエンドに移行する
- 影響を受けるアプリケーションの Trident Protect バックアップを再テストする
- サポートされていない変更後に新しいボリュームが作成されなかった場合
storagePrefixを、既存のqtreeがプロビジョニングされた際に使用された元の値に戻す- 使用中のデプロイメント方法でバックエンドのリロードが必要な場合は、Tridentコントローラーを再起動またはロールする
- Trident Protectバックアップを再テストする
パートナーノート
partnerNotes_text
追加情報
- 製品ドキュメントには、
storagePrefixは設定後に更新できないと記載されています。既存のqtreeとプールFlexVolsは元の名前を保持し、プレフィックスが変更されても名前は変更されません。バックエンド設定オプション - Trident Protect Kopia バックアップは、一時的な読み取り専用のクローン PVC を作成します。クローンのプロビジョニング中、Trident は現在のバックエンドプレフィックスと対応するエコノミープールFlexVol名前パターンを使用してソースqtreeを検索します。サポートされていないプレフィックスの変更後、Trident は新しいプレフィックスの下を検索しますが、ソースqtreeは元のプレフィックスで作成されたプールの下に引き続き存在します。検索は
could not find qtreeで失敗します。 tridentctl update backendはstoragePrefixの変更を拒否します。TridentBackendにパッチを適用するとその検証を回避できますが、既にボリュームが存在するバックエンドでプレフィックスを変更するためのサポートされた方法ではありません。- VolumeSnapshotsは、既存のソースボリュームメタデータを使用し、読み取り専用クローンパスで使用される同じFlexVolプール検索に依存しないため、引き続き機能します。
- 異なるstoragePrefixを持つ Trident バックエンドは、異なるボリュームにqtreeを作成しますか
内部情報
内部情報