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:

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

Tipo Atributo Descrição
BackupAllRestoreAll Fazer uma cópia de segurança e restaurar tudo no componente.
backupPreHooks Lista de hooks a executar antes da cópia de segurança.
backupPostHooks Lista de hooks a executar após a cópia de segurança.
volumeSelector Seletor de etiquetas que especifica os volumes persistentes dos quais fazer uma cópia de segurança. Se estiver vazio, todas as PVs são selecionadas.
backupOneRestoreAll Fazer uma cópia de segurança de um pod selecionado e usá-la para restaurar todos os pods.
backupTargetName O nome do dispositivo Deployment ou StatefulSet preferencial a usar para a cópia de segurança.
backupPreHooks Lista de hooks a executar antes da cópia de segurança.
backupPostHooks Lista de hooks a executar após a cópia de segurança.
volumeSelector Seletor de etiquetas que especifica os volumes persistentes dos quais fazer uma cópia de segurança. Se estiver vazio, todas as PVs são selecionadas.
dumpAndLoad Usa um volume dedicado para a cópia de segurança e o restauro.
dumpTarget Especifica o nome do Deployment preferido ou do StatefulSet que é usado para transferir os dados dos componentes. O alvo pod é selecionado com base na composição deste componente:
  • Implementação: escolha o único pod criado pelo destino Deployment.
  • Single-StatefulSet: escolha o segundo pod criado pelo destino StatefulSet se o número de réplicas for superior a dois. Caso contrário, escolha o único pod.
  • Multi-StatefulSet: escolha o primeiro pod criado pelo destino StatefulSet
loadTarget Especifica o nome do Deployment preferencial ou do StatefulSet que é usado para carregar os dados do componente. O alvo pod é selecionado com base na composição deste componente:
  • Implementação: escolha o único pod criado pelo destino Deployment.
  • StatefulSet: escolha sempre o primeiro pod criado pelo destino StatefulSet.
dumpHooks Lista de hooks que são usados para despejar os dados.
backupPostHooks Lista de hooks a executar após a cópia de segurança.
loadHooks Lista de hooks usados para carregar os dados deste componente a partir de um volume dedicado. Também pode incluir passos de limpeza após a conclusão do carregamento. O pod de destino de execução é um dos pods selecionados a partir de LoadTarget.
volumeSelector Seletor de etiquetas que especifica os volumes persistentes dos quais fazer uma cópia de segurança. Se estiver vazio, todas as PVs são selecionadas.

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?