Estrategias de aplicaciones protegidas

En esta página se describen las diferentes estrategias de aplicaciones protegidas disponibles en Google Distributed Cloud (GDC) aislado.

Las estrategias de aplicaciones protegidas te permiten ejecutar hooks específicos antes y después de la ejecución, así como definir un comportamiento personalizado para detener, crear copias de seguridad o restaurar una carga de trabajo con estado.

Hay tres estrategias de copia de seguridad y restauración que puedes usar al definir un recurso ProtectedApplication:

• Crear una copia de seguridad de todo y restaurarlo todo
• Crear una copia de seguridad y restaurar todo
• Volcado y carga

Las definiciones de estrategia pueden incluir los siguientes valores:

Crear una copia de seguridad de todo y restaurarlo todo

Esta estrategia crea una copia de seguridad de todos los recursos de la aplicación durante el proceso y restaura todos esos recursos durante la restauración. Esta estrategia funciona mejor en aplicaciones independientes, en las que no hay replicación entre pods.

En el caso de una estrategia de copia de seguridad y restauración completas, incluya la siguiente información en la definición de recursos:

• Hooks: definen los comandos que se ejecutan antes y después de crear copias de seguridad de volúmenes, como los pasos de quiescencia y no quiescencia de las aplicaciones. Estos comandos se ejecutan en todos los pods de un componente.

• Selección de volumen: ofrece una granularidad más precisa sobre qué volúmenes se crean como copia de seguridad y se restauran en el componente. Los volúmenes que no se seleccionen no se incluirán en la copia de seguridad. Durante una restauración, los volúmenes que se hayan omitido durante la copia de seguridad se restaurarán como volúmenes vacíos.

En este ejemplo se crea un recurso ProtectedApplication que detiene el sistema de archivos antes de crear una copia de seguridad del volumen de los registros y lo reactiva después de crear la copia de seguridad:

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 ]

Crear una copia de seguridad y restaurar todo

Esta estrategia crea una copia de seguridad de un pod seleccionado. Esta única copia es la fuente para restaurar todos los pods durante una restauración. Este método puede ayudar a reducir el coste de almacenamiento y el tiempo de creación de copias de seguridad. Esta estrategia funciona en una configuración de alta disponibilidad cuando un componente se implementa con un elemento principal PersistentVolumeClaim y varios secundarios PersistentVolumeClaims.

Para crear una copia de seguridad y restaurar todos los datos, debes incluir la siguiente información en la definición de recursos:

• Destino de la copia de seguridad: especifica qué Deployment o StatefulSet se va a usar para crear la copia de seguridad de los datos. Se selecciona automáticamente el mejor pod para crear la copia de seguridad. En una configuración de alta disponibilidad, Google recomienda crear copias de seguridad desde un PersistentVolumeClaim secundario.
• Hooks: define los comandos que se ejecutan antes y después de crear copias de seguridad de volúmenes, como los pasos de quiescencia y no quiescencia de las aplicaciones. Estos comandos solo se ejecutan en el pod de copia de seguridad seleccionado.
• Selección de volumen: ofrece una granularidad más precisa sobre qué volúmenes se crean como copia de seguridad y se restauran en el componente.

Si un componente se configura con varios recursos Deployment o StatefulSet, todos los recursos deben tener la misma estructura PersistentVolume y seguir estas reglas:

• El número de recursos PersistentVolumeClaim que usan todos los recursos Deployment o StatefulSet debe ser el mismo.
• Los recursos PersistentVolumeClaim del mismo índice deben tener el mismo propósito. En el caso de los recursos StatefulSet, el índice se define en volumeClaimTemplate. En el caso de los recursos de Deployment, el índice se define en los recursos de Volume y se omiten los volúmenes no persistentes.

Teniendo en cuenta estas consideraciones, se pueden seleccionar varios conjuntos de volúmenes para la copia de seguridad, pero solo se selecciona un volumen de cada conjunto.

En este ejemplo, que presupone una arquitectura de un StatefulSet principal y un StatefulSet secundario, se muestra una copia de seguridad de los volúmenes de un solo pod en un StatefulSet secundario y, a continuación, una restauración de todos los demás volúmenes:

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

Volcado y carga

Esta estrategia usa un volumen específico para los procesos de copia de seguridad y restauración, y requiere un PersistentVolumeClaim específico conectado a un componente que almacene datos de volcado. En el caso de una estrategia de volcado y carga, incluya la siguiente información en la definición de recursos:

• Destino del volcado: especifica qué Deployment o StatefulSet se debe usar para volcar los datos. Se selecciona automáticamente el mejor pod para crear la copia de seguridad. En una configuración de alta disponibilidad, se recomienda crear copias de seguridad desde una PersistentVolumeClaim secundaria.
• Carga de destino: especifica qué Deployment o StatefulSet se debe usar para cargar los datos. Se selecciona automáticamente el mejor pod para crear la copia de seguridad. El destino de carga no tiene por qué ser el mismo que el destino de volcado.
• Enlace: define los comandos que se ejecutan antes y después de crear copias de seguridad del volumen. Debes definir ganchos específicos para las estrategias de volcado y carga:
  • Hooks de volcado: define los hooks que vuelcan los datos en el volumen dedicado antes de crear la copia de seguridad. Este hook solo se ejecuta en el pod de volcado seleccionado.
  • Hooks de carga: define los hooks que cargan los datos después de que se inicie la aplicación. Este hook solo se ejecuta en el pod de carga seleccionado.
  • Opcional: ganchos posteriores a la copia de seguridad: define los ganchos que se ejecutan después de crear una copia de seguridad de los volúmenes dedicados, como los pasos de limpieza. Este hook solo se ejecuta en el pod de volcado seleccionado.
• Selección de volumen: especifica todos los volúmenes dedicados que almacenan los datos de volcado. Solo debes seleccionar un volumen para cada pod de volcado y carga.

Si la aplicación consta de Deployments, cada Deployment debe tener exactamente una réplica.

En este ejemplo, se presupone una arquitectura de un StatefulSet principal y un StatefulSet secundario con PersistentVolumeClaims dedicados tanto al StatefulSet principal como al secundario StatefulSets. Se muestra una estrategia de volcado y carga:

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

Siguientes pasos

• Programar un conjunto de copias de seguridad