Estratégias de aplicativos protegidos

Nesta página, descrevemos as diferentes estratégias de aplicativos protegidos disponíveis no Google Distributed Cloud (GDC) isolado.

Com as estratégias de aplicativos protegidos, é possível executar hooks específicos de pré e pós-execução e definir um comportamento personalizado para inatividade, backup ou restauração de uma carga de trabalho com estado.

Há três estratégias de backup e restauração que podem ser usadas ao definir um recurso ProtectedApplication:

• Fazer backup de tudo e restaurar tudo
• Fazer backup de uma e restaurar tudo
• Despejar e carregar

As definições de estratégia podem incluir os seguintes valores:

Fazer backup de tudo e restaurar tudo

Essa estratégia faz backup de todos os recursos do aplicativo durante o backup e os restaura durante a restauração. Essa estratégia funciona melhor para aplicativos independentes, em que não há replicação entre os pods.

Para uma estratégia de backup de tudo e restauração de tudo, inclua as seguintes informações na definição do recurso:

• Hooks: define comandos que são executados antes e depois de fazer backups de volume, como as ações de quiesco e o cancelamento de ações do aplicativo. Esses comandos são executados em todos os pods dentro de um componente.

• Seleção de volume: oferece granularidade mais refinada para os volumes que são armazenados em backup e restaurados no componente. Os volumes não selecionados não serão salvos em backup. Durante uma restauração, todos os volumes ignorados durante o backup são restaurados como volumes vazios.

Este exemplo cria um recurso ProtectedApplication que desativa o sistema de arquivos antes de fazer backup do volume de registros e cancela a desativação após o 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 ]

Fazer backup de uma e restaurar tudo

Essa estratégia faz backup de uma cópia de um pod selecionado. Essa cópia única é a fonte para restaurar todos os pods durante uma restauração. Esse método ajuda a reduzir o custo de armazenamento e o tempo de backup. Essa estratégia funciona em uma configuração de alta disponibilidade quando um componente é implantado com um PersistentVolumeClaim primário e vários PersistentVolumeClaims secundários.

Para uma estratégia de backup e restauração de tudo, inclua as seguintes informações na definição do recurso:

• Destino do backup: especifica qual Deployment ou StatefulSet usar para fazer backup dos dados. O melhor pod para fazer backup é selecionado automaticamente. Em uma configuração de alta disponibilidade, o Google recomenda fazer backup de um PersistentVolumeClaim secundário.
• Hooks: define comandos que são executados antes e depois de fazer backups de volume, como as ações de quiesco e o cancelamento de ações do aplicativo. Esses comandos são executados apenas no pod de backup selecionado.
• Seleção de volume: oferece granularidade mais refinada para os volumes que são armazenados em backup e restaurados no componente.

Se um componente for configurado com vários recursos Deployment ou StatefulSet, todos os recursos precisarão ter a mesma estrutura PersistentVolume e seguir estas regras:

• O número de recursos PersistentVolumeClaim usados por todos os recursos Deployment ou StatefulSet precisa ser o mesmo.
• A finalidade dos recursos PersistentVolumeClaim no mesmo índice precisa ser a mesma. Para recursos StatefulSet, o índice é definido no volumeClaimTemplate. Para recursos Deployment, o índice é definido em recursos Volume e todos os volumes não permanentes são ignorados.

Considerando essas considerações, vários conjuntos de volumes podem ser selecionados para backup, mas apenas um volume de cada conjunto é selecionado.

Neste exemplo, supondo uma arquitetura de um StatefulSet principal e um StatefulSet secundário, mostramos um backup dos volumes em um único pod em um StatefulSet secundário e uma restauração para todos os outros 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: [...]

Despejo e carregamento

Essa estratégia usa um volume dedicado para processos de backup e restauração e requer um PersistentVolumeClaim dedicado anexado a um componente que armazena dados dump. Para uma estratégia de despejo e carregamento, inclua as seguintes informações na definição do recurso:

• Destino do despejo:especifica qual Deployment ou StatefulSet deve ser usado para despejar os dados. O melhor pod para fazer backup é selecionado automaticamente. Em uma configuração de alta disponibilidade, é recomendado fazer backup de um PersistentVolumeClaim secundário.
• Destino de carregamento:especifica qual Deployment ou StatefulSet deve ser usado para carregar os dados. O melhor pod para fazer backup é selecionado automaticamente. O destino de carregamento não precisa ser o mesmo que o destino de despejo.
• Hooks:define os comandos que são executados antes e depois de fazer backups de volume. Há hooks específicos que precisam ser definidos para as estratégias de despejo e carregamento:
  • Dump hooks:define os hooks que despejam os dados no volume dedicado antes do backup. Esse hook é executado apenas no pod de despejo selecionado.
  • Hooks de carregamento:define os hooks que carregam os dados após o início do aplicativo. Esse hook é executado apenas no pod de carregamento selecionado.
  • Opcional - Hooks de pós-backup:define os hooks executados após o backup dos volumes dedicados, como etapas de limpeza. Esse hook é executado apenas no pod de despejo selecionado.
• Seleção de volume:especifica todos os volumes dedicados que armazenam os dados de despejo. Selecione apenas um volume para cada pod de despejo e carregamento.

Se o aplicativo consistir em Deployments, cada Deployment precisará ter exatamente uma réplica.

Neste exemplo, supondo uma arquitetura de um StatefulSet principal e um StatefulSet secundário com PersistentVolumeClaims dedicado para StatefulSets principal e secundário, mostramos uma estratégia de despejo e carregamento:

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

A seguir

• Planejar um conjunto de backups