Skip to main content
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Replicar aplicaciones con NetApp SnapMirror y Trident Protect

Colaboradores
PDF

Con Trident Protect, puede usar las funcionalidades de replicación asíncrona de la tecnología NetApp SnapMirror para replicar datos y cambios de aplicaciones de un back-end de almacenamiento a otro, en el mismo clúster o entre diferentes clústeres.

Etiquetas y anotaciones del espacio de nombres durante las operaciones de restauración y conmutación al nodo de respaldo

Durante las operaciones de restauración y conmutación al nodo de respaldo, se realizan etiquetas y anotaciones en el espacio de nombres de destino que coincidan con las etiquetas y anotaciones en el espacio de nombres de origen. Se añaden etiquetas o anotaciones del espacio de nombres origen que no existen en el espacio de nombres destino, y las etiquetas o anotaciones que ya existan se sobrescriben para que coincidan con el valor del espacio de nombres origen. Las etiquetas o anotaciones que sólo existen en el espacio de nombres de destino permanecen sin cambios.

Nota Si utiliza RedHat OpenShift, es importante tener en cuenta el papel fundamental de las anotaciones de espacio de nombres en entornos OpenShift. Las anotaciones del espacio de nombres garantizan que los pods restaurados cumplan los permisos y las configuraciones de seguridad adecuados definidos por las restricciones de contexto de seguridad (SCCs) de OpenShift y puedan acceder a los volúmenes sin problemas de permiso. Para obtener más información, consulte la "Documentación de restricciones de contexto de seguridad de OpenShift".

Puede evitar que se sobrescriban anotaciones específicas en el espacio de nombres de destino mediante el establecimiento de la variable de entorno de Kubernetes RESTORE_SKIP_NAMESPACE_ANNOTATIONS antes de llevar a cabo la operación de restauración o conmutación por error. Por ejemplo:

kubectl set env -n trident-protect deploy/trident-protect-controller-manager RESTORE_SKIP_NAMESPACE_ANNOTATIONS=<annotation_key_to_skip_1>,<annotation_key_to_skip_2>

Si instaló la aplicación de origen con Helm con el --create-namespace indicador, se le dará un tratamiento especial a la name clave de etiqueta. Durante el proceso de restauración o recuperación tras fallos, Trident protege esta etiqueta al espacio de nombres de destino, pero actualiza el valor al valor del espacio de nombres de destino si el valor del origen coincide con el espacio de nombres de origen. Si este valor no coincide con el espacio de nombres de origen, se copia al espacio de nombres de destino sin cambios.

Ejemplo

El siguiente ejemplo presenta un espacio de nombres de origen y destino, cada uno con anotaciones y etiquetas diferentes. Puede ver el estado del espacio de nombres de destino antes y después de la operación, así como cómo las anotaciones y etiquetas se combinan o sobrescriben en el espacio de nombres de destino.

Antes de la operación de restauración o conmutación por error

En la siguiente tabla se muestra el estado del ejemplo de espacios de nombres de origen y destino antes de la operación de restauración o conmutación por error:

Espacio de nombres Anotaciones Etiquetas

Espacio de nombres ns-1 (origen)

  • anotación.uno/clave: “updatedvalue”

  • anotación.dos/clave: “verdadero”

  • entorno=producción

  • cumplimiento=hipaa

  • name=ns-1

Espacio de nombres ns-2 (destino)

  • anotación.uno/tecla: “verdadero”

  • anotación.tres/clave: “falso”

  • role=base de datos

Después de la operación de restauración

En la siguiente tabla se muestra el estado del espacio de nombres de destino de ejemplo después de la operación de restauración o conmutación por error. Se han agregado algunas claves, algunas se han sobrescrito y la name etiqueta se ha actualizado para que coincida con el espacio de nombres de destino:

Espacio de nombres Anotaciones Etiquetas

Espacio de nombres ns-2 (destino)

  • anotación.uno/clave: “updatedvalue”

  • anotación.dos/clave: “verdadero”

  • anotación.tres/clave: “falso”

  • name=ns-2

  • cumplimiento=hipaa

  • entorno=producción

  • role=base de datos
