Skip to main content
NetApp Solutions
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Utilisez Trident Protect pour implémenter le basculement et le retour arrière pour les machines virtuelles dans OpenShift Virtualization

Contributeurs

Présentation

Cette section fournit des informations détaillées sur la mise en œuvre du basculement et du retour arrière des machines virtuelles dans la virtualisation OpenShift à l'aide de Trident Protect. Les procédures sont identiques, que les VM soient des clusters OpenShift sur site ou des clusters ROSA. Cette section présente les procédures de création d'un stockage objet ONTAP s3 à utiliser en tant qu'appvault pour Trident Protect et de création d'une planification pour le miroir d'applications. Après cela, il explique comment créer une relation de miroir d'application. Enfin, il explique comment modifier l'état de la relation de mise en miroir des applications pour effectuer le basculement et le retour arrière.

Prérequis

  • Trident doit être installé. Les classes backend et de stockage doivent être créées avant l'installation d'OpenShift Virtualization sur le cluster à l'aide de l'opérateur OpenShift Virtualization.

  • Trident Protect doit être installé pour mettre en œuvre des opérations de basculement et de restauration pour les machines virtuelles OpenShift. Reportez-vous aux instructions de la section "installez Trident protect"

OCP-v Trident Protect installé dans l'espace de noms Trident-Protect

Une VM doit être disponible dans OpenShift Virtualization. Pour plus d'informations sur le déploiement d'une nouvelle machine virtuelle ou sur la migration d'une machine virtuelle existante vers OpenShift Virtualization, consultez la section appropriée de la documentation.

OCP-v VM installé dans l'espace de noms source-ns

Création d'un coffre-fort d'applications à l'aide d'ONTAP S3

Cette section explique comment configurer un coffre-fort d'applications dans Trident Protect à l'aide du stockage objet ONTAP S3.

Utilisez les commandes oc et les fichiers yaml illustrés ci-dessous pour créer un secret et la ressource personnalisée appvault pour ONTAP s3. Veillez à les créer dans l'espace de noms 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

Assurez-vous que le coffre-fort ONTAP S3 est créé et qu'il est à l'état disponible

Coffre-fort d'applications OCP-v dans l'espace de noms Trident-Protect

Créez une application Trident Protect pour la machine virtuelle

Créez une ressource personnalisée d'application dans l'espace de nom où se trouve la machine virtuelle.

Application OCP-v dans l'espace de noms source-ns

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

Application OCP-v dans l'espace de noms source-ns

Créez une application Trident Protect pour la machine virtuelle de reprise après incident dans un nouvel espace de noms

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

Application OCP-v dans l'espace de noms source-ns

Créez une planification AppMirror dans l'espace de noms source

Créez un planning pour AppMirror à l'aide du yaml comme indiqué. Cela créera des instantanés en utilisant le planning (toutes les 5 minutes) et conservera 2 instantanés

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"

Espace de noms source-ns du programme de mise en miroir des applications

Snapshot créé

Créez une relation appMirror dans le namespace DR

Créez une relation Appmirror dans l'espace de noms de reprise après incident. Définissez l'état desiredState sur établi.

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"
Remarque Vous pouvez obtenir l'UID d'application de la machine virtuelle source à partir de la sortie json de l'application source, comme illustré ci-dessous

UID d'application créé

Créer une relation App Mirror

Lorsque la relation AppMirror est établie, le snapshot le plus récent est transféré dans l'espace de noms de destination. La demande de volume persistant est créée pour la machine virtuelle dans l'espace de nom de reprise après incident, mais le pod de machine virtuelle n'est pas encore créé dans l'espace de noms de reprise après incident.

Créer une relation App Mirror est établie

Changements d'état pour le miroir d'application

La demande de volume persistant est créée dans le namespace de destination

Promouvoir la relation avec le basculement

Définissez l'état souhaité de la relation sur « promu » pour créer la machine virtuelle dans le namespace de DR. La machine virtuelle s'exécute toujours dans l'espace de noms source.

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

La relation AppMirror applique le correctif

La relation AppMirror est à l'état promu

Machine virtuelle créée dans le namespace DR

La machine virtuelle dans les ns source est toujours en cours d'exécution

Établir à nouveau la relation avec le retour arrière

Modifier l'état souhaité de la relation sur « établi ». La VM est supprimée dans l'espace de noms DR. La demande de volume persistant existe toujours dans le namespace de DR. La machine virtuelle s'exécute toujours dans l'espace de noms source. La relation d'origine entre l'espace de noms source et les DR ns est établie. .

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

Patch à l'état établi

App Mirror à l'état établi

Le PVC reste toujours dans les DR ns

Le POD et le PVC dans les sources ns restent toujours