Skip to main content
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Replicare le applicazioni utilizzando NetApp SnapMirror e Trident Protect

Collaboratori netapp-mwallis netapp-shwetav Copilot
PDF

Utilizzando Trident Protect, è possibile sfruttare le funzionalità di replica asincrona della tecnologia NetApp SnapMirror per replicare le modifiche dei dati e delle applicazioni da un backend di storage all'altro, sullo stesso cluster o tra cluster diversi.

Annotazioni ed etichette del namespace durante le operazioni di ripristino e failover

Durante le operazioni di ripristino e failover, vengono applicate etichette e annotazioni nel namespace di destinazione in modo che corrispondano alle etichette e alle annotazioni nel namespace di origine. Vengono aggiunte etichette o annotazioni dallo spazio dei nomi di origine che non esistono nello spazio dei nomi di destinazione e le etichette o annotazioni già esistenti vengono sovrascritte per corrispondere al valore dello spazio dei nomi di origine. Le etichette o le annotazioni presenti solo nello spazio dei nomi di destinazione rimangono invariate.

Nota Se si utilizza Red Hat OpenShift, è importante tenere presente il ruolo fondamentale delle annotazioni dello spazio dei nomi negli ambienti OpenShift. Le annotazioni dello spazio dei nomi garantiscono che i pod ripristinati aderiscano alle autorizzazioni appropriate e alle configurazioni di sicurezza definite dai vincoli del contesto di sicurezza (SCC) di OpenShift e possano accedere ai volumi senza problemi di autorizzazione. Per maggiori informazioni, fare riferimento al"Documentazione dei vincoli del contesto di protezione OpenShift" .

Puoi impedire la sovrascrittura delle annotazioni specifiche nel namespace di destinazione impostando la variabile dell'ambiente Kubernetes RESTORE_SKIP_NAMESPACE_ANNOTATIONS prima di eseguire l'operazione di ripristino o failover. Ad esempio:

helm upgrade trident-protect --set restoreSkipNamespaceAnnotations=<annotation_key_to_skip_1>,<annotation_key_to_skip_2> --reuse-values
Nota Quando si esegue un'operazione di ripristino o failover, tutte le annotazioni e le etichette dello spazio dei nomi specificate in restoreSkipNamespaceAnnotations E restoreSkipNamespaceLabels sono esclusi dall'operazione di ripristino o failover. Assicurarsi che queste impostazioni siano configurate durante l'installazione iniziale di Helm. Per saperne di più, fare riferimento a "Configurare le impostazioni aggiuntive del grafico del timone Trident Protect".

Se hai installato l'applicazione sorgente utilizzando Helm con --create-namespace bandiera, un trattamento speciale è riservato al name etichetta chiave. Durante il processo di ripristino o failover, Trident Protect copia questa etichetta nello spazio dei nomi di destinazione, ma aggiorna il valore al valore dello spazio dei nomi di destinazione se il valore dell'origine corrisponde allo spazio dei nomi di origine. Se questo valore non corrisponde allo spazio dei nomi di origine, viene copiato nello spazio dei nomi di destinazione senza modifiche.

Esempio

Nell'esempio seguente viene presentato uno spazio dei nomi di origine e destinazione, ciascuno con annotazioni ed etichette diverse. È possibile visualizzare lo stato dello spazio dei nomi di destinazione prima e dopo l'operazione e il modo in cui le annotazioni e le etichette vengono combinate o sovrascritte nello spazio dei nomi di destinazione.

Prima dell'operazione di ripristino o failover

La tabella seguente illustra lo stato degli spazi dei nomi di origine e di destinazione di esempio prima dell'operazione di ripristino o failover:

Namespace Annotazioni Etichette

Namespace ns-1 (origine)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • ambiente=produzione

  • conformità=hipaa

  • name=ns-1

Namespace ns-2 (destinazione)

  • annotation.one/key: "true"

  • annotation.three/key: "false"

  • ruolo=database

Dopo l'operazione di ripristino

La tabella seguente illustra lo stato dello spazio dei nomi di destinazione di esempio dopo l'operazione di ripristino o failover. Alcune chiavi sono state aggiunte, altre sono state sovrascritte e l' `name`etichetta è stata aggiornata per corrispondere allo spazio dei nomi di destinazione:

