Skip to main content
Hay disponible una nueva versión de este producto.
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.

Replica aplicaciones usando NetApp SnapMirror y Trident Protect

PDF

Con Trident Protect, puedes usar las capacidades de replicación asíncrona de NetApp SnapMirror para replicar datos y cambios de aplicaciones de un backend de almacenamiento a otro, en el mismo clúster o entre diferentes clústeres.

Anotaciones y etiquetas de namespace durante las operaciones de restauración y conmutación por error

Durante las operaciones de restauración y conmutación por error, las etiquetas y anotaciones en el espacio de nombres de destino se hacen coincidir con las etiquetas y anotaciones en el espacio de nombres de origen. Las etiquetas o anotaciones del espacio de nombres de origen que no existen en el espacio de nombres de destino se añaden, y cualquier etiqueta o anotación que ya exista se sobrescribe para que coincida con el valor del espacio de nombres de origen. Las etiquetas o anotaciones que existen solo en el espacio de nombres de destino permanecen sin cambios.

Nota Si usas Red Hat OpenShift, es importante que notes el papel fundamental de las anotaciones de espacios de nombres en entornos OpenShift. Las anotaciones de espacios de nombres aseguran que los pods restaurados sigan los permisos y configuraciones de seguridad apropiados definidos por las restricciones de contexto de seguridad (SCC) de OpenShift y puedan acceder a los volúmenes sin problemas de permisos. Para más información, consulta el "OpenShift documentación de restricciones de contexto de seguridad".

Puedes evitar que se sobrescriban anotaciones específicas en el espacio de nombres de destino configurando la variable de entorno de Kubernetes RESTORE_SKIP_NAMESPACE_ANNOTATIONS antes de realizar la restauración o la 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, las anotaciones y etiquetas de espacios de nombres especificadas en restoreSkipNamespaceAnnotations y restoreSkipNamespaceLabels se excluyen de la operación de restauración o conmutación por error. Asegúrate de que estos ajustes estén configurados durante la instalación inicial de Helm. Para saber más, consulta "Configura los ajustes adicionales del helm chart de Trident Protect".

Si instalaste la aplicación de origen usando Helm con la --create-namespace flag, se da un tratamiento especial a la clave de etiqueta name. Durante el proceso de restauración o conmutación por error, Trident Protect copia 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 uno de destino, cada uno con anotaciones y etiquetas diferentes. Puedes ver el estado del espacio de nombres de destino antes y después de la operación, y cómo se combinan o sobrescriben las anotaciones y etiquetas en el espacio de nombres de destino.

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

La siguiente tabla ilustra el estado de los espacios de nombres de origen y destino de ejemplo antes de la operación de restauración o conmutación por error:

Espacio de nombres Anotaciones Etiquetas

Namespace ns-1 (fuente)

  • annotation.one/key: "valoractualizado"

  • annotation.two/key: "true"

  • entorno=producción

  • compliance=hipaa

  • name=ns-1

Namespace ns-2 (destino)

  • annotation.one/key: "true"

  • annotation.three/key: "false"

  • role=database

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

La siguiente tabla ilustra 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 añadido algunas claves, se han sobrescrito otras y la etiqueta name se ha actualizado para que coincida con el espacio de nombres de destino:

Espacio de nombres Anotaciones Etiquetas

Namespace ns-2 (destino)

  • annotation.one/key: "valoractualizado"

  • annotation.two/key: "true"

  • annotation.three/key: "false"

  • name=ns-2

  • compliance=hipaa

  • entorno=producción

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

Ganchos de ejecución durante la conmutación por error y las operaciones inversas

Cuando uses la relación AppMirror para proteger tu aplicación, hay comportamientos específicos relacionados con los hooks de ejecución que deberías conocer durante las operaciones de conmutación por error y reversa.

  • Durante la conmutación por error, los ganchos de ejecución se copian automáticamente del clúster de origen al clúster de destino. No necesitas volver a crearlos manualmente. Después de la conmutación por error, los ganchos de ejecución están presentes en la aplicación y se ejecutarán durante cualquier acción relevante.

  • Durante la resincronización inversa o inversa, se eliminan todos los execution hooks existentes en la aplicación. Cuando la source application se convierte en la destination application, estos execution hooks no son válidos y se eliminan para evitar su ejecución.

