Estratégias de aplicação protegidas

Esta página descreve as diferentes estratégias de aplicações protegidas disponíveis no Google Distributed Cloud (GDC) air-gapped.

As estratégias de aplicação protegidas permitem-lhe executar hooks específicos de pré-execução e pós-execução, bem como definir um comportamento personalizado para a suspensão, a cópia de segurança ou o restauro de uma carga de trabalho com estado.

Existem três estratégias de cópia de segurança e restauro que pode usar quando define um recurso ProtectedApplication:

• Fazer uma cópia de segurança de tudo e restaurar tudo
• Crie uma cópia de segurança de um e restaure todos
• Despejar e carregar

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

Fazer uma cópia de segurança de tudo e restaurar tudo

Esta estratégia faz uma cópia de segurança de todos os recursos da aplicação durante a cópia de segurança e restaura todos esses recursos durante o restauro. Esta estratégia funciona melhor para aplicações autónomas, em que as aplicações não têm replicação entre pods.

Para uma estratégia de fazer uma cópia de segurança de tudo e restaurar tudo, inclua as seguintes informações na definição do recurso:

• Hooks: define comandos que são executados antes e depois de fazer cópias de segurança de volumes, como passos de suspensão e retoma da aplicação. Estes comandos são executados em todos os pods num componente.

• Seleção de volumes: oferece uma granularidade mais precisa sobre os volumes dos quais é feita uma cópia de segurança e que são restaurados no componente. Não é feita uma cópia de segurança dos volumes não selecionados. Durante um restauro, todos os volumes ignorados durante a cópia de segurança são restaurados como volumes vazios.

Este exemplo cria um recurso ProtectedApplication que desativa o sistema de ficheiros antes de fazer uma cópia de segurança do volume de registos e reativa-o após a cópia de segurança:

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 ]

Faça uma cópia de segurança e restaure tudo

Esta estratégia faz uma cópia de segurança de um pod selecionado. Esta única cópia é a origem para restaurar todos os pods durante um restauro. Este método pode ajudar a reduzir o custo de armazenamento e o tempo de cópia de segurança. Esta estratégia funciona numa configuração de alta disponibilidade quando um componente é implementado com um principal PersistentVolumeClaim e vários secundários PersistentVolumeClaims.

Para uma estratégia de fazer uma cópia de segurança e restaurar tudo, tem de incluir as seguintes informações na definição de recursos:

• Destino da cópia de segurança: especifica que Deployment ou StatefulSet usar para fazer uma cópia de segurança dos dados. O melhor pod para fazer uma cópia de segurança é selecionado automaticamente. Numa configuração de elevada disponibilidade, a Google recomenda que faça uma cópia de segurança a partir de um PersistentVolumeClaim secundário.
• Hooks: define comandos que são executados antes e depois de fazer cópias de segurança de volumes, como passos de suspensão e retoma de aplicações. Estes comandos só são executados no pod de cópia de segurança selecionado.
• Seleção de volumes: oferece uma granularidade mais precisa sobre os volumes dos quais é feita uma cópia de segurança e que são restaurados no componente.

Se um componente estiver configurado com vários recursos Deployment ou StatefulSet, todos os recursos têm de ter a mesma estrutura PersistentVolume e seguir estas regras:

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

Tendo em conta estas considerações, podem ser selecionados vários conjuntos de volumes para a cópia de segurança, mas apenas é selecionado um volume de cada conjunto de volumes.

Este exemplo, partindo do princípio de uma arquitetura com um StatefulSet principal e um StatefulSet secundário, mostra uma cópia de segurança dos volumes num único pod num StatefulSet secundário e, em seguida, um restauro 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: [...]

Capturar e carregar

Esta estratégia usa um volume dedicado para processos de cópia de segurança e restauro e requer um PersistentVolumeClaim dedicado anexado a um componente que armazena dados de despejo. Para uma estratégia de descarga e carregamento, inclua as seguintes informações na definição do recurso:

• Destino de despejo: especifica que Deployment ou StatefulSet deve ser usado para despejar os dados. O melhor pod para fazer uma cópia de segurança é selecionado automaticamente. Numa configuração de alta disponibilidade, recomenda-se fazer uma cópia de segurança a partir de um PersistentVolumeClaim secundário.
• Destino do carregamento: especifica que Deployment ou StatefulSet deve ser usado para carregar os dados. O melhor pod para fazer uma cópia de segurança é selecionado automaticamente. O destino de carregamento não tem de ser o mesmo que o destino de despejo.
• Hooks: define os comandos que são executados antes e depois de fazer cópias de segurança dos volumes. Existem hooks específicos que tem de definir para estratégias de descarga e carregamento:
  • Dump hooks: define os hooks que transferem os dados para o volume dedicado antes da cópia de segurança. Este gancho é executado apenas no pod de despejo selecionado.
  • Load hooks: define os hooks que carregam os dados após o início da aplicação. Este gancho é executado apenas no pod de carregamento selecionado.
  • Opcional: hooks pós-cópia de segurança: define os hooks que são executados após a criação de cópias de segurança dos volumes dedicados, como passos de limpeza. Este hook é executado apenas no pod de despejo selecionado.
• Seleção de volume: especifica todos os volumes dedicados que armazenam os dados de despejo. Tem de selecionar apenas um volume para cada contentor de despejo e carregamento.

Se a aplicação consistir em Deployments, cada Deployment tem de ter exatamente uma réplica.

Este exemplo, partindo do princípio de uma arquitetura de um StatefulSet principal e um StatefulSet secundário com PersistentVolumeClaims dedicados para o StatefulSet principal e o StatefulSets secundário, mostra uma estratégia de descarga 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

O que se segue?

• Planeie um conjunto de cópias de segurança