このページは Cloud Translation API によって翻訳されました。

保護対象アプリケーションの戦略

このページでは、Google Distributed Cloud（GDC）エアギャップで使用できるさまざまな保護アプリケーション戦略について説明します。

保護されたアプリケーション戦略を使用すると、特定の実行前フックと実行後フックを実行し、ステートフルワークロードの静止、バックアップ、復元を行うカスタム動作を定義できます。

ProtectedApplication リソースを定義する場合、3 つのバックアップと復元の戦略を使用できます。

すべてバックアップしてすべて復元する
1 つをバックアップしてすべて復元する
ダンプと読み込み

戦略定義には次の値を含めることができます。

タイプ	属性	説明
`BackupAllRestoreAll`		コンポーネント内のすべてをバックアップして復元します。
	`backupPreHooks`	バックアップの前に実行するフックのリスト。
	`backupPostHooks`	バックアップ後に実行するフックのリスト。
	`volumeSelector`	バックアップする永続ボリュームを指定するラベルセレクタ。空の場合、すべての PV が選択されます。
`backupOneRestoreAll`		選択した Pod のコピーを 1 つバックアップし、それを使用してすべての Pod を復元します。
	`backupTargetName`	バックアップに使用する優先 `Deployment` または `StatefulSet` の名前。
	`backupPreHooks`	バックアップの前に実行するフックのリスト。
	`backupPostHooks`	バックアップ後に実行するフックのリスト。
	`volumeSelector`	バックアップする永続ボリュームを指定するラベルセレクタ。空の場合、すべての PV が選択されます。
`dumpAndLoad`		バックアップと復元に専用のボリュームを使用します。
	`dumpTarget`	コンポーネントデータのダンプに使用される優先 `Deployment` または `StatefulSet` の名前を指定します。ターゲット Pod は、このコンポーネントの構成方法に基づいて選択されます。デプロイ: ターゲット `Deployment` によって作成された唯一の Pod を選択します。 Single-StatefulSet: レプリカ数が 2 より大きい場合は、ターゲット `StatefulSet` によって作成された 2 番目の Pod を選択します。それ以外の場合は、唯一の Pod を選択します。 Multi-StatefulSet: ターゲット `StatefulSet` によって作成された最初の Pod を選択します。
	`loadTarget`	コンポーネントデータの読み込みに使用される優先 `Deployment` または `StatefulSet` の名前を指定します。ターゲット Pod は、このコンポーネントの構成方法に基づいて選択されます。デプロイ: ターゲット `Deployment` によって作成された唯一の Pod を選択します。 StatefulSet: ターゲット `StatefulSet` によって作成された最初の Pod を常に選択します。
	`dumpHooks`	データのダンプに使用されるフックのリスト。
	`backupPostHooks`	バックアップ後に実行するフックのリスト。
	`loadHooks`	専用ボリュームからこのコンポーネントのデータを読み込むために使用されるフックのリスト。読み込みの完了後にクリーンアップの手順が含まれる場合もあります。実行ターゲット Pod は、`LoadTarget` から選択された Pod の 1 つです。
	`volumeSelector`	バックアップする永続ボリュームを指定するラベルセレクタ。空の場合、すべての PV が選択されます。

すべてバックアップしてすべて復元する

この戦略では、バックアップ中にアプリケーションリソースがすべてバックアップされ、復元時にすべてのリソースが復元されます。この戦略は、スタンドアロンアプリケーション（Pod 間でレプリケーションがないアプリケーション）に最適です。

すべてバックアップしてすべて復元する戦略では、リソース定義に次の情報を含めます。

フック: ボリュームバックアップを取得する前後に実行されるコマンドを定義します（アプリケーションの停止や停止解除の手順など）。これらのコマンドは、コンポーネント内のすべての Pod で実行されます。
ボリュームの選択: コンポーネント内でバックアップおよび復元されるボリュームを詳細に指定します。選択されていないボリュームはバックアップされません。復元中、バックアップ時にスキップされたボリュームは空のボリュームとして復元されます。

この例では、ログボリュームをバックアップする前にファイルシステムを停止し、バックアップの後に停止する ProtectedApplication リソースを作成します。

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: nginx
  namespace: sales
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: nginx
  components:
  - name: nginx-app
    resourceKind: Deployment
    resourceNames: ["nginx"]
    strategy:
      type: BackupAllRestoreAll
      backupAllRestoreAll:
        backupPreHooks:
        - name: fsfreeze
          container: nginx
          Commands: [ /sbin/fsfreeze, -f, /var/log/nginx ]
        backupPostHooks:
        - name: fsunfreeze
          container: nginx
          commands: [ /sbin/fsfreeze, -u, /var/log/nginx ]

1 つをバックアップしてすべて復元する

この戦略では、選択した Pod のコピーを 1 つバックアップします。この単一コピーは、復元中にすべての Pod を復元するソースです。この方法は、ストレージ費用を削減しバックアップ時間を短縮するのに役立ちます。この戦略は、1 つのプライマリ PersistentVolumeClaim と複数のセカンダリ PersistentVolumeClaims でコンポーネントがデプロイされている場合に、高可用性構成で機能します。

1 つをバックアップしてすべて復元する戦略では、リソース定義に次の情報を含める必要があります。

