Skip to main content
NetApp Solutions
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Verwenden Sie Trident Protect, um Failover und Failback für VMs in OpenShift Virtualization zu implementieren

Beitragende
PDFs

Überblick

Dieser Abschnitt enthält Details zur Implementierung von Failover und Failback von VMs in OpenShift Virtualization mit Trident Protect. Die Verfahren sind gleich, unabhängig davon, ob es sich bei den VMs um lokale OpenShift-Cluster oder auf ROSA-Clustern handelt. In diesem Abschnitt werden die Verfahren zum Erstellen eines ONTAP s3-Objektspeichers beschrieben, der als Appvault für Trident Protect verwendet werden soll, und es wird ein Zeitplan für die App-Spiegelung erstellt. Danach zeigt es, wie man eine App-Spiegelbeziehung erstellt. Schließlich wird gezeigt, wie der Status der App-Spiegelungsbeziehung geändert wird, um Failover und Failback durchzuführen.

Voraussetzungen

  • Trident muss installiert sein. Back-End- und Storage-Klassen müssen erstellt werden, bevor OpenShift Virtualization mithilfe des OpenShift Virtualization Operators auf dem Cluster installiert wird.

  • Um Failover- und Failback-Vorgänge für die OpenShift-VMs zu implementieren, muss Trident Protect installiert sein. Beachten Sie die Anweisungen hier unter "Installieren Sie Trident Protect"

OCP-V Trident Protect installiert im Trident-Protect Namespace

In OpenShift Virtualization muss eine VM verfügbar sein. Details zur Bereitstellung einer neuen VM oder zur Migration einer vorhandenen VM in OpenShift Virtualization finden Sie im entsprechenden Abschnitt in der Dokumentation.

OCP-V VM im Source-ns Namespace installiert

Erstellen Sie App Vault mit ONTAP S3

In diesem Abschnitt wird das Einrichten eines App Vault in Trident Protect mit ONTAP S3 Objekt-Storage erläutert.

Verwenden Sie oc-Befehle und die unten gezeigten yaml-Dateien, um einen Secret und die benutzerdefinierte Appvault-Ressource für ONTAP s3 zu erstellen. Stellen Sie sicher, dass Sie sie im Trident Protect Namespace erstellen.

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

Stellen Sie sicher, dass ONTAP S3 Vault erstellt wurde und sich im verfügbaren Status befindet

OCP-V appvault im Trident-Protect Namespace

Erstellen Sie eine Trident Protect-App für die VM

Erstellen Sie eine benutzerdefinierte App-Ressource im Namespace, in dem sich die VM befindet.

OCP-V App im Source-ns Namespace

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

OCP-V App im Source-ns Namespace

Erstellen Sie eine Trident Protect-App für die Disaster Recovery VM in einem neuen Namespace

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

OCP-V App im Source-ns Namespace

Erstellen Sie einen AppMirror-Zeitplan im Quell-Namespace

Erstellen Sie einen Zeitplan für AppMirror mit yaml, wie in der Abbildung dargestellt. Dadurch werden Snapshots mit dem Zeitplan erstellt (alle 5 Minuten) und 2 Snapshots beibehalten

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"

Application Mirror Schedule source-ns Namespace

Snapshot wurde erstellt

Erstellen Sie eine appMirror-Beziehung im DR Namespace

Erstellen Sie eine Appmirror-Beziehung im Namespace Disaster Recovery. Legen Sie den Status „DesiredState“ auf „hergestellt“ fest.

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"
Hinweis Sie können die Anwendungs-UID der Quell-VM aus der json-Ausgabe der Quell-App abrufen, wie unten gezeigt

App-UID wurde erstellt

Erstellen Sie eine App Mirror-Beziehung

Wenn die AppMirror-Beziehung hergestellt wird, wird der letzte Snapshot an den Ziel-Namespace übertragen. Die PVC wird für die VM im dr Namespace erstellt, der VM-Pod ist jedoch noch nicht im dr Namespace erstellt.

App Mirror-Beziehung erstellen wurde hergestellt

Statusänderungen für App-Spiegelung

Die PVC wird im Ziel-Namespace erstellt

Fördern Sie die Beziehung zu Failover

Ändern Sie den gewünschten Status der Beziehung in „befördert“, um die VM im DR Namespace zu erstellen. Die VM wird noch im Quell-Namespace ausgeführt.

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

AppMirror Relationship Apply Patch

AppMirror-Beziehung befindet sich im Status „hochgestuft“

VM im DR Namespace erstellt

VM in der Quelle wird noch ausgeführt

Bauen Sie die Beziehung wieder zu einem Failback auf

Ändern Sie den gewünschten Status der Beziehung in „hergestellt“. Die VM wird im DR Namespace gelöscht. Die pvc ist weiterhin im DR Namespace vorhanden. Die VM wird noch im Quell-Namespace ausgeführt. Die ursprüngliche Beziehung vom Quell-Namespace zu DR ns wird hergestellt. .

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

Patch auf etablierten Status

App Mirror im etablierten Status

PVC in DR ns bleibt bestehen

POD und PVC in Quelle ns verbleiben immer noch