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.

Replica le applicazioni utilizzando NetApp SnapMirror e Trident Protect

Collaboratori
PDF

Utilizzando Trident Protect, puoi utilizzare le funzionalità di replica asincrona della tecnologia NetApp SnapMirror per replicare le modifiche ai dati e alle applicazioni da un backend storage a un 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 RedHat OpenShift, è importante notare il ruolo critico delle annotazioni dello spazio dei nomi negli ambienti OpenShift. Le annotazioni dello spazio dei nomi assicurano che i pod ripristinati aderiscano alle autorizzazioni e alle configurazioni di sicurezza appropriate definite dai vincoli del contesto di protezione OpenShift (SCC) e possano accedere ai volumi senza problemi di autorizzazione. Per ulteriori informazioni, fare riferimento alla "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:

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

Se l'applicazione di origine è stata installata utilizzando Helm con il --create-namespace flag, viene assegnato un trattamento speciale al name tasto etichetta. Durante il processo di ripristino o failover, Trident Protect copia questa etichetta nello spazio dei nomi di destinazione, ma aggiorna il valore allo spazio dei nomi di destinazione se il valore di 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 per bloccare e sbloccare i file system durante le operazioni di protezione dei dati. "Ulteriori informazioni sulla configurazione del blocco del filesystem con Trident Protect".

Impostare una relazione di replica

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

  • Scegliere la frequenza con cui desideri che Trident Protect crei un'istantanea dell'applicazione (che include le risorse Kubernetes dell'app e gli snapshot di 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. Creare un AppVault per l'applicazione di origine sul cluster 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>

  2. 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: maria
  namespace: my-app-namespace
spec:
  includedNamespaces:
    - namespace: maria
      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 maria --namespaces maria -n my-app-namespace

  3. Se si desidera, creare un'istantanea dell'applicazione di origine. Questo snapshot viene utilizzato come base per l'applicazione nel cluster di destinazione. Se si salta questo passaggio, è necessario attendere l'esecuzione dello snapshot pianificato successivo in modo da disporre di uno snapshot recente.

    Acquisire un'istantanea utilizzando una 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: (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 dell'applicazione di origine CR.

        • 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-0e1f88ab-f013-4bce-8ae9-6afed9df59a1
  namespace: my-app-namespace
spec:
  appVaultRef: generic-s3-trident-protect-src-bucket-04b6b4ec-46a3-420a-b351-45795e1b5e34
  applicationRef: maria
  backupRetention: "0"
  enabled: true
  granularity: custom
  recurrenceRule: |-
    DTSTART:20220101T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  snapshotRetention: "2"

      1. 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
    Scattare una snapshot utilizzando la CLI

    1. Creare l'istantanea, sostituendo i valori tra parentesi con le informazioni dell'ambiente. Ad esempio:

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

  4. Creare un'applicazione di origine AppVault CR sul cluster di destinazione che sia identica all'AppVault CR applicato sul cluster di origine e denominarla (ad esempio, trident-protect-appvault-primary-destination.yaml).

  5. Applicare la CR:

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

  6. Creare un AppVault 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 my-app-namespace

  7. 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.storageClassName: (required) scegliere il nome di una classe di archiviazione valida nel cluster. È necessario eseguire il peering della classe storage con la classe di storage in uso nel cluster di origine in cui viene implementata l'applicazione di origine.

      • 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: maria
  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. Creare e applicare l'oggetto AppMirrorRelationship, sostituendo i valori tra parentesi con le informazioni dell'ambiente. Ad esempio:

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

  8. (Optional) controllare 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

Con Trident Protect puoi eseguire il failover di applicazioni replicate su un cluster di destinazione. Questa procedura interrompe la relazione di replica e porta l'applicazione online sul cluster di destinazione. Trident Protect non interrompe l'applicazione sul cluster di origine se era operativa.

Fasi

  1. Aprire il file AppMirrorRelationship CR (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. Creare un'istantanea dell'applicazione di origine.

  2. Aprire il file AppMirrorRelationship CR (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. Eliminare la CR AppMirrorRelationship nel cluster di destinazione originale. 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 AppVault CRS sia pronto su ogni cluster.

  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 di replica, Trident Protect sposta l'applicazione nel backend dello storage di destinazione, continuando nel contempo la replica nel back-end dello storage di origine. Trident Protect interrompe l'applicazione di origine e replica i dati sulla destinazione prima di eseguire il failover sull'app di destinazione.

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

Fasi

  1. Creare un'istantanea 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: maria

    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>

  2. Al termine dell'istantanea, ottenere lo stato dell'istantanea:

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

  3. Trovare il valore di shutdownsnapshot.status.appArchivePath utilizzando il comando seguente 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 cluster di destinazione al 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 replica originale, Trident Protect replica (risincronizza) tutte le modifiche apportate all'applicazione di origine prima di invertire la direzione di replica.

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. Eliminare la CR AppMirrorRelationship:

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