NetApp Disaster Recovery ist ein Cloud-basiertes Disaster-Recovery-Service, das über die NetApp Console zugänglich ist und Disaster-Recovery-Workflows für VMware- und Kubernetes-Umgebungen automatisiert. Es repliziert lokale VMware-Workloads mit ONTAP-Speicher oder Kubernetes-Workloads mit von Trident verwaltetem ONTAP-Speicher an einen anderen Standort als Disaster-Recovery-Ziel. Der Service verwendet ONTAP SnapMirror Technologie mit nativer VMware-Orchestrierung oder Trident Protect-Orchestrierung, um Workloads zu schützen und dabei ONTAP-Speichereffizienzen wie Komprimierung und Deduplizierung zu bewahren.

Disaster Recovery muss nicht separat aktiviert werden. Es erscheint automatisch in der linken Navigation der NetApp Console unter Protection > Disaster recovery. Zum Zugriff auf die NetApp Console im Browser Folgendes eingeben: "https://console.netapp.com/".

Für den vollständigen und dauerhaften Zugriff ist eine Disaster Recovery-Lizenz erforderlich. Der Dienst kann mit einer 30-tägigen kostenlosen Testversion ausprobiert werden, bevor eine Lizenz oder ein Abonnement erworben wird. Weitere Einzelheiten finden sich unter "Einrichtung der NetApp Disaster Recovery Lizenzierung".

Disaster Recovery unterstützt die folgenden Schutzziele:

Für VMware Workloads unterstützt Disaster Recovery die folgenden Datenspeichertypen:

Für Kubernetes-Workloads schützt Disaster Recovery persistente Volumes, die über NetApp Trident auf ONTAP Storage bereitgestellt werden.

Disaster Recovery bietet folgende Lizenzierungsoptionen:

Die Kosten für die NetApp Disaster Recovery basieren auf der genutzten Kapazität der Datenspeicher am Quellstandort, wenn mindestens eine VM oder Kubernetes-Ressource einen Replikationsplan hat.

Bei einer BYOL-Umgebung (Bring Your Own License) sind die Funktionen des Dienstes eingeschränkt, wenn die Datenmenge die zulässige Kapazität überschreitet, bis eine zusätzliche Kapazitätslizenz erworben oder die Lizenz in der NetApp Console aktualisiert wird.

Nach Ablauf der kostenlosen Testphase können Sie weiterhin Ressourcen wie Workloads und Replikationspläne einsehen und löschen sowie alle während der Testphase erstellten geplanten Vorgänge ausführen. Um den Dienst weiterhin mit vollem Funktionsumfang nutzen zu können, benötigen Sie entweder ein PAYGO-Abonnement von Ihrem Cloud-Anbieter oder eine BYOL-Lizenz von NetApp.

Sie können jederzeit eine Lizenz erwerben oder ein Abonnement abschließen und die Zahlung erfolgt erst, wenn die 30-tägige Testphase endet.

Disaster Recovery unterstützt die folgenden Topologien:

Die vollständige Liste ist unter "Voraussetzungen für die Notfallwiederherstellung" zu finden.

Ein Console Agent ist eine Softwarekomponente, die es der NetApp Console ermöglicht, mit Ihrem ONTAP Storage sowie VMware vCenter Clustern oder Kubernetes Clustern zu kommunizieren. Er ist erforderlich, damit Disaster Recovery ordnungsgemäß funktioniert. Der Agent befindet sich in Ihrem privaten Netzwerk, entweder in einem lokalen Datacenter oder in einer Cloud VPC, und kommuniziert mit Ihren ONTAP Storage Instanzen sowie vCenter Clustern oder Kubernetes Clustern.

Für die Disaster Recovery von On-Premises zu On-Premises wird der lokale Console Agent am Disaster-Recovery-Standort installiert. Für die Disaster Recovery von On-Premises zu AWS wird der Console Agent für AWS in Ihrer AWS VPC installiert. Sowohl die Quell- als auch die Ziel-vCenter Cluster oder Kubernetes Cluster sollten denselben Console Agent verwenden. Disaster Recovery funktioniert nur mit dem Agent Deployment im Standardmodus.

