Strategie per le applicazioni protette

Questa pagina descrive le diverse strategie di protezione delle applicazioni disponibili in Google Distributed Cloud (GDC) air-gapped.

Le strategie di protezione delle applicazioni ti consentono di eseguire hook specifici pre-esecuzione e post-esecuzione e definire un comportamento personalizzato per la sospensione, il backup o il ripristino di un workload stateful.

Esistono tre strategie di backup e ripristino che puoi utilizzare quando definisci una risorsa ProtectedApplication:

Le definizioni delle strategie possono includere i seguenti valori:

Tipo Attributo Descrizione
BackupAllRestoreAll Esegui il backup e il ripristino di tutti i contenuti del componente.
backupPreHooks Elenco degli hook da eseguire prima del backup.
backupPostHooks Elenco degli hook da eseguire dopo il backup.
volumeSelector Selettore di etichette che specifica i volumi permanenti di cui eseguire il backup. Se vuoto, vengono selezionate tutte le visualizzazioni di pagina.
backupOneRestoreAll Esegui il backup di una copia di un pod selezionato e utilizzala per ripristinare tutti i pod.
backupTargetName Il nome del Deployment o del StatefulSet preferito da utilizzare per il backup.
backupPreHooks Elenco degli hook da eseguire prima del backup.
backupPostHooks Elenco degli hook da eseguire dopo il backup.
volumeSelector Selettore di etichette che specifica i volumi permanenti di cui eseguire il backup. Se vuoto, vengono selezionate tutte le visualizzazioni di pagina.
dumpAndLoad Utilizza un volume dedicato per il backup e il ripristino.
dumpTarget Specifica il nome del Deployment o StatefulSet preferito utilizzato per scaricare i dati dei componenti. Il pod di destinazione viene selezionato in base alla composizione di questo componente:
  • Deployment: scegli l'unico pod creato dal target Deployment.
  • Single-StatefulSet: scegli il secondo pod creato dal target StatefulSet se il numero di repliche è maggiore di due. Altrimenti, scegli l'unico pod.
  • Multi-StatefulSet: scegli il primo pod creato dal target StatefulSet
loadTarget Specifica il nome del Deployment o StatefulSet preferito utilizzato per caricare i dati dei componenti. Il pod di destinazione viene selezionato in base alla composizione di questo componente:
  • Deployment: scegli l'unico pod creato dal target Deployment.
  • StatefulSet: scegli sempre il primo pod creato dalla destinazione StatefulSet.
dumpHooks Elenco degli hook utilizzati per il dump dei dati.
backupPostHooks Elenco degli hook da eseguire dopo il backup.
loadHooks Elenco degli hook utilizzati per caricare i dati di questo componente dal volume dedicato. Potrebbe anche includere passaggi di pulizia dopo il caricamento. Il pod di destinazione dell'esecuzione è uno dei pod selezionati da LoadTarget.
volumeSelector Selettore di etichette che specifica i volumi permanenti di cui eseguire il backup. Se vuoto, vengono selezionate tutte le visualizzazioni di pagina.

Esegui il backup di tutto e ripristina tutto

Questa strategia esegue il backup di tutte le risorse dell'applicazione durante il backup e le ripristina tutte durante il ripristino. Questa strategia è più adatta alle applicazioni autonome, in cui non è presente alcuna replica tra i pod.

Per una strategia di backup e ripristino di tutto, includi le seguenti informazioni nella definizione della risorsa:

  • Hook: definisci i comandi eseguiti prima e dopo l'esecuzione dei backup del volume, ad esempio i passaggi di quiescenza e annullamento della quiescenza dell'applicazione. Questi comandi vengono eseguiti su tutti i pod all'interno di un componente.

  • Selezione del volume: offre una granularità più precisa sui volumi di cui viene eseguito il backup e il ripristino all'interno del componente. I volumi non selezionati non vengono sottoposti a backup. Durante un ripristino, tutti i volumi ignorati durante il backup vengono ripristinati come volumi vuoti.

Questo esempio crea una risorsa ProtectedApplication che sospende il file system prima di eseguire il backup del volume dei log e lo riattiva dopo il backup:

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 ]

Esegui il backup di uno e ripristina tutti

