Utilisez Trident Protect pour implémenter le basculement et le retour arrière pour les machines virtuelles dans OpenShift Virtualization
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"
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.
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
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.
tridentctl-protect create app source-vm -n source-ns --namespaces 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
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"
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"
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 |
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.
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"}}'
É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"}}'