Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

高度なカスタムリソースのリストア設定を使用する

共同作成者 netapp-mwallis

注釈、名前空間設定、ストレージ オプションなどの詳細設定を使用して、特定の要件を満たすように復元操作をカスタマイズできます。

リストアおよびフェイルオーバー処理中のネームスペースのアノテーションとラベル

リストアおよびフェイルオーバー時には、宛先の名前空間ラベルと注釈がソースに合わせて更新されます(ソースのキーは宛先のキーに追加または上書きされますが、宛先にのみ存在するキーは変更されません)。

メモ Red Hat OpenShiftでは、ネームスペースアノテーションは、リストアされたポッドが正しいセキュリティコンテキスト制約と権限を受け取ることを保証し、ボリュームへのアクセスや権限エラーなしでの実行を可能にするため重要です。詳細については、"OpenShiftセキュリティコンテキスト制約ドキュメント"を参照してください。

Kubernetes環境変数を設定する

RESTORE_SKIP_NAMESPACE_ANNOTATIONS

復元またはフェイルオーバーの前に、特定の宛先ネームスペースの注釈が上書きされないようにします。例:

helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect \
  --set-string restoreSkipNamespaceAnnotations="{<annotation_key_to_skip_1>,<annotation_key_to_skip_2>}" \
  --reuse-values
メモ リストアまたはフェイルオーバー中に、 `restoreSkipNamespaceAnnotations`および `restoreSkipNamespaceLabels`で指定された名前空間アノテーションとラベルは、リストアまたはフェイルオーバー処理から除外されます。これらの設定は、Helmの初回インストール時に必ず構成してください。詳細については、 "追加のTrident Protectヘルムチャート設定を構成する"を参照してください。

Helm を `--create-namespace`フラグとともに使用してソースアプリケーションをインストールした場合、Trident Protect は名前ラベルをデスティネーションネームスペースにコピーします。ラベルの値がソースネームスペース名と一致する場合は、デスティネーションネームスペース名に置き換えられます。一致しない場合は、そのまま残されます。

次の例では、異なるラベルと注釈を持つソースネームスペースと宛先ネームスペースを示し、操作の前後の宛先ネームスペースを表示することで、キーがどのように追加、マージ、または上書きされるかを説明しています。

リストアまたはフェイルオーバー処理の前に

次の表は、リストアまたはフェイルオーバー処理前のサンプルのソースネームスペースとデスティネーションネームスペースの状態を示しています:

ネームスペース アノテーション ラベル

ネームスペースns-1(ソース)

  • annotation.one/key:"updatedvalue"

  • annotation.two/key:"true"

  • environment=production

  • コンプライアンス=hipaa

  • name=ns-1

ネームスペースns-2(宛先)

  • annotation.one/key:"true"

  • annotation.three/key:"false"

  • ロール=database

リストア処理後

次の表は、復元またはフェイルオーバー操作後の宛先名前空間の例の状態を示しています。いくつかのキーが追加され、いくつかは上書きされ、 `name`ラベルは宛先名前空間と一致するように更新されました:

ネームスペース アノテーション ラベル

ネームスペースns-2(宛先)

  • annotation.one/key:"updatedvalue"

  • annotation.two/key:"true"

  • annotation.three/key:"false"

  • name=ns-2

  • コンプライアンス=hipaa

  • environment=production

  • ロール=database

サポートされているフィールド

このセクションでは、復元操作に使用できる追加のフィールドについて説明します。

ストレージクラスのマッピング

`spec.storageClassMapping`属性は、ソース アプリケーションに存在するストレージ クラスからターゲット クラスタ上の新しいストレージ クラスへのマッピングを定義します。異なるストレージ クラスを持つクラスタ間でアプリケーションを移行する場合や、BackupRestore操作のストレージ バックエンドを変更する場合にこれを使用できます。

例:

storageClassMapping:
  - destination: "destinationStorageClass1"
    source: "sourceStorageClass1"
  - destination: "destinationStorageClass2"
    source: "sourceStorageClass2"

サポートされているアノテーション

このセクションでは、システム内のさまざまな動作を構成するためにサポートされているアノテーションを一覧表示します。ユーザーがアノテーションを明示的に設定しない場合、システムはデフォルト値を使用します。

注釈 タイプ 説明 デフォルト値

protect.trident.netapp.io/data-mover-timeout-sec

string

データ ムーバー処理が停止する最大時間(秒単位)。

"300"

protect.trident.netapp.io/kopia-content-cache-size-limit-mb

string

Kopia コンテンツ キャッシュの最大サイズ制限(メガバイト単位)。

"1000"

protect.trident.netapp.io/pvc-bind-timeout-sec

string

新しく作成されたPersistentVolumeClaims(PVC)が `Bound`フェーズに到達するまで待機する最大時間(秒単位)。この時間を超えると処理は失敗します。環境:すべてのリストアCRタイプ(BackupRestore、BackupInplaceRestore、SnapshotRestore、SnapshotInplaceRestore)。ストレージバックエンドまたはクラスターで処理に時間がかかることが多い場合は、より大きい値を使用してください。

「1200」(20分)