Namespace Annotazioni Etichette

Namespace ns-2 (destinazione)

  • annotation.one/key: "updatedvalue"

  • annotation.two/key: "true"

  • annotation.three/key: "false"

  • name=ns-2

  • conformità=hipaa

  • ambiente=produzione

  • ruolo=database
Nota È possibile configurare Trident Protect in modo che blocchi e sblocchi i file system durante le operazioni di protezione dei dati. "Scopri di più sulla configurazione del congelamento del file system con Trident Protect".

Hook di esecuzione durante le operazioni di failover e reverse

Quando si utilizza la relazione AppMirror per proteggere l'applicazione, ci sono comportamenti specifici relativi agli hook di esecuzione di cui è necessario essere a conoscenza durante le operazioni di failover e reverse.

  • Durante il failover, gli hook di esecuzione vengono copiati automaticamente dal cluster di origine a quello di destinazione. Non è necessario ricrearli manualmente. Dopo il failover, gli hook di esecuzione sono presenti nell'applicazione e verranno eseguiti durante qualsiasi azione rilevante.

  • Durante l'inversione o la risincronizzazione inversa, tutti gli hook di esecuzione esistenti sull'applicazione vengono rimossi. Quando l'applicazione di origine diventa l'applicazione di destinazione, questi hook di esecuzione non sono più validi e vengono eliminati per impedirne l'esecuzione.

Per saperne di più sugli hook di esecuzione, fare riferimento a"Gestire gli hook di esecuzione Trident Protect" .

Impostare una relazione di replica

L'impostazione di una relazione di replica comporta quanto segue:

  • Scegliere la frequenza con cui si desidera che Trident Protect esegua uno snapshot dell'app (che include le risorse Kubernetes dell'app e gli snapshot del volume per ciascuno dei volumi dell'app)

  • Scelta del programma di replica (include risorse Kubernetes nonché dati dei volumi persistenti)

  • Impostazione dell'ora in cui eseguire l'istantanea

