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 utilizando NetApp SnapMirror y Trident Protect

Colaboradores netapp-mwallis netapp-shwetav Copilot
PDF

Con Trident Protect, puede utilizar las capacidades de replicación asincrónica de la tecnología SnapMirror de NetApp para replicar cambios de datos y aplicaciones de un backend 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 Red Hat OpenShift, es importante tener en cuenta el papel fundamental que desempeñan las anotaciones de espacios de nombres en los entornos OpenShift. Las anotaciones de espacio de nombres garantizan que los pods restaurados cumplan con los permisos y las configuraciones de seguridad adecuados definidos por las restricciones de contexto de seguridad (SCC) de OpenShift y puedan acceder a los volúmenes sin problemas de permisos. 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:

helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect \
  --set-string restoreSkipNamespaceAnnotations="{<annotation_key_to_skip_1>,<annotation_key_to_skip_2>}" \
  --reuse-values
Nota Al realizar una operación de restauración o conmutación por error, se tendrán en cuenta las anotaciones y etiquetas de espacio de nombres especificadas en restoreSkipNamespaceAnnotations y restoreSkipNamespaceLabels quedan excluidos de la operación de restauración o conmutación por error. Asegúrese de que estos ajustes se configuren durante la instalación inicial de Helm. Para obtener más información, consulte "Configurar ajustes adicionales del gráfico de timón Trident Protect".

Si instalaste la aplicación de origen usando Helm con el --create-namespace bandera, se le da un trato especial a la name Clave de etiqueta. Durante el proceso de restauración o conmutación por error, Trident Protect copia esta etiqueta en el 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 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".

Ganchos de ejecución durante operaciones de conmutación por error e inversas

Al usar la relación AppMirror para proteger su aplicación, hay comportamientos específicos relacionados con los ganchos de ejecución que debe tener en cuenta durante las operaciones de conmutación por error y de reversión.

  • Durante la conmutación por error, los ganchos de ejecución se copian automáticamente del clúster de origen al de destino. No es necesario volver a crearlos manualmente. Tras la conmutación por error, los ganchos de ejecución permanecen en la aplicación y se ejecutarán durante cualquier acción relevante.

  • Durante la resincronización inversa, se eliminan todos los ganchos de ejecución existentes en la aplicación. Cuando la aplicación de origen se convierte en la aplicación de destino, estos ganchos de ejecución dejan de ser válidos y se eliminan para impedir su ejecución.

Para obtener más información sobre los ganchos de ejecución, consulte"Administrar los ganchos de ejecución de Trident Protect" .

Configurar una relación de replicación

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

  • Elegir la frecuencia con la que desea 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 para 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. En el clúster de origen, cree un AppVault para la aplicación 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> -n trident-protect

  2. En el clúster de origen, 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: my-app-name
  namespace: my-app-namespace
spec:
  includedNamespaces:
    - namespace: my-app-namespace
      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 <my-app-name> --namespaces <namespaces-to-be-included> -n <my-app-namespace>

  3. Opcionalmente, en el clúster de origen, tome una instantánea de la aplicación de origen. Esta instantánea se utiliza como base para 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 tener una instantánea reciente. Para crear una instantánea bajo demanda, consulte "Crear una snapshot bajo demanda".

  4. En el clúster de origen, cree la programación de replicación CR:

    Nota

    Además del programa que se proporciona a continuación, se recomienda crear un programa de instantáneas diarias independiente con un período de retención de 7 días para mantener una instantánea común entre los clústeres de ONTAP emparejados. Esto garantiza que las instantáneas estén disponibles hasta por 7 días, pero el período de retención se puede personalizar según las necesidades del usuario.

    Si se produce una conmutación por error, el sistema puede usar estas instantáneas hasta por 7 días para operaciones inversas. Este enfoque agiliza y optimiza el proceso, ya que solo se transfieren los cambios realizados desde la última instantánea, no todos los datos.

    Si un programa existente para la aplicación ya cumple con los requisitos de retención deseados, no se requieren programas adicionales.
    Cree la programación de replicación utilizando 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: (Obligatorio) Este valor debe coincidir con el campo metadata.name del AppVault para la aplicación de origen.

        • spec.applicationRef: (Obligatorio) Este valor debe coincidir con el campo metadata.name del CR de la aplicación de origen.

        • 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
  namespace: my-app-namespace
