Stratégies pour les applications protégées

Cette page décrit les différentes stratégies d'application protégée disponibles dans Google Distributed Cloud (GDC) air-gapped.

Les stratégies d'application protégée vous permettent d'exécuter des hooks spécifiques avant et après l'exécution, et de définir un comportement personnalisé pour la suspension, la sauvegarde ou la restauration d'une charge de travail avec état.

Vous pouvez employer trois stratégies de sauvegarde et de restauration lorsque vous définissez une ressource ProtectedApplication :

• Tout sauvegarder et tout restaurer
• Sauvegarder une ressource et tout restaurer
• Vider et charger

Les définitions de stratégie peuvent inclure les valeurs suivantes :

Tout sauvegarder et tout restaurer

Cette stratégie sauvegarde toutes les ressources de l'application pendant la sauvegarde et restaure toutes ces ressources lors de la restauration. Cette stratégie est idéale pour les applications autonomes, c'est-à-dire sans application de réplication entre pods.

Pour effectuer une sauvegarde complète et restaurer toutes les stratégies, incluez les informations suivantes dans la définition de la ressource :

• Hooks : définissent les commandes exécutées avant et après les sauvegardes de volume, telles que les étapes de suspension et de reprise de l'application. Ces commandes sont exécutées sur tous les pods d'un composant.

• Sélection du volume : fournit des informations plus précises sur les volumes qui sont sauvegardés et restaurés dans le composant. Les volumes non sélectionnés ne sont pas sauvegardés. Lors d'une restauration, tous les volumes ignorés lors de la sauvegarde sont restaurés en tant que volumes vides.

L'exemple ci-dessous crée une ressource ProtectedApplication qui suspend le système de fichiers avant de sauvegarder le volume de journaux et de suspendre le service après la sauvegarde :

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 ]

Sauvegarder une ressource et tout restaurer

Cette stratégie sauvegarde une copie d'un pod sélectionné. Cette copie unique sert de source pour la restauration de tous les pods lors d'une opération de restauration. Cette méthode permet de réduire les coûts de stockage et le temps de sauvegarde. Cette stratégie fonctionne dans une configuration à haute disponibilité lorsqu'un composant est déployé avec une PersistentVolumeClaim principale et plusieurs PersistentVolumeClaims secondaires.

Pour une sauvegarde et une restauration de toutes les stratégies, vous devez inclure les informations suivantes dans la définition de la ressource :

• Backup target (Sauvegarde cible) : spécifie le Deployment ou le StatefulSet à utiliser pour sauvegarder les données. Le meilleur pod à sauvegarder est sélectionné automatiquement. Dans une configuration à haute disponibilité, Google recommande de sauvegarder les données à partir d'une PersistentVolumeClaim secondaire.
• Hooks : définissent les commandes exécutées avant et après les sauvegardes de volume, telles que les étapes de suspension et de reprise de l'application. Ces commandes ne sont exécutées que sur le pod de sauvegarde sélectionné.
• Sélection du volume : fournit des informations plus précises sur les volumes qui sont sauvegardés et restaurés dans le composant.

Si un composant est configuré avec plusieurs ressources Deployment ou StatefulSet, toutes les ressources doivent avoir la même structure PersistentVolume et respecter les règles suivantes :

• Le nombre de ressources PersistentVolumeClaim utilisées par toutes les ressources Deployment ou StatefulSet doit être identique.
• L'objectif des ressources PersistentVolumeClaim dans le même index doit être identique. Pour les ressources StatefulSet, l'index est défini dans volumeClaimTemplate. Pour les ressources Deployment, l'index est défini dans les ressources Volume et tous les volumes non persistants sont ignorés.

Compte tenu de ces éléments, plusieurs ensembles de volumes peuvent être sélectionnés pour la sauvegarde, mais un seul volume de chaque ensemble de volumes sera sélectionné.

Cet exemple, dans l'hypothèse d'une architecture comprenant un StatefulSet principal et un StatefulSet secondaire, indique une sauvegarde des volumes d'un seul pod dans un StatefulSet secondaire, puis une restauration pour tous les autres volumes :

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: [...]

Vider et charger

Cette stratégie utilise un volume dédié aux processus de sauvegarde et de restauration. Elle nécessite une PersistentVolumeClaim dédiée associée à un composant qui stocke les données de vidage. Pour une stratégie de vidage et de chargement, incluez les informations suivantes dans la définition de la ressource :

• Dump target (Cible de vidage) : spécifie le Deployment ou le StatefulSet à utiliser pour vider les données. Le meilleur pod à sauvegarder est sélectionné automatiquement. Dans une configuration de haute disponibilité, il est recommandé de procéder à la sauvegarde à partir d'une PersistentVolumeClaim secondaire.
• Load target (Cible de chargement) : spécifie le Deployment ou le StatefulSet à utiliser pour charger les données. Le meilleur pod à sauvegarder est sélectionné automatiquement. La cible de chargement ne doit pas nécessairement être identique à la cible de vidage.
• Hooks : définissent les commandes exécutées avant et après les sauvegardes de volume. Vous devez définir des hooks spécifiques pour les stratégies de vidage et de chargement :
  • Dump hooks (Hooks de vidage) : définissent les hooks qui vident les données dans le volume dédié avant la sauvegarde. Ce hook s'exécute uniquement sur le pod de vidage sélectionné.
  • Load hooks (Cibles de chargement) : définissent les hooks qui chargent les données après le démarrage de l'application. Ce hook s'exécute uniquement sur le pod de chargement sélectionné.
  • Facultatif : Post-backup hooks (Hooks post-sauvegarde) : définissent les hooks qui s'exécutent après la sauvegarde des volumes dédiés, tels que les étapes de nettoyage. Ce hook s'exécute uniquement sur le pod de vidage sélectionné.
• Volume selection (Sélection du volume) : spécifie tous les volumes dédiés qui stockent les données de vidage. Vous ne devez sélectionner qu'un seul volume pour chaque fichier de vidage et de pod de chargement.

Si l'application comprend des Deployments, chaque Deployment doit posséder exactement une instance dupliquée.

Cet exemple, dans l'hypothèse d'une architecture comprenant un StatefulSet principal et un StatefulSet secondaire avec des PersistentVolumeClaims dédiées pour le StatefulSets principal et le StatefulSets secondaire, indique une stratégie de vidage et de chargement :

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

Étapes suivantes

• Planifier un ensemble de sauvegardes