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

Richten Sie Failover und Failback für VMs in Red Hat OpenShift Virtualization mit Trident Protect ein

Beitragende netapp-jsnyder kevin-hoke
PDFs

Richten Sie mit Trident Protect die Notfallwiederherstellung für VMs in OpenShift Virtualization ein. Dieses Verfahren umfasst das Erstellen eines AppVault mit ONTAP S3, das Einrichten von AppMirror-Beziehungen zwischen Quell- und Disaster Recovery-Namespaces, das Planen der Replikation und das Ausführen von Failover- und Failback-Vorgängen, um die VM-Verfügbarkeit während Site-Ausfällen aufrechtzuerhalten.

Voraussetzungen

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

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

OCP-v Trident Protect im Trident-Protect-Namespace installiert

Eine VM muss in OpenShift Virtualization verfügbar sein. Einzelheiten zum Bereitstellen einer neuen VM oder zum Migrieren einer vorhandenen VM in OpenShift Virtualization finden Sie im entsprechenden Abschnitt der Dokumentation.

OCP-v VM im Source-NS-Namespace installiert

App Vault mit ONTAP S3 erstellen

In diesem Abschnitt wird gezeigt, wie Sie mithilfe des Ontap S3-Objektspeichers einen App-Tresor in Trident Protect einrichten.

Verwenden Sie OC-Befehle und die unten gezeigten YAML-Dateien, um ein Geheimnis 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 der Ontap S3-Tresor erstellt wurde und sich im Status „Verfügbar“ 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 -Schutz-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 Quellnamespace

Erstellen Sie mithilfe des YAML wie gezeigt einen Zeitplan für AppMirror. Dadurch werden Snapshots nach dem Zeitplan (alle 5 Minuten) erstellt und 2 Snapshots gespeichert

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-Spiegel Zeitplan source-ns Namespace

Snapshot erstellt

Erstellen Sie eine AppMirror-Beziehung im DR-Namespace

Erstellen Sie eine Appmirror-Beziehung im Disaster Recovery-Namespace. Setzen Sie den gewünschten Status auf „Etabliert“.

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 erstellt

App Mirror-Beziehung erstellen

Wenn die AppMirror-Beziehung hergestellt ist, wird der aktuellste Snapshot in den Zielnamespace übertragen. Der PVC wird für die VM im dr-Namespace erstellt, der VM-Pod wird jedoch noch nicht im dr-Namespace erstellt.

App-Spiegel-Beziehung erstellen ist hergestellt

Statusänderungen für App Mirror

PVC wird im Zielnamespace erstellt

Fördern Sie die Beziehung zum Failover

Ändern Sie den gewünschten Status der Beziehung in „Promoted“, um die VM im DR-Namespace zu erstellen. Die VM wird weiterhin im Quellnamespace ausgeführt.

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

Patch für AppMirror-Beziehung anwenden

AppMirror-Beziehung befindet sich im Status „Promoted“

Im DR-Namespace erstellte VM

VM in Quell-NS läuft noch

Stellen Sie die Beziehung erneut zu Failback her

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

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

Patch zum etablierten Zustand

App Mirror im etablierten Zustand

PVC in DR ns bleibt weiterhin

POD und PVC in der Quelle ns bleibt weiterhin

Videodemonstration

Das folgende Video zeigt eine Demonstration der Implementierung eines Disaster Recovery-Szenarios für eine OpenShift-VM mit Trident Protect

Notfallwiederherstellung mit Trident Protect