Nota Puede configurar Trident Protect para congelar y descongelar sistemas de archivos durante las operaciones de protección de datos. "Obtenga más información sobre cómo configurar la congelación del sistema de archivos con Trident Protect".

Configurar una relación de replicación

La configuración de una relación de replicación implica lo siguiente:

  • Elegir con qué frecuencia quieres que Trident Protect tome una instantánea de la aplicación (que incluye los recursos de Kubernetes de la aplicación, así como las instantáneas de volumen de cada uno de los volúmenes de la aplicación)

  • Elegir el programa de replicación (incluye recursos de Kubernetes, así como datos de volumen persistentes)

  • Establecer la hora para que se realice la snapshot

Pasos

  1. Cree un AppVault para la aplicación de origen en el clúster de origen. Según su proveedor de almacenamiento, modifique un ejemplo en "Recursos personalizados de AppVault" Para adaptarse a su entorno:

    Cree un AppVault con un CR

    1. Cree el archivo de recursos personalizados (CR) y asígnele un nombre (por ejemplo, trident-protect-appvault-primary-source.yaml).

    2. Configure los siguientes atributos:

      • metadata.name: (required) El nombre del recurso personalizado de AppVault. Tome nota del nombre que elija, ya que otros archivos CR necesarios para una relación de replicación hacen referencia a este valor.

      • spec.providerConfig: (required) almacena la configuración necesaria para acceder a AppVault utilizando el proveedor especificado. Elija un nombre de bucketName y cualquier otro detalle necesario para su proveedor. Tome nota de los valores que elija, ya que otros archivos CR necesarios para una relación de replicación hacen referencia a estos valores. Consulte "Recursos personalizados de AppVault"para ver ejemplos de CRS de AppVault con otros proveedores.

      • spec.providerCredentials: (required) almacena referencias a cualquier credencial necesaria para acceder a AppVault utilizando el proveedor especificado.

        • spec.providerCredentials.valueFromSecret: (required) indica que el valor de la credencial debe provenir de un secreto.

          • KEY: (REQUIRED) La clave válida del secreto para seleccionar.

          • Name: (required) Nombre del secreto que contiene el valor para este campo. Debe estar en el mismo espacio de nombres.

        • spec.providerCredentials.secretAccessKey: (required) La clave de acceso utilizada para acceder al proveedor. El name debe coincidir con spec.providerCredentials.valueFromSecret.name.

      • spec.providerType: (required) determina qué proporciona la copia de seguridad; por ejemplo, NetApp ONTAP S3, S3 genérico, Google Cloud o Microsoft Azure. Los posibles valores son los siguientes:

        • aws

        • azure

        • gcp

        • genérico-s3

        • ONTAP-s3

        • StorageGRID-s3

    3. Después de rellenar trident-protect-appvault-primary-source.yaml el archivo con los valores correctos, aplique el CR:

      kubectl apply -f trident-protect-appvault-primary-source.yaml -n trident-protect
    Cree un AppVault con la CLI

    1. Cree AppVault, reemplazando los valores entre paréntesis con información de su entorno:

      tridentctl protect create vault Azure <vault-name> --account <account-name> --bucket <bucket-name> --secret <secret-name>

  2. Cree la aplicación de origen CR:

    Cree la aplicación de origen mediante un CR

    1. Cree el archivo de recursos personalizados (CR) y asígnele un nombre (por ejemplo, trident-protect-app-source.yaml).

    2. Configure los siguientes atributos:

      • metadata.name: (required) El nombre del recurso personalizado de la aplicación. Tome nota del nombre que elija, ya que otros archivos CR necesarios para una relación de replicación hacen referencia a este valor.

      • spec.includedNamespaces: (required) Una matriz de espacios de nombres y etiquetas asociadas. Utilice nombres de espacio de nombres y, opcionalmente, reduzca el ámbito de los espacios de nombres con etiquetas para especificar los recursos que existen en los espacios de nombres que se muestran aquí. El espacio de nombres de la aplicación debe formar parte de esta cabina.

        Ejemplo YAML:

      apiVersion: protect.trident.netapp.io/v1
