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.

Esegui il failover a uno snapshot precedente usando Trident Protect

Collaboratori netapp-shwetav
PDF

Usa Trident Protect per eseguire il failover di un'applicazione replicata verso uno snapshot precedente, consentendoti di ripristinare i dati a un momento precedente al loro danneggiamento o alla loro compromissione. Per impostazione predefinita, il failover utilizza lo snapshot trasferito più di recente.

Avvertenza Il passaggio a uno snapshot precedente fa sì che ONTAP SnapMirror elimini gli snapshot sul cluster di destinazione più recenti dello snapshot selezionato, perché non sono più validi. Aggiungi l'annotazione in questa procedura solo se questa perdita di dati è accettabile.
Prima di iniziare

  • Esiste un oggetto AppMirrorRelationship ed è nello stato Established. Per crearne uno, consulta "Impostare una relazione di replica". Per verificare lo stato, esegui kubectl get amr -n <namespace> <relationship_name> -o=jsonpath='{.status}'.

  • I cluster di origine e di destinazione utilizzano backend di storage ONTAP con replica SnapMirror. Azure NetApp Files e altri backend non-ONTAP non sono supportati. Consulta "Requisiti per la replica SnapMirror".

  • Nell'applicazione di origine esiste una pianificazione di snapshot (con snapshotRetention valore maggiore di 1).

Identifica l'istantanea

Ogni istantanea ha un orario di completamento, quindi puoi scegliere il momento che desideri.

Fasi

  1. Sul cluster di origine, elenca gli snapshot:

    kubectl get snapshots -n my-app-namespace

  2. Individua l'istantanea a cui eseguire il failover. Utilizza il completionTimestamp valore per selezionare il momento desiderato.

  3. Ottieni il percorso dell'archivio di quella snapshot:

    kubectl get snapshots <snapshot_name> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'

  4. Registra l'ultima parte del percorso, ovvero tutto ciò che segue l'ultima barra. Questa parte è il basename. Ad esempio:

    20231114173500_schedule-20231114173500_f8df8bd3-a727-4a14-b954-9666aa618b55
    Nota Usa il nome base, non il nome della risorsa personalizzata snapshot.
Risultato

Il nome di base dello snapshot selezionato viene registrato.

Passa allo snapshot selezionato in caso di errore

Specifica l'istantanea da promuovere e conferma la perdita di dati aggiungendo un'annotazione.

Fasi

  1. Sul cluster di destinazione, aggiungi l'annotazione a AppMirrorRelationship. Senza l'annotazione, un failover può utilizzare solo lo snapshot trasferito più di recente.

    kubectl annotate appmirrorrelationship <relationship_name> -n my-app-namespace protect.trident.netapp.io/allow-promotion-with-older-snapshots="true"

  2. Modifica il file CR AppMirrorRelationship (ad esempio trident-protect-relationship.yaml):

    • Imposta spec.desiredState su Promoted.

    • Imposta spec.promotedSnapshot sul nome base che hai registrato in Identifica l'istantanea.

      Ad esempio:

    apiVersion: protect.trident.netapp.io/v1
kind: AppMirrorRelationship
metadata:
  name: <relationship_name>
  namespace: <namespace>
  annotations:
    protect.trident.netapp.io/allow-promotion-with-older-snapshots: "true"
spec:
  desiredState: Promoted
  promotedSnapshot: <basename>

  3. Applicare la CR:

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

  4. Verifica lo stato della relazione:

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

La relazione passa allo Promoted stato e l'applicazione viene eseguita sul cluster di destinazione con i dati dello snapshot selezionato.

Se la relazione rimane nello Promoting`stato e `status.error`mostra `The snapshot provided is invalid or older than the most recently transferred snapshot, l'annotazione è mancante o non è impostata su true. Aggiungi l'annotazione e riprova.

Quali sono le prossime novità?

Per tornare al cluster originale, esegui un "risincronizzazione inversa" e poi "invertire la direzione della replica".

Avvertenza Per tornare al cluster originale, non eseguire una normale risincronizzazione. Una normale risincronizzazione scarta l'applicazione di failover e ripristina la relazione con l'istantanea di origine più recente.