Jeder Kubernetes-Cluster muss NetApp Trident installiert haben, ein ONTAP Backend und eine Storage-Klasse müssen konfiguriert sein, und die Volume Snapshot CRDs sowie der Controller müssen installiert sein. Anwendungen müssen persistente Volumes verwenden, die über die Trident Storage-Klasse bereitgestellt werden. Wenn ein Kubernetes-Cluster als Standort hinzugefügt wird, führt Disaster Recovery durch die Installation und Registrierung von Trident Protect auf diesem Cluster. Siehe "Anforderungen an einen Kubernetes Cluster für die NetApp Disaster Recovery" für Schritt-für-Schritt-Befehle und Überprüfungen.

Ein Standort ist ein logischer Container, der typischerweise einem physischen Rechenzentrum oder Cloud-Standort zugeordnet ist und einen oder mehrere vCenter Cluster oder Kubernetes-Cluster hostet. Sowohl ein Quellstandort (Produktionsstandort) als auch ein Zielstandort (Disaster-Recovery-Standort) werden hinzugefügt, bevor ein Replikationsplan erstellt wird.

Eine Ressourcengruppe ist ein logischer Container, mit dem Sie mehrere VMs, Datastores oder Kubernetes Namespaces und Ressourcen als eine Einheit managen können, sodass sie mit einem gemeinsamen Snapshot geschützt werden können. Eine VM kann jeweils nur einer Ressourcengruppe angehören. Für jede Applikation oder Workload, die Sie schützen möchten, kann eine eigene Ressourcengruppe erstellt werden.

Ein Replikationsplan ist ein Regelwerk, das festlegt, wie oft Backups erstellt und wie Failover-Ereignisse behandelt werden. Er wählt Quell- und Zielstandorte aus, weist Ressourcengruppen zu, definiert Wiederherstellungszuordnungen und konfiguriert das Einschaltverhalten. Pläne definieren das Recovery Point Objective (RPO) durch die Häufigkeit der Datenreplizierung.

Recovery Point Objective (RPO) ist der maximal akzeptable Datenverlust im Katastrophenfall; er wird durch die Replikationsfrequenz oder den Zeitplan des Replikationsplans definiert. Recovery Time Objective (RTO) ist die maximal akzeptable Zeitspanne für die Wiederherstellung nach einer Katastrophe; sie wird dadurch bestimmt, wie lange das Failover zum DR-Standort und der Neustart aller VMs oder Anwendungen dauert.

Die einzelnen Schritte sind unter "Standorte in der NetApp Disaster Recovery hinzufügen" zu finden.

Die Erkennung wird standardmäßig alle 24 Stunden ausgeführt; der Zeitplan kann an Ihre Umgebung angepasst werden. Das minimale Intervall beträgt 30 Minuten und das maximale 24 Stunden. NetApp empfiehlt, zunächst einige manuelle Erkennungen durchzuführen, um aktuelle Informationen zu erhalten, und anschließend den Zeitplan auf automatische Ausführung zu setzen. Neu hinzugefügte oder gelöschte Ressourcen werden bei der nächsten geplanten oder manuellen Erkennung erkannt.

Nein. Das Hosten von geschützten und ungeschützten VMs auf demselben Datenspeicher kann Probleme verursachen. Wenn der Datenspeicher ein Failover durchläuft, existieren nach dem Failover keine ungeschützten VMs mehr am ursprünglichen Standort, und NetApp Disaster Recovery startet sie nicht am Failover-Standort.

Die Ressourcen sollten vor der Bereitstellung von Disaster Recovery so organisiert werden, dass geschützte und ungeschützte Workloads separate Teilmengen von Datenspeichern verwenden und sichergestellt ist, dass ein einzelner Datenspeicher nicht durch mehr als einen Replikationsplan geschützt wird.

Wenn die Verwendung von plattformverwalteten (ONTAP-verwalteten) Backups vorgesehen ist, sollte die MirrorAll Richtlinie verwendet werden. MirrorVault und Asynchron sind akzeptable Alternativen, allerdings muss sichergestellt werden, dass der während des Failovers oder Failbacks ausgewählte Snapshot sowohl auf dem Quell- als auch auf dem Zielvolume vorhanden ist, da der Vorgang andernfalls mit dem Fehler „no common snapshot found“ fehlschlägt. MirrorLatest wird nicht empfohlen, da dadurch nur ein gemeinsamer Snapshot für das Failover verbleibt. Für SnapMirror Beziehungen, die von NetApp Disaster Recovery verwaltet werden, sollten außerhalb des Dienstes keine Aktualisierungen geplant werden, da Disaster Recovery das Replikations-Timing steuert.

