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

Impostare il failover e il failback per le VM in Red Hat OpenShift Virtualization utilizzando Trident Protect

Collaboratori netapp-jsnyder kevin-hoke
PDF

Configurare il disaster recovery per le VM in OpenShift Virtualization utilizzando Trident Protect. Questa procedura include la creazione di un AppVault con ONTAP S3, la definizione di relazioni AppMirror tra gli spazi dei nomi di origine e di ripristino di emergenza, la pianificazione della replica e l'esecuzione di operazioni di failover e failback per mantenere la disponibilità della VM durante le interruzioni del sito.

Prerequisiti

  • Trident deve essere installato. Le classi backend e storage devono essere create prima di installare OpenShift Virtualization sul cluster utilizzando l'operatore OpenShift Virtualization.

  • Per implementare le operazioni di failover e failback per le VM OpenShift, è necessario installare Trident Protect. Fare riferimento alle istruzioni qui per"installare Trident Protect"

OCP-v trident protect installato nello spazio dei nomi trident-protect

Una VM deve essere disponibile in OpenShift Virtualization. Per informazioni dettagliate sulla distribuzione di una nuova VM o sulla migrazione di una VM esistente in OpenShift Virtualization, consultare la sezione appropriata nella documentazione.

VM OCP-v installata nello spazio dei nomi source-ns

Crea App Vault utilizzando ONTAP S3

Questa sezione mostra come configurare un app vault in Trident Protect utilizzando Ontap S3 Object Storage.

Utilizzare i comandi oc e i file yaml mostrati di seguito per creare un segreto e la risorsa personalizzata appvault per ontap s3. Assicurati di crearli nello spazio dei nomi trident protect.

oc create -f app-vault-secret.yaml -n trident-protect
oc create -f app-vault.yaml -n trident-protect
apiVersion: v1
# You can provide the keys either as stringData or base 64 encoded data
stringData:
  accessKeyID: "<access key id as obtained from ONTAP>"
  secretAccessKey: "<secret access key as obtained from ONTAP>"
#data:
  #accessKeyID: <base 64 encoded value of access key>
  #secretAccessKey: <base 64 encoded value of secret access key>
kind: Secret
metadata:
  name: appvault-secret
  namespace: trident-protect
type: Opaque
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: ontap-s3-appvault
  namespace: trident-protect
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: trident-protect
      endpoint: <data lif to use to access S3>
      secure: "false"
      skipCertValidation: "true"
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: appvault-secret
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: appvault-secret
  providerType: OntapS3

Assicurarsi che il vault S3 di Ontap sia stato creato e sia nello stato Disponibile

Appvault OCP-v nello spazio dei nomi trident-protect

Creare un'app di protezione Trident per la VM

Creare una risorsa personalizzata dell'app nello spazio dei nomi in cui si trova la macchina virtuale.

Applicazione OCP-v nello spazio dei nomi source-ns

tridentctl-protect create app source-vm -n source-ns --namespaces source-ns

Applicazione OCP-v nello spazio dei nomi source-ns

Crea un'app di protezione Trident per la VM di Disaster Recovery in un nuovo spazio dei nomi

oc create ns dr-ns
tridentctl-protect create app dr-vm -n dr-ns --namespaces dr-ns

Applicazione OCP-v nello spazio dei nomi source-ns

Crea una pianificazione AppMirror nello spazio dei nomi di origine

Creare una pianificazione per AppMirror utilizzando lo yaml come mostrato. Ciò creerà snapshot utilizzando la pianificazione (ogni 5 minuti) e conserverà 2 snapshot

oc create -f appmirror-schedule.yaml -n source-ns
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  name: appmirror-sched1
spec:
  appVaultRef: ontap-s3-appvault
  applicationRef: source-vm
  backupRetention: "0"
  enabled: true
  granularity: Custom
  recurrenceRule: |-
    DTSTART:20240901T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  snapshotRetention: "2"

App mirror Pianificazione source-ns namespace

Istantanea creata

Creare una relazione appMirror nello spazio dei nomi DR

Creare una relazione Appmirror nello spazio dei nomi Disaster Recovery. Impostare lo stato desiderato su Stabilito.

apiVersion: protect.trident.netapp.io/v1
kind: AppMirrorRelationship
metadata:
  name: amr1
spec:
  desiredState: Established
  destinationAppVaultRef: ontap-s3-appvault
  destinationApplicationRef: dr-vm
  namespaceMapping:
  - destination: dr-ns
    source: source-ns
  recurrenceRule: |-
    DTSTART:20240901T000200Z
    RRULE:FREQ=MINUTELY;INTERVAL=5
  sourceAppVaultRef: ontap-s3-appvault
  sourceApplicationName: source-vm
  sourceApplicationUID: "<application UID of the source VM>"
  storageClassName: "ontap-nas"
Nota È possibile ottenere l'UID dell'applicazione della VM di origine dall'output JSON dell'app di origine, come mostrato di seguito

UID dell'app creato

Crea relazione App Mirror

Una volta stabilita la relazione AppMirror, lo snapshot più recente viene trasferito allo spazio dei nomi di destinazione. Il PVC viene creato per la VM nello spazio dei nomi dr, tuttavia il pod della VM non è ancora stato creato nello spazio dei nomi dr.

La relazione Crea App Mirror è stata stabilita

Modifiche di stato per App Mirror

PVC viene creato nello spazio dei nomi di destinazione

Promuovere la relazione con Failover

Modificare lo stato desiderato della relazione in "Promosso" per creare la VM nello spazio dei nomi DR. La VM è ancora in esecuzione nello spazio dei nomi di origine.

oc patch amr amr1 -n dr-ns --type=merge -p '{"spec":{"desiredState":"Promoted"}}'

Patch di applicazione della relazione AppMirror

La relazione AppMirror è in stato promosso

VM creata nello spazio dei nomi DR

La VM nella sorgente ns è ancora in esecuzione

Ripristinare la relazione con Failback

Modificare lo stato desiderato della relazione in "Stabilito". La VM viene eliminata nello spazio dei nomi DR. Il pvc esiste ancora nello spazio dei nomi DR. La VM è ancora in esecuzione nello spazio dei nomi di origine. Viene stabilita la relazione originale tra lo spazio dei nomi di origine e i DR ns. .

oc patch amr amr1 -n dr-ns --type=merge -p '{"spec":{"desiredState":"Established"}}'

Patch allo stato stabilito

App Mirror nello stato stabilito

Il PVC nei DR ns rimane ancora

POD e PVC nella sorgente ns rimangono ancora

Dimostrazione video

Il seguente video mostra una dimostrazione dell'implementazione di uno scenario di Disaster Recovery per una VM OpenShift utilizzando Trident Protect

Disaster Recovery tramite Trident Protect