kind: Application
metadata:
  name: maria
  namespace: my-app-namespace
spec:
  includedNamespaces:
    - namespace: maria
      labelSelector: {}

    3. Después de rellenar trident-protect-app-source.yaml el archivo con los valores correctos, aplique el CR:

      kubectl apply -f trident-protect-app-source.yaml -n my-app-namespace
    Cree la aplicación de origen mediante la CLI

    1. Cree la aplicación de origen. Por ejemplo:

      tridentctl protect create app maria --namespaces maria -n my-app-namespace

  3. Si lo desea, realice una instantánea de la aplicación de origen. Esta copia Snapshot se utiliza como base de la aplicación en el clúster de destino. Si omite este paso, deberá esperar a que se ejecute la siguiente instantánea programada para que tenga una instantánea reciente.

    Tome una instantánea con un CR

    1. Cree un programa de replicación para la aplicación de origen:

      1. Cree el archivo de recursos personalizados (CR) y asígnele un nombre (por ejemplo, trident-protect-schedule.yaml).

      2. Configure los siguientes atributos:

        • metadata.name: (required) El nombre del recurso personalizado de horario.

        • Spec.AppVaultRef: (required) Este valor debe coincidir con el campo metadata.name del AppVault para la aplicación de origen.

        • Spec.ApplicationRef: (required) Este valor debe coincidir con el campo metadata.name de la aplicación de origen CR.

        • Spec.backupRetention: (required) Este campo es obligatorio y el valor debe establecerse en 0.

        • Spec.enabled: Debe establecerse en true.

        • spec.granularity: debe ser establecido en Custom.

        • Spec.recurrenceRule: Define una fecha de inicio en la hora UTC y un intervalo de recurrencia.

        • Spec.snapshotRetention: Debe establecerse en 2.

          Ejemplo YAML:

      apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  name: appmirror-schedule-0e1f88ab-f013-4bce-8ae9-6afed9df59a1
  namespace: my-app-namespace