Fasi

  1. Nel cluster di origine, creare un AppVault per l'applicazione di origine. A seconda del provider di storage, modificare un esempio in "Risorse personalizzate AppVault" per adattare il proprio ambiente:

    Creare un AppVault utilizzando una CR

    1. Creare il file di risorsa personalizzata (CR) e assegnargli un nome (ad esempio, trident-protect-appvault-primary-source.yaml).

    2. Configurare i seguenti attributi:

      • metadata.name: (required) il nome della risorsa personalizzata AppVault. Prendere nota del nome scelto, poiché altri file CR necessari per una relazione di replica fanno riferimento a questo valore.

      • spec.providerConfig: (required) Memorizza la configurazione necessaria per accedere ad AppVault utilizzando il provider specificato. Scegli un bucketName e tutti gli altri dettagli necessari per il tuo provider. Prendere nota dei valori scelti, poiché altri file CR necessari per una relazione di replica fanno riferimento a questi valori. Fare riferimento a "Risorse personalizzate AppVault" per esempi di CRS AppVault con altri provider.

      • spec.providerCredentials: (required) archivia i riferimenti a qualsiasi credenziale richiesta per accedere ad AppVault utilizzando il provider specificato.

        • spec.providerCredentials.valueFromSecret: (required) indica che il valore della credenziale deve provenire da un segreto.

          • Key: (required) la chiave valida del segreto da selezionare.

          • Nome: (obbligatorio) Nome del segreto che contiene il valore per questo campo. Deve trovarsi nello stesso spazio dei nomi.

        • spec.providerCredentials.secretAccessKey: (required) la chiave di accesso utilizzata per accedere al provider. Il nome deve corrispondere a spec.providerCredentials.valueFromSecret.name.

      • spec.providerType: (required) determina cosa fornisce il backup; ad esempio, NetApp ONTAP S3, S3 generico, Google Cloud o Microsoft Azure. Valori possibili:

        • aws

        • azure

        • gcp

        • generico-s3

        • ONTAP-s3

        • StorageGRID-s3

    3. Dopo aver popolato il trident-protect-appvault-primary-source.yaml file con i valori corretti, applicare la CR:

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

    1. Creare AppVault, sostituendo i valori tra parentesi con le informazioni dell'ambiente:

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

  2. Nel cluster di origine, creare l'applicazione di origine CR:

    Creare l'applicazione di origine utilizzando una CR

    1. Creare il file di risorsa personalizzata (CR) e assegnargli un nome (ad esempio, trident-protect-app-source.yaml).

    2. Configurare i seguenti attributi:

      • metadata.name: (required) il nome della risorsa personalizzata dell'applicazione. Prendere nota del nome scelto, poiché altri file CR necessari per una relazione di replica fanno riferimento a questo valore.

      • spec.includedNamespaces: (required) un array di spazi dei nomi e di etichette associate. Utilizzare i nomi degli spazi dei nomi e, facoltativamente, restringere l'ambito degli spazi dei nomi con le etichette per specificare le risorse esistenti negli spazi dei nomi elencati di seguito. Lo spazio dei nomi dell'applicazione deve far parte di questo array.

        Esempio 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. Dopo aver popolato il trident-protect-app-source.yaml file con i valori corretti, applicare la CR:

      kubectl apply -f trident-protect-app-source.yaml -n my-app-namespace
    Creare l'applicazione di origine utilizzando l'interfaccia CLI

    1. Creare l'applicazione di origine. Ad esempio:

      tridentctl-protect create app <my-app-name> --namespaces <namespaces-to-be-included> -n <my-app-namespace>

  3. Facoltativamente, sul cluster di origine, eseguire uno snapshot dell'applicazione di origine. Questo snapshot viene utilizzato come base per l'applicazione sul cluster di destinazione. Se si salta questo passaggio, sarà necessario attendere l'esecuzione del prossimo snapshot pianificato per avere uno snapshot recente. Per creare uno snapshot on-demand, fare riferimento a "Crea un'istantanea on-demand".

  4. Nel cluster di origine, creare la pianificazione della replica CR:

    Nota

    Oltre alla pianificazione fornita di seguito, si consiglia di creare una pianificazione separata per gli snapshot giornalieri con un periodo di conservazione di 7 giorni per mantenere uno snapshot comune tra i cluster ONTAP peer. Ciò garantisce che gli snapshot siano disponibili fino a 7 giorni, ma il periodo di conservazione può essere personalizzato in base alle esigenze dell'utente.

    In caso di failover, il sistema può utilizzare questi snapshot per un massimo di 7 giorni per le operazioni di reverse. Questo approccio rende il processo di reverse più rapido ed efficiente, poiché verranno trasferite solo le modifiche apportate dall'ultimo snapshot, non tutti i dati.

    Se una pianificazione esistente per l'applicazione soddisfa già i requisiti di conservazione desiderati, non sono necessarie pianificazioni aggiuntive.
    Creare la pianificazione della replica utilizzando un CR

    1. Creare una pianificazione di replica per l'applicazione di origine:

      1. Creare il file di risorsa personalizzata (CR) e assegnargli un nome (ad esempio, trident-protect-schedule.yaml).

      2. Configurare i seguenti attributi:

        • metadata.name: (required) il nome della risorsa personalizzata di pianificazione.

        • spec.appVaultRef: (Obbligatorio) Questo valore deve corrispondere al campo metadata.name dell'AppVault per l'applicazione di origine.

        • spec.applicationRef: (Obbligatorio) Questo valore deve corrispondere al campo metadata.name del CR dell'applicazione di origine.

        • Spec.backupRetention: (required) questo campo è obbligatorio e il valore deve essere impostato su 0.

        • Spec.Enabled: Deve essere impostato su true.

        • spec.granularity: deve essere impostato su Custom.

        • Spec.recurrenceRule: Consente di definire una data di inizio nell'ora UTC e un intervallo di ricorrenza.

        • Spec.snapshotRetention: Deve essere impostato su 2.

          Esempio 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. Dopo aver popolato il trident-protect-schedule.yaml file con i valori corretti, applicare la CR:

        kubectl apply -f trident-protect-schedule.yaml -n my-app-namespace
    Creare la pianificazione della replica utilizzando la CLI

    1. Crea la pianificazione della replica, sostituendo i valori tra parentesi con le informazioni provenienti dal tuo ambiente:

      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>

      Esempio:

      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. Nel cluster di destinazione, creare un'applicazione di origine AppVault CR identica a quella AppVault CR applicata al cluster di origine e assegnargli un nome (ad esempio, trident-protect-appvault-primary-destination.yaml).

  6. Applicare la CR:

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

  7. Creare una destinazione AppVault CR per l'applicazione di destinazione sul cluster di destinazione. A seconda del provider di storage, modificare un esempio in "Risorse personalizzate AppVault" per adattare il proprio ambiente:

    1. Creare il file di risorsa personalizzata (CR) e assegnargli un nome (ad esempio, trident-protect-appvault-secondary-destination.yaml).

    2. Configurare i seguenti attributi:

      • metadata.name: (required) il nome della risorsa personalizzata AppVault. Prendere nota del nome scelto, poiché altri file CR necessari per una relazione di replica fanno riferimento a questo valore.

      • spec.providerConfig: (required) Memorizza la configurazione necessaria per accedere ad AppVault utilizzando il provider specificato. Scegliere una bucketName e tutte le altre informazioni necessarie per il provider. Prendere nota dei valori scelti, poiché altri file CR necessari per una relazione di replica fanno riferimento a questi valori. Fare riferimento a "Risorse personalizzate AppVault" per esempi di CRS AppVault con altri provider.

      • spec.providerCredentials: (required) archivia i riferimenti a qualsiasi credenziale richiesta per accedere ad AppVault utilizzando il provider specificato.

        • spec.providerCredentials.valueFromSecret: (required) indica che il valore della credenziale deve provenire da un segreto.

          • Key: (required) la chiave valida del segreto da selezionare.

          • Nome: (obbligatorio) Nome del segreto che contiene il valore per questo campo. Deve trovarsi nello stesso spazio dei nomi.

        • spec.providerCredentials.secretAccessKey: (required) la chiave di accesso utilizzata per accedere al provider. Il nome deve corrispondere a spec.providerCredentials.valueFromSecret.name.

      • spec.providerType: (required) determina cosa fornisce il backup; ad esempio, NetApp ONTAP S3, S3 generico, Google Cloud o Microsoft Azure. Valori possibili:

        • aws

        • azure

        • gcp

        • generico-s3

        • ONTAP-s3

        • StorageGRID-s3

    3. Dopo aver popolato il trident-protect-appvault-secondary-destination.yaml file con i valori corretti, applicare la CR:

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

  8. Nel cluster di destinazione, creare un file CR AppMirrorRelationship:

    Creare una relazione AppMirrorRelationship utilizzando una CR

    1. Creare il file di risorsa personalizzata (CR) e assegnargli un nome (ad esempio, trident-protect-relationship.yaml).

    2. Configurare i seguenti attributi:

      • metadata.name: (obbligatorio) il nome della risorsa personalizzata AppMirrorRelationship.

      • spec.destinationAppVaultRef: (required) questo valore deve corrispondere al nome dell'AppVault per l'applicazione di destinazione sul cluster di destinazione.

      • spec.namespaceMapping: (required) gli spazi dei nomi di destinazione e di origine devono corrispondere allo spazio dei nomi dell'applicazione definito nella rispettiva CR dell'applicazione.

      • Spec.sourceAppVaultRef: (required) questo valore deve corrispondere al nome dell'AppVault per l'applicazione di origine.

      • Spec.sourceApplicationName: (required) questo valore deve corrispondere al nome dell'applicazione di origine definita nell'applicazione di origine CR.

      • spec.sourceApplicationUID: (obbligatorio) Questo valore deve corrispondere all'UID dell'applicazione sorgente definita nel CR dell'applicazione sorgente.

      • spec.storageClassName: (Facoltativo) Scegli il nome di una classe di archiviazione valida sul cluster. La classe di archiviazione deve essere collegata a una VM di archiviazione ONTAP collegata in peering con l'ambiente di origine. Se non viene specificata la classe di archiviazione, verrà utilizzata per impostazione predefinita la classe di archiviazione predefinita sul cluster.

      • Spec.recurrenceRule: Consente di definire una data di inizio nell'ora UTC e un intervallo di ricorrenza.

        Esempio 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. Dopo aver popolato il trident-protect-relationship.yaml file con i valori corretti, applicare la CR:

      kubectl apply -f trident-protect-relationship.yaml -n my-app-namespace
    Creare un AppMirrorRelationship utilizzando l'interfaccia CLI

    1. Crea e applica l'oggetto AppMirrorRelationship, sostituendo i valori tra parentesi con le informazioni provenienti dal tuo ambiente:

      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>

      Esempio:

      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) nel cluster di destinazione, verificare lo stato e lo stato della relazione di replica:

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

