Vereinfachte Benutzererfahrung für die Erkennung von vCenter und Kubernetes-Clustern sowie die Wiederherstellung von Applikationen mit mehreren zeitpunktgenauen Wiederherstellungsvorgängen.

Niedrigere Gesamtbetriebskosten durch reduzierte Betriebskosten und die Möglichkeit, Notfallwiederherstellungspläne mit minimalem Ressourcenaufwand zu erstellen und anzupassen.

Kontinuierliche Notfallwiederherstellungsbereitschaft mit virtuellen Failover-Tests, die den Betrieb nicht unterbrechen. Sie können Ihre DR-Failover-Pläne regelmäßig testen, ohne die Produktionsarbeitslast zu beeinträchtigen.

Schnellere Wertschöpfung durch dynamische Änderungen in Ihrer IT-Umgebung und die Möglichkeit, diese in Ihren Notfallwiederherstellungsplänen zu berücksichtigen.

Möglichkeit, sowohl die Speicher- als auch die virtuellen Ebenen durch Backend-Orchestrierung von ONTAP und VMware gleichzeitig zu verwalten, ohne dass virtuelle Server-Appliances (VSAs) bereitgestellt und gewartet werden müssen.

Applikationszentrierter Schutz für Kubernetes-Workloads mit derselben ONTAP SnapMirror Technologie und Trident Protect Orchestrierung. Ressourcentransformationen ermöglichen die Anpassung von Workloads an die Wiederherstellungsumgebung während des Failovers.

DR-Lösungen für VMware können ressourcenintensiv sein. Viele DR-Lösungen replizieren VMs auf der virtuellen VMware-Ebene mithilfe von VSAs, was mehr Rechenressourcen verbrauchen und zu einem Verlust der wertvollen Speichereffizienz von ONTAP führen kann. Da Disaster Recovery die ONTAP SnapMirror -Technologie verwendet, kann es mithilfe unseres inkrementellen Replikationsmodells mit allen nativen Datenkomprimierungs- und Deduplizierungseffizienzen von ONTAP Daten von Produktionsdatenspeichern zum DR-Standort replizieren.

Replizieren Sie VMware-Apps auf Ihrem lokalen Produktionsstandort mithilfe der SnapMirror -Replikation an einen Remote-Standort zur Notfallwiederherstellung in der Cloud oder vor Ort.

Kubernetes-Applikationen lassen sich mithilfe von SnapMirror Replikation und Trident Protect auf einen Ziel-Kubernetes-Cluster replizieren.

VMware-Workloads lassen sich von Ihrem ursprünglichen Standort zu einem anderen Standort migrieren. Eine Migration von Kubernetes-Workloads wird derzeit nicht unterstützt.

Es lässt sich ein Failover-Test durchführen. Für VMware Workloads erstellt der Dienst temporäre virtuelle Maschinen. Disaster Recovery erstellt aus dem ausgewählten Snapshot ein neues FlexClone Volume und ordnet den ESXi Hosts einen temporären Datastore zu, der auf dem FlexClone Volume basiert. Dieser Prozess verbraucht keine zusätzliche physische Kapazität auf lokalem ONTAP Storage oder FSx for NetApp ONTAP Storage in AWS. Das ursprüngliche Quellvolume wird nicht geändert, und Replikationsjobs können auch während der Disaster Recovery fortgesetzt werden. Auch das Failover von Kubernetes Workloads lässt sich testen, und die Testressourcen lassen sich anschließend bereinigen.

Im Katastrophenfall kann bei Bedarf ein Failover Ihres primären Standorts auf den Disaster-Recovery-Standort erfolgen. Bei VMware Workloads kann der Disaster-Recovery-Standort VMware Cloud on AWS mit Amazon FSx for NetApp ONTAP oder eine lokale VMware Umgebung mit ONTAP sein. Bei Kubernetes Workloads erfolgt das Failover auf den Ziel-Cluster im Replikationsplan.

Nachdem der Notfall behoben wurde, führen Sie bei Bedarf ein Failback vom Notfallwiederherstellungsstandort zum primären Standort durch.

VMs, Datastores oder Kubernetes-Ressourcen lassen sich zur effizienten Verwaltung in logische Ressourcengruppen zusammenfassen.

Bei Kubernetes-Workloads dienen Ressourcentransformationen dazu, Applikationen während eines Failover an die Wiederherstellungsumgebung anzupassen, und Pre-Snapshot- oder Post-Snapshot-Skripte managen die Applikationsstilllegung und -wiederaufnahme.

Melden Sie sich für eine 30-tägige kostenlose Testversion an.

Ein Pay-as-you-go (PAYGO)-Abonnement kann über den Amazon Web Services (AWS) Marketplace, den Azure Marketplace oder den Google Cloud Marketplace erworben werden. Diese Lizenz ermöglicht den Erwerb einer Lizenz mit fester, geschützter Kapazität ohne langfristige Verpflichtung.

Bringen Sie Ihre eigene Lizenz (BYOL) mit. Dabei handelt es sich um eine NetApp Lizenzdatei (NLF), die Sie von Ihrem NetApp Vertriebsmitarbeiter erhalten. Sie können die Seriennummer der Lizenz verwenden, um BYOL in der NetApp Console zu aktivieren.

Mit dem Dienst können Sie außerdem ein Failback virtueller Maschinen auf den ursprünglichen Quellspeicherort durchführen.

Sie können den Failover-Prozess für die Notfallwiederherstellung testen, ohne die ursprünglichen virtuellen Maschinen zu unterbrechen. Der Test stellt virtuelle Maschinen in einem isolierten Netzwerk wieder her, indem ein FlexClone des Volumes erstellt wird.