spec:
  appVaultRef: generic-s3-trident-protect-src-bucket-04b6b4ec-46a3-420a-b351-45795e1b5e34
  applicationRef: maria
  backupRetention: "0"
  enabled: true
  granularity: custom
  recurrenceRule: |-
    DTSTART:20220101T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  snapshotRetention: "2"

      1. Después de rellenar trident-protect-schedule.yaml el archivo con los valores correctos, aplique el CR:

        kubectl apply -f trident-protect-schedule.yaml -n my-app-namespace
    Tome una instantánea utilizando la CLI

    1. Cree la instantánea, reemplazando valores entre paréntesis con información de su entorno. Por ejemplo:

      tridentctl protect create snapshot <my_snapshot_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot>

  4. Cree una aplicación de origen AppVault CR en el clúster de destino que sea idéntica a la aplicación AppVault CR que aplicó en el clúster de origen y asígnele el nombre (por ejemplo, trident-protect-appvault-primary-destination.yaml).

  5. Aplicar el CR:

    kubectl apply -f trident-protect-appvault-primary-destination.yaml -n my-app-namespace

  6. Cree un AppVault para la aplicación de destino en el clúster de destino. Según su proveedor de almacenamiento, modifique un ejemplo en "Recursos personalizados de AppVault" Para adaptarse a su entorno:

    1. Cree el archivo de recursos personalizados (CR) y asígnele un nombre (por ejemplo, trident-protect-appvault-secondary-destination.yaml).

    2. Configure los siguientes atributos:

      • metadata.name: (required) El nombre del recurso personalizado de AppVault. Tome nota del nombre que elija, ya que otros archivos CR necesarios para una relación de replicación hacen referencia a este valor.

      • spec.providerConfig: (required) almacena la configuración necesaria para acceder a AppVault utilizando el proveedor especificado. Elija un bucketName y cualquier otro detalle necesario para su proveedor. Tome nota de los valores que elija, ya que otros archivos CR necesarios para una relación de replicación hacen referencia a estos valores. Consulte "Recursos personalizados de AppVault"para ver ejemplos de CRS de AppVault con otros proveedores.

      • spec.providerCredentials: (required) almacena referencias a cualquier credencial necesaria para acceder a AppVault utilizando el proveedor especificado.

        • spec.providerCredentials.valueFromSecret: (required) indica que el valor de la credencial debe provenir de un secreto.

          • KEY: (REQUIRED) La clave válida del secreto para seleccionar.

          • Name: (required) Nombre del secreto que contiene el valor para este campo. Debe estar en el mismo espacio de nombres.

        • spec.providerCredentials.secretAccessKey: (required) La clave de acceso utilizada para acceder al proveedor. El name debe coincidir con spec.providerCredentials.valueFromSecret.name.

      • spec.providerType: (required) determina qué proporciona la copia de seguridad; por ejemplo, NetApp ONTAP S3, S3 genérico, Google Cloud o Microsoft Azure. Los posibles valores son los siguientes:

        • aws

        • azure

        • gcp

        • genérico-s3

        • ONTAP-s3

        • StorageGRID-s3

    3. Después de rellenar trident-protect-appvault-secondary-destination.yaml el archivo con los valores correctos, aplique el CR:

      kubectl apply -f trident-protect-appvault-secondary-destination.yaml -n my-app-namespace

  7. Cree un archivo CR de AppMirrorRelationship:

    Cree una AppMirrorRelationship con un CR

    1. Cree el archivo de recursos personalizados (CR) y asígnele un nombre (por ejemplo, trident-protect-relationship.yaml).

    2. Configure los siguientes atributos:

      • metadata.name: (requerido) El nombre del recurso personalizado AppMirrorRelationship.

      • spec.destinationAppVaultRef: (required) Este valor debe coincidir con el nombre de AppVault para la aplicación de destino en el clúster de destino.

      • spec.namespaceMapping: (required) Los espacios de nombres de destino y origen deben coincidir con el espacio de nombres de aplicación definido en la aplicación CR respectiva.

      • Spec.sourceAppVaultRef: (required) Este valor debe coincidir con el nombre de AppVault para la aplicación de origen.

      • Spec.sourceApplicationName: (required) Este valor debe coincidir con el nombre de la aplicación de origen que definió en la aplicación de origen CR.

      • Spec.storageClassName: (required) Elija el nombre de una clase de almacenamiento válida en el clúster. La clase de almacenamiento debe tener una relación entre iguales con la clase de almacenamiento que se esté usando en el clúster de origen donde se implementa la aplicación de origen.

      • Spec.recurrenceRule: Define una fecha de inicio en la hora UTC y un intervalo de recurrencia.

        Ejemplo YAML:

      apiVersion: protect.trident.netapp.io/v1
kind: AppMirrorRelationship
metadata:
  name: amr-16061e80-1b05-4e80-9d26-d326dc1953d8
  namespace: my-app-namespace
spec:
  desiredState: Established
  destinationAppVaultRef: generic-s3-trident-protect-dst-bucket-8fe0b902-f369-4317-93d1-ad7f2edc02b5
  namespaceMapping:
    - destination: my-app-namespace
      source: my-app-namespace
  recurrenceRule: |-
    DTSTART:20220101T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  sourceAppVaultRef: generic-s3-trident-protect-src-bucket-b643cc50-0429-4ad5-971f-ac4a83621922
  sourceApplicationName: maria
  sourceApplicationUID: 7498d32c-328e-4ddd-9029-122540866aeb
  storageClassName: sc-vsim-2

    3. Después de rellenar trident-protect-relationship.yaml el archivo con los valores correctos, aplique el CR:

      kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace
    Cree una AppMirrorRelationship con la CLI

    1. Cree y aplique el objeto AppMirrorRelationship, reemplazando los valores entre paréntesis con información de su entorno. Por ejemplo:

      tridentctl protect create appmirrorrelationship <name_of_appmirorrelationship> --destination-app-vault <my_vault_name> --recurrence-rule <rule> --source-app <my_source_app> --source-app-vault <my_source_app_vault>

  8. (Optional) Compruebe el estado y el estado de la relación de replicación:

    kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq

Conmutación por error al clúster de destino

Con Trident Protect, puede conmutar al respaldo de aplicaciones replicadas a un clúster de destino. Este procedimiento detiene la relación de replicación y conecta la aplicación en el clúster de destino. Trident Protect no detiene la aplicación en el clúster de origen si estaba operativa.

Pasos

  1. Abra el archivo AppMirrorRelationship CR (por ejemplo, trident-protect-relationship.yaml) y cambie el valor de spec.desiredState a Promoted.

  2. Guarde el archivo CR.

  3. Aplicar el CR:

    kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace

  4. (Optional) Cree cualquier programación de protección que necesite en la aplicación con fallos.

  5. (Optional) Compruebe el estado y el estado de la relación de replicación:

    kubectl get amr -n my-app-namespace <relationship name> -o=jsonpath='{.status}' | jq

Resincronizar una relación de replicación con fallo

La operación de resincronización vuelve a establecer la relación de replicación. Después de realizar una operación de resincronización, la aplicación de origen original se convierte en la aplicación en ejecución y se descartan todos los cambios realizados en la aplicación en ejecución en el clúster de destino.

El proceso detiene la aplicación en el clúster de destino antes de restablecer la replicación.

Importante Se perderán todos los datos escritos en la aplicación de destino durante la conmutación al respaldo.
Pasos

  1. Crear una instantánea de la aplicación de origen.

  2. Abra el archivo AppMirrorRelationship CR (por ejemplo, trident-protect-relationship.yaml) y cambie el valor de spec.desiredState a Established.

  3. Guarde el archivo CR.

  4. Aplicar el CR:

    kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace

  5. Si ha creado cualquier programación de protección en el clúster de destino para proteger la aplicación con errores, elimínela. Cualquier programación que permanezca provoca errores de snapshots de volumen.

Resincronización inversa de una relación de replicación fallida

Cuando se realiza una resincronización inversa de una relación de replicación fallida, la aplicación de destino se convierte en la aplicación de origen y el origen se convierte en el destino. Se mantienen los cambios realizados en la aplicación de destino durante la conmutación por error.

Pasos

  1. Elimine el AppMirrorRelationship CR en el clúster de destino original. Esto hace que el destino se convierta en el origen. Si queda alguna programación de protección en el nuevo clúster de destino, elimínela.

  2. Configure una relación de replicación aplicando los archivos CR que utilizó originalmente para configurar la relación con los clusters opuestos.

  3. Asegúrese de que los CRS de AppVault están listos en cada clúster.

  4. Configure una relación de replicación en el cluster opuesto, configurando valores para la dirección inversa.

Invertir dirección de replicación de aplicaciones

Al invertir la dirección de replicación, Trident Protect mueve la aplicación al back-end del almacenamiento de destino, a la vez que continúa replicando al back-end del almacenamiento de origen original. Trident Protect detiene la aplicación de origen y replica los datos en el destino antes de conmutar por error a la aplicación de destino.

En esta situación, está intercambiando el origen y el destino.

Pasos

  1. Crear una instantánea de cierre:

    Cree una instantánea de cierre con un CR

    1. Desactive las programaciones de políticas de protección para la aplicación de origen.

    2. Crear un archivo CR de ShutdownSnapshot:

      1. Cree el archivo de recursos personalizados (CR) y asígnele un nombre (por ejemplo, trident-protect-shutdownsnapshot.yaml).

      2. Configure los siguientes atributos:

        • metadata.name: (required) El nombre del recurso personalizado.

        • Spec.AppVaultRef: (required) Este valor debe coincidir con el campo metadata.name del AppVault para la aplicación de origen.

        • Spec.ApplicationRef: (required) Este valor debe coincidir con el campo metadata.name del archivo CR de la aplicación de origen.

          Ejemplo YAML:

      apiVersion: protect.trident.netapp.io/v1