Failover sul cluster di destinazione

Utilizzando Trident Protect è possibile eseguire il failover delle applicazioni replicate su un cluster di destinazione. Questa procedura interrompe la relazione di replica e porta l'app online sul cluster di destinazione. Trident Protect non arresta l'app sul cluster di origine se era operativa.

Fasi

  1. Nel cluster di destinazione, modificare il file CR AppMirrorRelationship (ad esempio, trident-protect-relationship.yaml) e modificare il valore di spec.desiredState in Promoted.

  2. Salvare il file CR.

  3. Applicare la CR:

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

  4. (Optional) creare tutte le pianificazioni di protezione necessarie per l'applicazione in cui è stato eseguito il failover.

  5. (Optional) controllare lo stato e lo stato della relazione di replica:

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

Risincronizzazione di una relazione di replica non riuscita

L'operazione di risincronizzazione ristabilisce la relazione di replica. Dopo aver eseguito un'operazione di risincronizzazione, l'applicazione di origine diventa l'applicazione in esecuzione e tutte le modifiche apportate all'applicazione in esecuzione sul cluster di destinazione vengono scartate.

Il processo arresta l'applicazione sul cluster di destinazione prima di ristabilire la replica.

Importante Tutti i dati scritti nell'applicazione di destinazione durante il failover andranno persi.
Fasi

  1. Opzionale: Nel cluster di origine, creare uno snapshot dell'applicazione di origine. In questo modo si garantisce che vengano acquisite le ultime modifiche dal cluster di origine.

  2. Nel cluster di destinazione, modificare il file CR AppMirrorRelationship (ad esempio, trident-protect-relationship.yaml) e modificare il valore di spec.desiredState in Established.

  3. Salvare il file CR.

  4. Applicare la CR:

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

  5. Rimuovere eventuali pianificazioni di protezione sul cluster di destinazione per proteggere l'applicazione in cui è stato eseguito il failover. Qualsiasi pianificazione rimanente causa errori di snapshot dei volumi.