Für den Failover- oder Test-Failover-Prozess können Sie den neuesten (Standard) oder ausgewählten Snapshot auswählen, von dem aus Ihre virtuelle Maschine wiederhergestellt werden soll.

* NetApp Console*: Die Benutzeroberfläche zum Verwalten Ihrer Notfallwiederherstellungspläne. Mit der NetApp Console können Sie Replikationspläne, Ressourcengruppen und Failover-Vorgänge in Ihren lokalen und Cloud-Umgebungen erstellen und verwalten.

Console agent: Eine schlanke Softwarekomponente, die in Ihrem Cloud-gehosteten Netzwerk oder Ihrer lokalen VMware-Umgebung ausgeführt wird. Er kommuniziert mit der NetApp Console und managt die Datenreplikation zwischen Ihrer lokalen Umgebung und dem Disaster-Recovery-Standort. Der Console agent ist auf einer virtuellen Maschine in Ihrer VMware-Umgebung installiert. Für Kubernetes-Workloads kommuniziert der Console agent auf dieselbe Weise mit Ihren Kubernetes-Clustern.

ONTAP Storage-Cluster: Die ONTAP Storage-Cluster sind die primären Storage-Systeme, auf denen Ihre VMware- und Kubernetes-Workloads gehostet werden. Die ONTAP Storage-Cluster stellen die zugrunde liegende Storage-Infrastruktur für Ihre Disaster-Recovery-Pläne bereit. Disaster Recovery verwendet ONTAP Storage APIs, um ONTAP Storage-Cluster wie lokale Arrays und Cloud-basierte Lösungen wie Amazon FSx for NetApp ONTAP zu managen.

vCenter-Server: Das VMware vCenter ist der Verwaltungsserver für Ihre VMware-Umgebung. Es verwaltet die ESXi-Hosts und die zugehörigen Datenspeicher. Der Konsolenagent kommuniziert mit dem VMware vCenter, um die Datenreplikation zwischen Ihrer lokalen Umgebung und dem Notfallwiederherstellungsstandort zu verwalten. Dazu gehört das Registrieren von ONTAP -LUNs und -Volumes als Datenspeicher, das Neukonfigurieren von VMs sowie das Starten und Stoppen von VMs.

Kubernetes Cluster und Trident Protect: Für Kubernetes Workloads wird Trident Protect auf jedem Kubernetes Cluster installiert und registriert, der durch Disaster Recovery geschützt wird. Beim Hinzufügen eines Kubernetes Clusters als Standort führt Disaster Recovery durch die Installation und Registrierung von Trident Protect auf diesem Cluster.

NFS-Datenspeicher, die auf ONTAP FlexVol -Volumes gehostet werden, die sich auf ONTAP Clustern befinden.

VMware vSphere Virtual Machine File System (VMFS)-Datenspeicher mit dem iSCSI- oder FC-Protokoll

VMware Cloud (VMC) auf AWS mit Amazon FSx for NetApp ONTAP

Eine weitere lokale, NFS-basierte VMware-Umgebung mit ONTAP Storage oder eine lokale FC/iSCSI VMFS-Umgebung

Amazon Elastic VMware Service

Azure VMware Solution mit NetApp Cloud Volumes ONTAP (iSCSI) (Private Preview)

Google Cloud VMware Engine (GCVE) mit Google Cloud NetApp Volumes

Kubernetes-Cluster mit von Trident verwaltetem ONTAP Storage (geschützt mit Trident Protect)

Datenspeicher: Ein VMware vCenter-Datencontainer, der ein Dateisystem zum Speichern von VMDK-Dateien verwendet. Typische Datenspeichertypen sind NFS, VMFS, vSAN oder vVol. Disaster Recovery unterstützt NFS- und VMFS-Datenspeicher. Jeder VMware-Datenspeicher wird auf einem einzelnen ONTAP Volume oder LUN gehostet. Disaster Recovery unterstützt NFS- und VMFS-Datenspeicher, die auf FlexVol Volumes gehostet werden, die sich auf ONTAP Clustern befinden.

Replikationsplan: Ein Satz von Regeln darüber, wie oft Sicherungen durchgeführt werden und wie mit Failover-Ereignissen umgegangen wird. Pläne werden einer oder mehreren Ressourcengruppen zugewiesen.

Recovery Point Objective (RPO): Der maximale Datenverlust, der im Katastrophenfall akzeptabel ist. RPO wird in der Häufigkeit der Datenreplikation oder im Replikationszeitplan des Replikationsplans definiert.

Wiederherstellungszeitziel (RTO): Die maximal akzeptable Zeitspanne für die Wiederherstellung nach einem Katastrophenfall. Das RTO ist im Replikationsplan definiert und entspricht der Zeit, die für ein Failover zum DR-Standort und den Neustart aller VMs oder Applikationen benötigt wird.

Ressourcengruppe: Ein logischer Container, mit dem Sie mehrere VMs, Datastores oder Kubernetes-Ressourcen als eine Einheit managen können. Eine VM kann jeweils nur einer Ressourcengruppe angehören. Sie können für jede Applikation oder jeden Workload, den Sie schützen möchten, eine eigene Ressourcengruppe erstellen.

Site: Ein logischer Container, der typischerweise mit einem physischen Datacenter oder Cloud-Standort verbunden ist und einen oder mehrere vCenter Cluster oder Kubernetes-Cluster sowie ONTAP Storage beherbergt.

AppVault: Für Kubernetes-Workloads ein Cloud-Storage-Ziel, auf dem Trident Protect Kubernetes-Schutzdaten speichert.

Trident Protect: Die NetApp Software, die Disaster Recovery zum Schutz von Kubernetes-Applikationen verwendet.