spec:
  appVaultRef: my-appvault-name
  applicationRef: my-app-name
  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
    Cree la programación de replicación mediante la CLI.

    1. Cree la planificación de replicación, reemplazando los valores entre corchetes con información de su entorno:

      tridentctl-protect create schedule --name appmirror-schedule --app <my_app_name> --appvault <my_app_vault> --granularity Custom --recurrence-rule <rule> --snapshot-retention <snapshot_retention_count> -n <my_app_namespace>

      Ejemplo:

      tridentctl-protect create schedule --name appmirror-schedule --app <my_app_name> --appvault <my_app_vault> --granularity Custom --recurrence-rule  "DTSTART:20220101T000200Z\nRRULE:FREQ=MINUTELY;INTERVAL=5" --snapshot-retention 2 -n <my_app_namespace>

  5. En el clúster de destino, cree una aplicación de origen AppVault CR 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).

  6. Aplicar el CR:

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

  7. Cree un AppVault CR de destino 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 trident-protect

  8. En el clúster de destino, 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.sourceApplicationUID: (Obligatorio) Este valor debe coincidir con el UID de la aplicación de origen que definió en el CR de la aplicación de origen.

      • spec.storageClassName: (Opcional) Elija el nombre de una clase de almacenamiento válida en el clúster. La clase de almacenamiento debe estar vinculada a una máquina virtual de almacenamiento ONTAP que esté emparejada con el entorno de origen. Si no se proporciona la clase de almacenamiento, se utilizará por defecto la clase de almacenamiento predeterminada del clúster.

      • 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: my-app-name
  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. Crea y aplica el objeto AppMirrorRelationship, reemplazando los valores entre corchetes con información de tu entorno:

      tridentctl-protect create appmirrorrelationship <name_of_appmirorrelationship> --destination-app-vault <my_vault_name> --source-app-vault <my_vault_name> --recurrence-rule <rule> --namespace-mapping <ns_mapping> --source-app-id <source_app_UID> --source-app <my_source_app_name> --storage-class <storage_class_name> -n <application_namespace>

      Ejemplo:

      tridentctl-protect create appmirrorrelationship my-amr --destination-app-vault appvault2 --source-app-vault appvault1 --recurrence-rule "DTSTART:20220101T000200Z\nRRULE:FREQ=MINUTELY;INTERVAL=5" --source-app my-app --namespace-mapping "my-source-ns1:my-dest-ns1,my-source-ns2:my-dest-ns2" --source-app-id 373f24c1-5769-404c-93c3-5538af6ccc36 --storage-class my-storage-class -n my-dest-ns1

  9. (Optional) En el clúster de destino, 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 por error las aplicaciones replicadas a un clúster de destino. Este procedimiento detiene la relación de replicación y pone la aplicación en línea en el clúster de destino. Trident Protect no detiene la aplicación en el clúster de origen si estaba operativa.

Pasos

  1. En el clúster de destino, edite el archivo CR de AppMirrorRelationship (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. Opcional: En el clúster de origen, cree una copia Snapshot de la aplicación de origen. De esta forma se garantiza que se capturen los cambios más recientes del clúster de origen.

  2. En el clúster de destino, edite el archivo CR de AppMirrorRelationship (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. En el clúster de destino original, elimine el CR de AppMirrorRelationship. 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 el nuevo destino (cluster de origen original) está configurado con los CRS de AppVault.

  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

Cuando invierte la dirección de replicación, Trident Protect mueve la aplicación al backend de almacenamiento de destino mientras continúa replicando al backend de 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. En el clúster de origen, cree una snapshot de apagado:

    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: my-app-name

    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> -n <application_namespace>

  2. En el clúster de origen, cuando se complete la snapshot de apagado, obtenga el estado de la snapshot de apagado:

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

  3. En el clúster de origen, 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 nuevo clúster de destino al nuevo 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

Al utilizar Trident Protect, puede lograr una "conmutación por error" después de una operación de conmutación por error mediante la siguiente secuencia de operaciones. En este flujo de trabajo para restaurar la dirección de replicación original, Trident Protect replica (resincroniza) cualquier cambio de aplicación a 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. En el clúster de eliminación actual, elimine el CR de AppMirrorRelationship:

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