Risincronizzazione inversa di una relazione di replica non riuscita

Quando si esegue la risincronizzazione inversa di una relazione di replica non riuscita, l'applicazione di destinazione diventa l'applicazione di origine e l'origine diventa la destinazione. Le modifiche apportate all'applicazione di destinazione durante il failover vengono mantenute.

Fasi

  1. Nel cluster di destinazione originale, eliminare la CR AppMirrorRelationship. Ciò fa sì che la destinazione diventi l'origine. Rimuovere eventuali pianificazioni relative alla protezione sul nuovo cluster di destinazione.

  2. Impostare una relazione di replica applicando i file CR utilizzati originariamente per impostare la relazione con i cluster opposti.

  3. Assicurarsi che la nuova destinazione (cluster di origine originale) sia configurata con entrambi i CRS AppVault.

  4. Impostare una relazione di replica sul cluster opposto, configurando i valori per la direzione inversa.

Invertire la direzione di replica dell'applicazione

Quando si inverte la direzione della replica, Trident Protect sposta l'applicazione sul backend di archiviazione di destinazione, continuando a replicare sul backend di archiviazione di origine. Trident Protect arresta l'applicazione di origine e replica i dati nella destinazione prima di eseguire il failover sull'app di destinazione.

In questa situazione, si sta sostituendo l'origine e la destinazione.