kind: ShutdownSnapshot
metadata:
  name: replication-shutdown-snapshot-afc4c564-e700-4b72-86c3-c08a5dbe844e
  namespace: my-app-namespace
spec:
  appVaultRef: generic-s3-trident-protect-src-bucket-04b6b4ec-46a3-420a-b351-45795e1b5e34
  applicationRef: maria

    3. Después de rellenar trident-protect-shutdownsnapshot.yaml el archivo con los valores correctos, aplique el CR:

      kubectl apply -f trident-protect-shutdownsnapshot.yaml -n my-app-namespace
    Cree una snapshot apagada con la CLI

    1. Cree la instantánea de cierre, reemplazando valores entre paréntesis con información de su entorno. Por ejemplo:

      tridentctl protect create shutdownsnapshot <my_shutdown_snapshot> --appvault <my_vault> --app <app_to_snapshot>

  2. Cuando se complete la copia de Snapshot, se debe obtener el estado de la copia de Snapshot:

    kubectl get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o yaml

  3. Busque el valor de shutdownsnapshot.status.appArchivePath usando el siguiente comando, y registre la última parte de la ruta del archivo (también llamada nombre base; esto será todo después de la última barra diagonal):

    k get shutdownsnapshot -n my-app-namespace <shutdown_snapshot_name> -o jsonpath='{.status.appArchivePath}'

  4. Realice una conmutación por error del clúster de destino al clúster de origen con el siguiente cambio:

    Nota En el paso 2 del procedimiento de conmutación por error, incluya el spec.promotedSnapshot campo en el archivo AppMirrorRelationship CR y establezca su valor en el nombre base que registró en el paso 3 anterior.

  5. Realice los pasos de resincronización inversa en Resincronización inversa de una relación de replicación fallida.

  6. Habilite las programaciones de protección en el nuevo clúster de origen.

Resultado

Las siguientes acciones se producen debido a la replicación inversa:

  • Se toma una instantánea de los recursos de Kubernetes de la aplicación de origen original.

  • Los pods de la aplicación de origen originales se detienen con dignidad al eliminar los recursos de Kubernetes de la aplicación (dejando las RVP y los VP en funcionamiento).

  • Después de que los pods se cierran, se toman y replican instantáneas de los volúmenes de la aplicación.

  • Las relaciones de SnapMirror se rompen, lo que hace que los volúmenes de destino estén listos para la lectura/escritura.

  • Los recursos de Kubernetes de la aplicación se restauran a partir de la instantánea previa al cierre, utilizando los datos del volumen replicados después de que se cerró la aplicación de origen original.

  • La replicación se restablece en la dirección inversa.

Conmutación tras error de las aplicaciones al clúster de origen original

Con Trident Protect, puede obtener un «fallo» tras una operación de recuperación tras fallos utilizando la siguiente secuencia de operaciones. En este flujo de trabajo para restaurar la dirección de replicación original, Trident protege replica (resincroniza) cualquier cambio de aplicación de nuevo en la aplicación de origen original antes de revertir la dirección de replicación.

Este proceso se inicia desde una relación que ha completado una conmutación al nodo de respaldo a un destino e implica los siguientes pasos:

  • Comience con un estado de conmutación al respaldo.

  • Vuelva a sincronizar la relación de replicación.

    Precaución No realice una operación de resincronización normal, ya que esto descartará los datos escritos en el clúster de destino durante el procedimiento de conmutación por error.

  • Invierta la dirección de replicación.

Pasos

  1. Realice Resincronización inversa de una relación de replicación fallidalos pasos.

  2. Realice Invertir dirección de replicación de aplicacioneslos pasos.

Eliminar una relación de replicación

Puede eliminar una relación de replicación en cualquier momento. Al eliminar la relación de replicación de la aplicación, se crean dos aplicaciones independientes sin relación entre ellas.

Pasos

  1. Elimine el CR de AppMirrorRelationship:

    kubectl delete -f trident-protect-relationship.yaml -n my-app-namespace