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 der NetApp Console die Kommunikation mit Ihrem ONTAP Storage und Ihren VMware vCenter Clustern ermöglicht. Für die ordnungsgemäße Funktion von NetApp Disaster Recovery ist er erforderlich. Der Agent befindet sich in Ihrem privaten Netzwerk (entweder in einem lokalen Rechenzentrum oder in einer Cloud-VPC) und kommuniziert mit Ihren ONTAP Storage Instanzen und vCenter Clustern.

Für die Notfallwiederherstellung von lokalen Systemen zu lokalen Systemen ist der lokale Console-Agent am Notfallwiederherstellungsstandort zu installieren. Für die Notfallwiederherstellung von lokalen Systemen zu AWS ist der Console-Agent für AWS in Ihrer AWS VPC zu installieren. Sowohl der Quell- als auch der Ziel-vCenter-Cluster sollten denselben Console-Agent verwenden. Die Notfallwiederherstellung funktioniert nur mit der Agentenbereitstellung 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 verwalten 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 Anwendung oder Arbeitslast, die geschützt werden soll, kann eine Ressourcengruppe erstellt werden, und die VMs werden entsprechend der innerhalb der Gruppe konfigurierten Startreihenfolge eingeschaltet.

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. Während eines Test-Failovers erstellt Disaster Recovery temporäre VMs aus einem neuen FlexClone Volume des ausgewählten Snapshots und ordnet einen temporären, auf FlexClone basierenden Datenspeicher den ESXi-Hosts zu. Dabei wird keine zusätzliche physische Kapazität verbraucht, das ursprüngliche Quellvolume nicht verändert und weder die SnapMirror Beziehung noch die Produktions-Workloads werden beeinträchtigt, die weiterhin normal repliziert werden. Nach dem Test erfolgt die Bereinigung der Testumgebung über die Aktion Clean up failover test. Siehe "Failover von Anwendungen auf einen Remote-Standort".

Ja. Standardmäßig starten alle VMs parallel, aber jeder VM kann eine sequenzielle Nummer (z. B. 1, 2, 3) zugewiesen werden, um die Startreihenfolge zu steuern, oder mehreren VMs kann dieselbe Nummer zugewiesen werden, damit sie gleichzeitig starten. Es kann auch eine Startverzögerung (0–10 Minuten) pro VM festgelegt werden, um den Start zu staffeln, was nützlich ist, um sicherzustellen, dass VMs mit höherer Priorität laufen, bevor VMs mit niedrigerer Priorität starten.

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, in dem Trident Protect Kubernetes-Schutzdaten speichert. Ein AppVault wird beim Konfigurieren eines Kubernetes-Replikationsplans erstellt.