Ja. Wenn zwischen den Quell- und Zielvolumes eines geschützten Datenspeichers bereits eine SnapMirror Beziehung besteht, verwendet Disaster Recovery diese Beziehung für alle Replikationsvorgänge, anstatt eine neue zu erstellen.

Ja. VMware-Anwendungen können mithilfe eines für die Migration konfigurierten Replikationsplans von einem Quellstandort zu einem anderen migriert werden. Nach der Initiierung der Migration überprüft der Service alle 30 Minuten, ob die Migration planmäßig verläuft; der Fortschritt kann in der Auftragsüberwachung verfolgt werden. Migration wird derzeit für Kubernetes-basierte Workloads nicht unterstützt. Siehe "Anwendungen auf einen anderen Standort migrieren".

Ja. Ein Test-Failover ändert weder das ursprüngliche Quellvolume noch beeinträchtigt es die SnapMirror Beziehung, und die Produktions-Workloads werden weiterhin normal repliziert. Bei VMware-Workloads erstellt Disaster Recovery temporäre VMs aus einem FlexClone Volume des ausgewählten Snapshots und ordnet den ESXi Hosts einen temporären, durch FlexClone gestützten Datastore zu. Bei Kubernetes-Workloads stellt der Test die geschützten Applikationen und persistenten Volumes auf dem Ziel-Cluster wieder her. Nach dem Test lässt sich die Testumgebung mit der Aktion Clean up failover test bereinigen. Siehe "Failover von Anwendungen auf einen Remote-Standort".

Ja. Sie konfigurieren die Startreihenfolge im Replikationsplan. Standardmäßig starten alle Entitäten parallel, aber Sie können jeder Entität eine sequenzielle Nummer (z. B. 1, 2, 3) zuweisen, um die Startreihenfolge zu steuern, oder mehreren Ressourcen dieselbe Nummer zuweisen, damit sie gleichzeitig starten. Sie können außerdem pro Ressource eine Startverzögerung (0–10 Minuten) festlegen, um den Start zu staffeln. Das ist hilfreich, um sicherzustellen, dass priorisierte Ressourcen zuerst ausgeführt werden. Die Startreihenfolge wird sowohl für VMware- als auch für Kubernetes-Workloads unterstützt.

Nach Behebung eines Fehlers stellt das Failback den Betrieb am ursprünglichen Quellstandort wieder her. Ausgehend von einer Beziehung, die auf das Ziel umgeschaltet wurde, synchronisiert NetApp Disaster Recovery alle Änderungen zurück zur ursprünglichen Quell-VM oder dem Kubernetes-Cluster, bevor die Replikationsrichtung umgekehrt wird. Der Prozess:

Siehe "Anwendungen auf die ursprüngliche Quelle zurückverschieben".

Das Disaster Recovery Dashboard bietet einen Überblick darüber, ob Standorte und Pläne intakt, getrennt oder beeinträchtigt sind, zeigt aktuelle Warnungen und fehlgeschlagene Jobs an, ermöglicht die Identifizierung geschützter und ungeschützter Workloads und stellt die Kapazität auf einen Blick dar. Siehe "Status des Disaster Recovery-Plans anzeigen".

Die Jobüberwachung ermöglicht die Überprüfung von Zeitstempeln, Status und Initiator eines Auftrags (oder „System“, wenn NetApp Disaster Recovery ihn initiiert hat). Ein Auftrag mit dem Status „In Bearbeitung“ oder „In der Warteschlange“ kann über das Aktionsmenü abgebrochen werden, was hilfreich ist, wenn ein Auftrag festhängt oder eine andere Operation priorisiert werden muss. Siehe "Disaster Recovery Jobs überwachen".

Berichte können für VMware, Kubernetes oder alle Workloads erstellt werden und enthalten Details zum Replikationsplan, Compliance-Status und Zusammenfassungen der Jobs. Berichte können als PDF-, HTML- oder JSON-Dateien heruntergeladen werden. Sie beziehen sich auf einen Zeitraum von ein bis sieben Tagen. Weitere Informationen finden sich unter "Berichte in Disaster Recovery erstellen".

Ein AppVault ist das Cloud-Speicherziel, an dem Trident Protect die Kubernetes-Schutzdaten speichert. Ein AppVault wird beim Konfigurieren eines Kubernetes-Replikationsplans erstellt. AppVaults können auch auf der Seite „Einstellungen“ verwaltet werden.