Para obtener más información sobre los ganchos de ejecución, consulta "Administra los hooks de ejecución de Trident Protect".

Configura una relación de replicación

Configurar una relación de replicación implica lo siguiente:

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

  • Elegir el calendario de replicación (incluye los recursos de Kubernetes y también los datos de volumen persistente)

  • Configurar la hora para que se tome la instantánea

Pasos

  1. En el clúster de origen, crea un AppVault para la aplicación de origen. Dependiendo de tu proveedor de almacenamiento, modifica un ejemplo en "AppVault recursos personalizados" para adaptarlo a tu entorno:

    Crea un AppVault usando un CR

    1. Crea el archivo de recurso personalizado (CR) y ponle un nombre (por ejemplo, trident-protect-appvault-primary-source.yaml).

    2. Configura los siguientes atributos:

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

      • spec.providerConfig: (Requerido) Almacena la configuración necesaria para acceder a AppVault usando el proveedor especificado. Elige un bucketName y cualquier otro detalle necesario para tu proveedor. Toma nota de los valores que elijas, porque otros archivos CR necesarios para una relación de replicación hacen referencia a estos valores. Consulta "AppVault recursos personalizados" para ver ejemplos de CR de AppVault con otros proveedores.

      • spec.providerCredentials: (Obligatorio) 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 venir de un secreto.

          • key: (Obligatorio) La clave válida del secreto a seleccionar.

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

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

      • spec.providerType: (Obligatorio) determina qué proporciona la copia de seguridad; por ejemplo, NetApp ONTAP S3, S3 genérico, Google Cloud o Microsoft Azure. Valores posibles:

        • aws

        • azure

        • gcp

        • generic-s3

        • ontap-s3

        • storagegrid-s3

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

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

    1. Crea el AppVault, reemplazando los valores entre corchetes con información de tu 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, crea la CR de la aplicación de origen:

    Crea la aplicación fuente usando una CR

    1. Crea el archivo de recurso personalizado (CR) y ponle un nombre (por ejemplo, trident-protect-app-source.yaml).

    2. Configura los siguientes atributos:

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

      • spec.includedNamespaces: (Obligatorio) Una matriz de espacios de nombres y etiquetas asociadas. Usa los nombres de los espacios de nombres y, si quieres, limita el alcance de los espacios de nombres con etiquetas para especificar los recursos que existen en los espacios de nombres que aparecen aquí. El espacio de nombres de la aplicación debe formar parte de esta matriz.

        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 el archivo trident-protect-app-source.yaml con los valores correctos, aplica la CR:

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

    1. Crea la aplicación fuente. 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, toma una instantánea de la aplicación de origen. Esta instantánea se usa como base para la aplicación en el clúster de destino. Si te saltas este paso, tendrás que esperar a que se ejecute la siguiente instantánea programada para tener una instantánea reciente. Para crear una instantánea bajo demanda, consulta "Crea una instantánea a pedido".

  4. En el clúster de origen, crea 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 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 hace que el proceso inverso sea más rápido y eficiente porque solo se transferirán los cambios hechos 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 programaciones adicionales.
    Crea el programa de replicación usando una CR

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

      1. Crea el archivo de recurso personalizado (CR) y ponle un nombre (por ejemplo, trident-protect-schedule.yaml).

      2. Configura los siguientes atributos:

        • metadata.name: (Obligatorio) El nombre del recurso personalizado de schedule.

        • spec.appVaultRef: (Obligatorio) Este valor debe coincidir con el campo metadata.name de la 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: (Obligatorio) Este campo es obligatorio y el valor debe establecerse en 0.

        • spec.enabled: debe establecerse en true.

        • spec.granularity: debe establecerse en Custom.

        • spec.recurrenceRule: define una fecha de inicio en tiempo UTC y un intervalo de recurrencia.

        • spec.snapshotRetention: debe establecerse en 2.

          Ejemplo de 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 el archivo trident-protect-schedule.yaml con los valores correctos, aplica la CR:

        kubectl apply -f trident-protect-schedule.yaml -n my-app-namespace
    Crea la programación de replicación usando la CLI

    1. Crea el programa de replicación, reemplazando los valores entre corchetes con información de tu 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, crea una CR de aplicación de origen AppVault que sea idéntica a la CR AppVault que aplicaste en el clúster de origen y asígnale un nombre (por ejemplo, trident-protect-appvault-primary-destination.yaml).

  6. Aplica la CR:

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

  7. Crea un CR de AppVault de destino para la aplicación de destino en el clúster de destino. Dependiendo de tu proveedor de almacenamiento, modifica un ejemplo en "AppVault recursos personalizados" para adaptarlo a tu entorno:

    1. Crea el archivo de recurso personalizado (CR) y ponle un nombre (por ejemplo, trident-protect-appvault-secondary-destination.yaml).

    2. Configura los siguientes atributos:

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

      • spec.providerConfig: (Obligatorio) Almacena la configuración necesaria para acceder a AppVault usando el proveedor especificado. Elige un bucketName y cualquier otro detalle necesario para tu proveedor. Toma nota de los valores que elijas, porque otros archivos CR necesarios para una relación de replicación hacen referencia a estos valores. Consulta "AppVault recursos personalizados" para ver ejemplos de CR de AppVault con otros proveedores.

      • spec.providerCredentials: (Obligatorio) 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 venir de un secreto.

          • key: (Obligatorio) La clave válida del secreto a seleccionar.

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

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

      • spec.providerType: (Obligatorio) determina qué proporciona la copia de seguridad; por ejemplo, NetApp ONTAP S3, S3 genérico, Google Cloud o Microsoft Azure. Valores posibles:

        • aws

        • azure

        • gcp

        • generic-s3

        • ontap-s3

        • storagegrid-s3

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

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

  8. En el clúster de destino, crea un archivo CR de AppMirrorRelationship.

    Nota Al usar una CR, crea manualmente el espacio de nombres de destino antes de aplicarla. Trident Protect crea espacios de nombres automáticamente solo cuando usas la CLI.
    Crea un AppMirrorRelationship usando un CR

    1. Crea el archivo de recurso personalizado (CR) y ponle un nombre (por ejemplo, trident-protect-relationship.yaml).

    2. Configura los siguientes atributos:

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

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

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

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

      • spec.sourceApplicationName: (Obligatorio) Este valor debe coincidir con el nombre de la aplicación de origen que definiste en el CR de la aplicación de origen.

      • spec.sourceApplicationUID: (Obligatorio) Este valor debe coincidir con el UID de la aplicación de origen que definiste en el CR de la aplicación de origen.

      • spec.storageClassName: (opcional) elige 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 usará la clase de almacenamiento predeterminada del clúster.

      • spec.recurrenceRule: define una fecha de inicio en tiempo UTC y un intervalo de recurrencia.

        Ejemplo de 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 el archivo trident-protect-relationship.yaml con los valores correctos, aplica la CR:

      kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace
    Crea un AppMirrorRelationship usando 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. (Opcional) En el clúster de destino, revisa el estado y el estatus de la relación de replicación:

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

