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

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

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

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

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

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

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

この戦略では、バックアップ中にアプリケーション リソースがすべてバックアップされ、復元時にすべてのリソースが復元されます。この戦略は、スタンドアロン アプリケーション（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

次のステップ

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