Estrategias de aplicaciones protegidas

En esta página, se describen las diferentes estrategias de protección de aplicaciones disponibles en Google Distributed Cloud (GDC) con aislamiento físico.

Las estrategias de aplicaciones protegidas te permiten ejecutar hooks específicos previos y posteriores a la ejecución, y definir un comportamiento personalizado para la inactividad, la copia de seguridad o el restablecimiento de una carga de trabajo con estado.

Existen tres estrategias de copia de seguridad y restablecimiento que puedes usar cuando defines un recurso ProtectedApplication:

• Crear una copia de seguridad de todo y restablecer todo
• Crear una copia de seguridad de uno y restablecer todo
• Realizar una operación de volcado y carga

Las definiciones de estrategia pueden incluir los siguientes valores:

Crear una copia de seguridad de todo y restablecer todo

Esta estrategia crea una copia de seguridad de todos los recursos de la aplicación durante la copia de seguridad y los restablece durante la restauración. Esta estrategia funciona mejor para las aplicaciones independientes, en las que no hay replicación entre los Pods.

Para la estrategia de Crear una copia de seguridad de todo y restablecer todo, incluye la siguiente información en la definición del recurso:

• Hooks: Define los comandos que se ejecutan antes y después de realizar copias de seguridad de los volúmenes, como los pasos de activación y desactivación de la aplicación. Estos comandos se ejecutan en todos los Pods dentro de un componente.

• Selección de volumen: Proporciona un nivel de detalle más preciso sobre los volúmenes para los que se crea una copia de seguridad y que se restablecen dentro del componente. No se crea una copia de seguridad de los volúmenes no seleccionados. Durante un restablecimiento, los volúmenes que se omiten durante la creación de la copia de seguridad se restablecen como volúmenes vacíos.

En este ejemplo, se crea un recurso ProtectedApplication que desactiva el sistema de archivos antes de crear una copia de seguridad del volumen de registros y lo vuelve a activar después de 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 de uno y restablecer todo

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

Para la estrategia de Crear una copia de seguridad de uno y restablecer todo, debes incluir la siguiente información en la definición del recurso:

• Destino de copia de seguridad: Especifica qué Deployment o StatefulSet se debe usar para crear una copia de seguridad de los datos. Se selecciona automáticamente el mejor Pod para crear una copia de seguridad. En una configuración de alta disponibilidad, Google recomienda crear una copia de seguridad desde una PersistentVolumeClaim secundaria.
• Hooks: Define los comandos que se ejecutan antes y después de realizar copias de seguridad de los volúmenes, como los pasos de activación y desactivación de la aplicación. Estos comandos solo se ejecutan en el pod de copia de seguridad seleccionado.
• Selección de volumen: Proporciona un nivel de detalle más preciso sobre los volúmenes para los que se crea una copia de seguridad y que se restablecen dentro del componente.

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

• La cantidad de recursos PersistentVolumeClaim que usan todos los recursos Deployment o StatefulSet debe ser la misma.
• El propósito de los recursos PersistentVolumeClaim en el mismo índice debe ser el mismo. Para los recursos StatefulSet, el índice se define en volumeClaimTemplate. Para los recursos Deployment, el índice se define en los recursos Volume y se omiten los volúmenes no persistentes.

Según estas consideraciones, se pueden seleccionar varios conjuntos de volúmenes para la copia de seguridad, pero solo se seleccionará un volumen de cada conjunto de volúmenes.

En este ejemplo, si suponemos que se usa una arquitectura de un StatefulSet principal y un StatefulSet secundario, se muestra una copia de seguridad de los volúmenes dentro de un solo pod en un StatefulSet secundario y, luego, un restablecimiento a 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: [...]

Realizar una operación de volcado y carga

Esta estrategia usa un volumen dedicado para los procesos de copia de seguridad y restablecimiento, y requiere una PersistentVolumeClaim dedicada adjunta a un componente que almacena datos de volcado. Para la estrategia de Realizar una operación de volcado y carga, incluye la siguiente información en la definición del recurso:

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

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

En este ejemplo, si suponemos que hay una arquitectura de un StatefulSet principal y un StatefulSet secundario con una PersistentVolumeClaims dedicada para los StatefulSets principales y secundarios, se muestra una estrategia de volcado y de 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

¿Qué sigue?

• Planifica un conjunto de copias de seguridad