Conmutar al clúster de destino

Con Trident Protect, puedes conmutar por error las aplicaciones replicadas a un clúster de destino. Este procedimiento detiene la relación de replicación y pone la app en línea en el clúster de destino. Trident Protect no detiene la app en el clúster de origen si estaba operativa.

Pasos

  1. En el clúster de destino, edita el archivo CR AppMirrorRelationship (por ejemplo, trident-protect-relationship.yaml) y cambia el valor de spec.desiredState a Promoted.

  2. Guarda el archivo CR.

  3. Aplica la CR:

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

  4. (Opcional) Crea cualquier programación de protección que necesites en la aplicación conmutada por error.

  5. (Opcional) Verifica el estado y el estatus 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 conmutada por error

La operación de resincronización restablece 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 cualquier cambio hecho en la aplicación en ejecución en el clúster de destino se descarta.

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

Importante Cualquier dato escrito en la aplicación de destino durante la conmutación por error se perderá.
Pasos

  1. Opcional: en el clúster de origen, crea una instantánea de la aplicación de origen. Esto asegura que se capturen los últimos cambios del clúster de origen.

  2. En el clúster de destino, edita el archivo CR de AppMirrorRelationship (por ejemplo, trident-protect-relationship.yaml) y cambia el valor de spec.desiredState a Established.

  3. Guarda el archivo CR.

  4. Aplica la CR:

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

  5. Si creaste alguna programación de protección en el clúster de destino para proteger la aplicación que se transfirió tras el fallo, elimínala. Cualquier programación que quede provoca fallos en las instantáneas del volumen.