Fasi

  1. Nel cluster di origine, creare uno snapshot di arresto:

    Creare un'istantanea di arresto utilizzando una CR

    1. Disattivare le pianificazioni dei criteri di protezione per l'applicazione di origine.

    2. Creare un file ShutdownSnapshot CR:

      1. Creare il file di risorsa personalizzata (CR) e assegnargli un nome (ad esempio, trident-protect-shutdownsnapshot.yaml).

      2. Configurare i seguenti attributi:

        • metadata.name: (required) il nome della risorsa personalizzata.

        • Spec.AppVaultRef: (required) questo valore deve corrispondere al campo metadata.name dell'AppVault per l'applicazione di origine.

        • Spec.ApplicationRef: (required) questo valore deve corrispondere al campo metadata.name del file CR dell'applicazione di origine.

          Esempio 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. Dopo aver popolato il trident-protect-shutdownsnapshot.yaml file con i valori corretti, applicare la CR:

      kubectl apply -f trident-protect-shutdownsnapshot.yaml -n my-app-namespace
    Creare uno snapshot di arresto utilizzando l'interfaccia CLI

    1. Creare l'istantanea di arresto, sostituendo i valori tra parentesi con le informazioni provenienti dall'ambiente. Ad esempio:

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

  2. Sul cluster di origine, dopo il completamento dello snapshot di arresto, ottenere lo stato dello snapshot di arresto:

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

  3. Nel cluster di origine, trovare il valore di shutdownsnapshot.status.appArchivePath utilizzando il seguente comando e registrare l'ultima parte del percorso del file (chiamato anche nome di base; questo sarà tutto dopo l'ultima barra):

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

  4. Eseguire un failover dal nuovo cluster di destinazione al nuovo cluster di origine, con la seguente modifica:

    Nota Nel passaggio 2 della procedura di failover, includere il spec.promotedSnapshot campo nel file CR AppMirrorRelationship e impostarne il valore sul nome di base registrato nel passaggio 3 di cui sopra.

  5. Eseguire le operazioni di risincronizzazione inversa descritte in Risincronizzazione inversa di una relazione di replica non riuscita.

  6. Attiva le pianificazioni della protezione sul nuovo cluster di origine.

Risultato

A causa della replica inversa, si verificano le seguenti azioni:

  • Viene acquisita un'istantanea delle risorse Kubernetes dell'applicazione di origine.

  • I pod dell'applicazione di origine vengono interrotti correttamente eliminando le risorse Kubernetes dell'applicazione (lasciando PVC e PVS in posizione).

  • Una volta spenti i pod, vengono acquisite e replicate le istantanee dei volumi dell'applicazione.

  • Le relazioni di SnapMirror vengono interrotte, rendendo i volumi di destinazione pronti per la lettura/scrittura.

  • Le risorse Kubernetes dell'applicazione vengono ripristinate dallo snapshot pre-shutdown, utilizzando i dati del volume replicati dopo l'arresto dell'applicazione di origine.

  • La replica viene ristabilita in senso inverso.

Eseguire il failback delle applicazioni nel cluster di origine originale

Utilizzando Trident Protect, è possibile ottenere il "fail back" dopo un'operazione di failover utilizzando la seguente sequenza di operazioni. In questo flusso di lavoro per ripristinare la direzione di replicazione originale, Trident Protect replica (risincronizza) tutte le modifiche apportate all'applicazione di origine prima di invertire la direzione di replicazione.

Questo processo inizia da una relazione che ha completato un failover verso una destinazione e prevede i seguenti passaggi:

  • Iniziare con uno stato di failover.

  • Risincronizzazione inversa della relazione di replica.

    Avvertenza Non eseguire una normale operazione di risincronizzazione, in quanto i dati scritti nel cluster di destinazione verranno eliminati durante la procedura di failover.

  • Invertire la direzione di replica.

Fasi

  1. Eseguire i Risincronizzazione inversa di una relazione di replica non riuscitapassaggi.

  2. Eseguire i Invertire la direzione di replica dell'applicazionepassaggi.

Eliminare una relazione di replica

È possibile eliminare una relazione di replica in qualsiasi momento. Quando si elimina la relazione di replica dell'applicazione, vengono generate due applicazioni separate senza alcuna relazione tra di esse.

Fasi

  1. Nel cluster di desinazione corrente, eliminare AppMirrorRelationship CR:

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