Questa strategia esegue il backup di una copia di un pod selezionato. Questa singola copia è l'origine per il ripristino di tutti i pod durante un ripristino. Questo metodo può contribuire a ridurre i costi di archiviazione e i tempi di backup. Questa strategia funziona in una configurazione ad alta disponibilità quando un componente viene implementato con un PersistentVolumeClaim primario e più PersistentVolumeClaims secondari.

Per una strategia di backup e ripristino di tutti i dati, devi includere le seguenti informazioni nella definizione della risorsa:

  • Destinazione del backup: specifica quale Deployment o StatefulSet utilizzare per eseguire il backup dei dati. Viene selezionato automaticamente il pod migliore per il backup. In una configurazione ad alta disponibilità, Google consiglia di eseguire il backup da un PersistentVolumeClaim secondario.
  • Hook: definisce i comandi eseguiti prima e dopo l'esecuzione dei backup dei volumi, ad esempio i passaggi di quiescenza e annullamento della quiescenza dell'applicazione. Questi comandi vengono eseguiti solo sul pod di backup selezionato.
  • Selezione del volume: offre una granularità più precisa per i volumi di cui viene eseguito il backup e il ripristino all'interno del componente.

Se un componente è configurato con più risorse Deployment o StatefulSet, tutte le risorse devono avere la stessa struttura PersistentVolume e rispettare queste regole:

  • Il numero di risorse PersistentVolumeClaim utilizzate da tutte le risorse Deployment o StatefulSet deve essere lo stesso.
  • Lo scopo delle risorse PersistentVolumeClaim nello stesso indice deve essere lo stesso. Per le risorse StatefulSet, l'indice è definito in volumeClaimTemplate. Per le risorse Deployment, l'indice è definito nelle risorse Volume e tutti i volumi non permanenti vengono ignorati.

Tenendo conto di queste considerazioni, è possibile selezionare più set di volumi per il backup, ma viene selezionato un solo volume da ogni set di volumi.

Questo esempio, che presuppone un'architettura di un StatefulSet primario e un StatefulSet secondario, mostra un backup dei volumi all'interno di un singolo pod in un StatefulSet secondario e poi un ripristino di tutti gli altri volumi:

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

Dump and load

Questa strategia utilizza un volume dedicato per i processi di backup e ripristino e richiede un PersistentVolumeClaim dedicato collegato a un componente che archivia i dati di dump. Per una strategia di dump e caricamento, includi le seguenti informazioni nella definizione della risorsa:

  • Destinazione dump:specifica quale Deployment o StatefulSet deve essere utilizzato per eseguire il dump dei dati. Viene selezionato automaticamente il pod migliore per il backup. In una configurazione ad alta disponibilità, è consigliabile eseguire il backup da un PersistentVolumeClaim secondario.
  • Destinazione di caricamento:specifica quale Deployment o StatefulSet deve essere utilizzato per caricare i dati. Viene selezionato automaticamente il pod migliore per il backup. La destinazione di caricamento non deve necessariamente corrispondere alla destinazione di dump.
  • Hook:definisce i comandi eseguiti prima e dopo l'esecuzione dei backup del volume. Esistono hook specifici che devi definire per le strategie di dump e caricamento:
    • Dump hooks:definisce gli hook che scaricano i dati nel volume dedicato prima del backup. Questo hook viene eseguito solo sul pod dump selezionato.
    • Hook di caricamento:definisce gli hook che caricano i dati dopo l'avvio dell'applicazione. Questo hook viene eseguito solo sul pod di caricamento selezionato.
    • (Facoltativo) Hook post-backup: definisce gli hook eseguiti dopo il backup dei volumi dedicati, ad esempio i passaggi di pulizia. Questo hook viene eseguito solo sul pod di dump selezionato.
  • Selezione del volume:specifica tutti i volumi dedicati che archiviano i dati di dump. Devi selezionare un solo volume per ogni pod di dump e caricamento.

Se l'applicazione è costituita da Deployments, ogni Deployment deve avere esattamente una replica.

Questo esempio, che presuppone un'architettura di un StatefulSet primario e un StatefulSet secondario con PersistentVolumeClaims dedicati sia per StatefulSet primario che secondario StatefulSets, mostra una strategia di dump e caricamento:

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

Passaggi successivi