Resincroniza de forma inversa una relación de replicación que ha fallado

Cuando haces 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 la de origen en la de destino. Los cambios hechos en la aplicación de destino durante el failover se mantienen.

Pasos

  1. En el clúster de destino original, elimina el CR AppMirrorRelationship. Esto hace que el destino se convierta en el origen. Si quedan programas de protección en el nuevo clúster de destino, elimínalos.

  2. Configura una relación de replicación aplicando los archivos CR que usaste originalmente para configurar la relación en los clústeres opuestos.

  3. Asegúrate de que el nuevo destino (clúster de origen original) esté configurado con ambos CR de AppVault.

  4. Configura una relación de replicación en el clúster opuesto, configurando los valores para la dirección inversa.

Invertir la dirección de replicación de la aplicación

Cuando inviertes la dirección de replicación, Trident Protect mueve la aplicación al backend de almacenamiento de destino mientras sigue replicando de vuelta al backend de almacenamiento de origen original. Trident Protect detiene la aplicación de origen y replica los datos al destino antes de hacer el failover a la app de destino.

En esta situación, estás intercambiando el clúster de origen y el clúster de destino.

Pasos

  1. En el clúster de origen, crea una instantánea de apagado:

    Crea una instantánea de apagado usando un CR

    1. Desactiva las programaciones de la política de protección para la aplicación de origen.

    2. Crea un archivo ShutdownSnapshot CR:

      1. Crea el archivo de recurso personalizado (CR) y ponle un nombre (por ejemplo, trident-protect-shutdownsnapshot.yaml).

      2. Configura los siguientes atributos:

        • metadata.name: (Requerido) 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 de 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 el archivo trident-protect-shutdownsnapshot.yaml con los valores correctos, aplica la CR:

      kubectl apply -f trident-protect-shutdownsnapshot.yaml -n my-app-namespace
    Crea una instantánea de apagado usando la CLI

    1. Crea la instantánea de apagado, reemplazando los valores entre corchetes por información de tu 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, después de que se complete la instantánea de apagado, obtén el estado de la instantánea de apagado:

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

  3. En el clúster de origen, encuentra el valor de shutdownsnapshot.status.appArchivePath usando el siguiente comando y apunta la última parte de la ruta del archivo (también llamada basename; esto será todo lo que esté después de la última barra):

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

  4. Realiza 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, incluye el campo spec.promotedSnapshot en el archivo AppMirrorRelationship CR y pon su valor en el nombre base que anotaste en el paso 3 de arriba.

  5. Realiza los pasos de resincronización inversa en Resincroniza de forma inversa una relación de replicación que ha fallado.

  6. Habilita los calendarios de protección en el nuevo clúster de origen.

Resultado

Las siguientes acciones ocurren debido a la replicación inversa:

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

  • Los pods de la app fuente original se detienen de forma gradual eliminando los recursos de Kubernetes de la app (dejando los PVCs y PVs en su lugar).

  • Después de que los pods se apagan, se toman instantáneas de los volúmenes de la app y se replican.

  • Las relaciones de SnapMirror se rompen, lo que deja los volúmenes de destino listos para lectura/escritura.

  • Los recursos de Kubernetes de la app se restauran desde la instantánea previa al apagado, usando los datos de volumen replicados después de que la app de origen original se apagara.

  • La replicación se restablece en sentido inverso.

Devuelve las aplicaciones al clúster de origen

Con Trident Protect, puedes lograr la "recuperación" después de una operación de conmutación por error usando 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 la aplicación de vuelta a la aplicación de origen original antes de invertir la dirección de replicación.

Este proceso parte de una relación que ha completado una conmutación por error a un destino e implica los siguientes pasos:

  • Empieza con un estado conmutado por error.

  • Resincroniza de forma inversa la relación de replicación.

    Precaución No realices 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.

  • Invierte la dirección de replicación.

Pasos

  1. Realiza los pasos de Resincroniza de forma inversa una relación de replicación que ha fallado.

  2. Realiza los pasos de Invertir la dirección de replicación de la aplicación.

Eliminar una relación de replicación

Puedes eliminar una relación de replicación en cualquier momento. Cuando eliminas la relación de replicación de aplicaciones, el resultado son dos aplicaciones separadas sin relación entre ellas.

Pasos

  1. En el clúster de destino actual, elimina el CR AppMirrorRelationship:

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