バックアップターゲット: データのバックアップに使用する Deployment または StatefulSet を指定します。バックアップに最適な Pod が自動的に選択されます。高可用性構成では、セカンダリ PersistentVolumeClaim からバックアップすることをおすすめします。
フック: ボリュームバックアップを取得する前後に実行されるコマンドを定義します（アプリケーションの停止や停止解除の手順など）。これらのコマンドは、選択したバックアップ Pod でのみ実行されます。
ボリュームの選択: コンポーネント内でバックアップおよび復元されるボリュームを詳細に指定します。

コンポーネントが複数の Deployment リソースまたは StatefulSet リソースで構成されている場合は、すべてのリソースが同じ PersistentVolume 構造になっている必要があります。つまり、次のルールに従う必要があります。

すべての Deployment リソースまたは StatefulSet リソースで使用される PersistentVolumeClaim リソースの数は同じである必要があります。
同じインデックス内の PersistentVolumeClaim リソースの目的は同じである必要があります。StatefulSet リソースの場合、インデックスは volumeClaimTemplate で定義されます。Deployment リソースの場合、インデックスは Volume リソースで定義され、非永続ボリュームはスキップされます。

これらの考慮事項を前提に、バックアップには複数のボリュームセットを選択できますが、各ボリュームセットから選択されるボリュームは 1 つだけです。

この例は、1 つのプライマリ StatefulSet とセカンダリ StatefulSet のアーキテクチャを想定し、セカンダリ StatefulSet の単一 Pod 内のボリュームのバックアップがあり、その後、他のすべてのボリュームに復元されることを示しています。

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: mariadb
  namespace: mariadb
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: mariadb
  components:
  - name: mariadb
    resourceKind: StatefulSet
    resourceNames: ["mariadb-primary", "mariadb-secondary"]
    strategy:
      type: BackupOneRestoreAll
      backupOneRestoreAll:
        backupTargetName: mariadb-secondary
        backupPreHooks:
        - name: quiesce
          container: mariadb
          command: [...]
        backupPostHooks:
        - name: unquiesce
          container: mariadb
          command: [...]

ダンプと読み込み

この戦略では、バックアップと復元のプロセスに専用のボリュームが使用されます。ダンプデータを格納するコンポーネントには、専用の PersistentVolumeClaim が接続されている必要があります。ダンプと読み込みの戦略では、リソース定義に次の情報を含めます。

ダンプターゲット: データのダンプに使用する Deployment または StatefulSet を指定します。バックアップに最適な Pod が自動的に選択されます。高可用性構成では、セカンダリ PersistentVolumeClaim からバックアップすることをおすすめします。
読み込みターゲット: データの読み込みに使用する Deployment または StatefulSet を指定します。バックアップに最適な Pod が自動的に選択されます。読み込みターゲットは、ダンプターゲットと同じにする必要はありません。
フック: ボリュームバックアップを取得する前後に実行されるコマンドを定義します。ダンプと読み込みの戦略には、特定のフックを定義する必要があります。
- ダンプフック: バックアップの前に、データを専用ボリュームにダンプするフックを定義します。このフックは、選択したダンプ Pod でのみ実行されます。
- 読み込みフック: アプリケーションが起動した後にデータを読み込むフックを定義します。このフックは、選択した読み込み Pod でのみ実行されます。
- 省略可 - バックアップ後のフック: 専用ボリュームのバックアップ後に実行されるフック（クリーンアップ手順など）を定義します。このフックは、選択したダンプ Pod でのみ実行されます。
ボリュームの選択: ダンプデータを保存するすべての専用ボリュームを指定します。各ダンプと読み込み Pod ごとに 1 つのボリュームのみを選択する必要があります。

アプリケーションが Deployments で構成されている場合、各 Deployment には 1 つのレプリカが必要です。

この例では、プライマリ StatefulSet とセカンダリ StatefulSet の両方に専用の PersistentVolumeClaims を持つ 1 つのプライマリ StatefulSet とセカンダリ StatefulSet のアーキテクチャを想定し、ダンプと読み込みの戦略を示しています。StatefulSets

kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
  name: mariadb
  namespace: mariadb
spec:
  resourceSelection:
    type: Selector
    selector:
      matchLabels:
        app: mariadb
  components:
  - name: mariadb-dump
    resourceKind: StatefulSet
    resourceNames: ["mariadb-primary", "mariadb-secondary"]
    backupStrategy:
      type: DumpAndLoad
      DumpAndLoad:
        loadTarget: mariadb-primary
        dumpTarget: mariadb-secondary
        dumpHooks:
        - name: db_dump
          container: mariadb
          commands:
          - bash
          - "-c"
          - |
            mysqldump -u root --all-databases > /backup/mysql_backup.dump
        loadHooks:
        - name: db_load
          container: mariadb
          commands:
          - bash
          - "-c"
          - |
            mysql -u root < /backup/mysql_backup.sql
    volumeSelector:
      matchLabels:
        gkebackup.gke.io/backup: dedicated-volume

次のステップ

一連のバックアップを計画する

保護対象アプリケーションの戦略 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

すべてバックアップしてすべて復元する

1 つをバックアップしてすべて復元する

ダンプと読み込み

次のステップ

保護対象アプリケーションの戦略