Wechseln von der klassischen zur modernisierten VMware-Notfallwiederherstellung
Erfahren Sie mehr über die Architektur, die erforderliche Infrastruktur und häufig gestellte Fragen zur Umstellung Ihrer VMware-Replikation oder der Replikation physischer Computer von der klassischen auf die modernisierte Schutzarchitektur. Mit dieser Funktion zum Migrieren können Sie Ihre replizierten Elemente erfolgreich von einem Konfigurationsserver in eine Azure Site Recovery-Replikationsappliance übertragen. Diese Migration wird von einem intelligenten Replikationsmechanismus gesteuert, wodurch sichergestellt wird, dass für nicht kritische replizierte Elemente nicht erneut eine vollständige Erstreplikation ausgeführt wird und nur die Differenzdaten übertragen werden.
Hinweis
Wiederherstellungspläne werden nicht migriert und müssen im modernisierten Recovery Services-Tresor erneut erstellt werden.
Aufbau
Die Komponenten, die an der Migration replizierter Elemente eines VMware- oder physischen Computers beteiligt sind, werden in der folgenden Tabelle zusammengefasst:
| Komponente | Anforderung |
|---|---|
| Replizierte Elemente in einem klassischen Recovery Services-Tresor | Mindestens ein repliziertes Element, das mithilfe der klassischen Architektur und eines fehlerfreien Konfigurationsservers geschützt wird. Das replizierte Element sollte sich in einem nicht kritischen Zustand befinden und muss vom lokalen Standort in Azure repliziert werden, wobei der Mobilitäts-Agent in Version 9.50 oder höher ausgeführt wird. |
| Von replizierten Elementen verwendeter Konfigurationsserver | Der von den replizierten Elementen verwendete Konfigurationsserver sollte sich in einem nicht kritischen Zustand befinden, und es sollte ein Upgrade seiner Komponenten auf die neueste Version (9.50 oder höher) ausgeführt worden sein. |
| Recovery Services-Tresor mit modernisierter Benutzeroberfläche | Ein Recovery Services-Tresor mit modernisierter Benutzeroberfläche. |
| Fehlerfreie Azure Site Recovery-Replikationsappliance | Eine nicht kritische Azure Site Recovery-Replikationsappliance, die lokale Computer entdecken kann und deren Komponenten alle auf die neueste Version (9.50 oder höher) aktualisiert wurden. Die genau erforderlichen Versionen werden im Folgenden aufgeführt: Prozessserver: 9.50 Proxyserver: 1.35.8419.34591 Recovery Services-Agent: 2.0.9249.0 Replikationsdienst: 1.35.8433.24227 |
Erforderliche Infrastruktur
Stellen Sie Folgendes sicher, um das replizierte Element erfolgreich zu verschieben:
- Recovery Services-Tresor mit modernisierter Benutzeroberfläche.
Hinweis
Bei jedem neu erstellten Recovery Services-Tresor ist standardmäßig die modernisierte Benutzeroberfläche aktiviert. Sie können nicht zur klassischen Benutzeroberfläche wechseln, da deren Einstellung bereits angekündigt wurde.
- Eine Azure Site Recovery-Replikationsappliance, die erfolgreich im Tresor registriert wurde, und alle zugehörigen Komponenten befinden sich in einem nicht kritischen Zustand.
- Die Version der Appliance muss 9.50 oder höher sein. Eine detaillierte Versionsbeschreibung finden Sie hier.
- Die Details des vCenter-Servers oder des vSphere-Hosts, auf dem sich die vorhandenen replizierten Computer befinden, werden der Appliance hinzugefügt, um eine erfolgreiche lokale Ermittlung zu gewährleisten.
Voraussetzungen
Vorbereiten der Infrastruktur
Stellen Sie Folgendes sicher, bevor Sie von der klassischen Architektur zur modernisierten Architektur wechseln:
- Erstellen Sie einen Recovery Services-Tresor, und stellen Sie sicher, dass die Benutzeroberfläche nicht auf klassisch umgeschaltet wurde.
- Stellen Sie eine Azure Site Recovery-Replikationsappliance bereit.
- Fügen Sie der Appliance die vCenter Server-Details des lokalen Computers hinzu, damit die Ermittlung erfolgreich ausgeführt wird.
Vorbereiten des klassischen Recovery Services-Tresors
Stellen Sie für die replizierten Elemente, die Sie verschieben möchten, Folgendes sicher:
- Das replizierte Element ist ein VMware-Computer oder ein physischer Computer, der über einen Konfigurationsserver repliziert wird.
- Die Replikation erfolgt nicht in ein nicht verwaltetes Speicherkonto, sondern auf einen verwalteten Datenträger.
- Die Replikation erfolgt vom lokalen Standort zu Azure, und das replizierte Element befindet sich nicht in einem Failover- oder Failbackzustand.
- Das replizierte Element repliziert die Daten nicht von Azure zum lokalen Standort.
- Die Erstreplikation wurde bereits vollständig abgeschlossen.
- Das replizierte Element befindet sich nicht im Zustand „Neusynchronisierung“.
- Die Version des Konfigurationsservers ist 9.50 oder höher, und seine Integrität befindet sich in einem nicht kritischen Zustand.
- Der Heartbeat des Konfigurationsservers ist fehlerfrei.
- Die Version des auf dem Quellcomputer installierten Mobilitätsdienst-Agents ist 9.50 oder höher.
- Recovery Services-Tresore mit aktivierter MSI werden unterstützt.
- Recovery Services-Tresore mit aktivierten privaten Endpunkten werden unterstützt.
- Die Integrität des replizierten Elements befindet sich in einem nicht kritischen Zustand, oder seine Wiederherstellungspunkte werden erfolgreich erstellt.
Vorbereiten des modernisierten Recovery Services-Tresors
Stellen Sie für das modernisierte Architektursetup Folgendes sicher:
- Der Recovery Services-Tresor, der für das modernisierte Architektursetup verwendet wird, befindet sich am selben geografischen Ort wie der klassische Tresor.
- Eine Azure Site Recovery-Replikationsappliance wird lokal mit Version 9.50 oder höher bereitgestellt.
- Die Appliance wird erfolgreich im Tresor registriert.
- Die Appliance und alle zugehörigen Komponenten befinden sich in einem nicht kritischen Zustand, und der Heartbeat der Appliance ist fehlerfrei.
- Die vCenter Server-Version wird von der modernisierten Architektur unterstützt.
- Die vCenter Server-Details des Quellcomputers werden der Appliance hinzugefügt.
- Die Version der Linux-Distribution wird von der modernisierten Architektur unterstützt. Weitere Informationen.
- Die Windows Server-Version wird von der modernisierten Architektur unterstützt. Weitere Informationen
Berechnen der Gesamtdauer der Verschiebung
Die Gesamtdauer der Verschiebung eines replizierten Elements aus dem klassischem Tresor in einen modernisierten Tresor hängt vom Replikationsstatus des Elements und der Datenträgergröße ab.
| State | Dauer der Migration in den modernisierten Tresor |
|---|---|
| Der Schutzstatus des replizierten Elements ist fehlerfrei, und der letzte Wiederherstellungspunkt wurde vor weniger als 50 Minuten erstellt. | Die Migration dauert 1–2 Stunden. |
| Der Schutzstatus des replizierten Elements ist nicht fehlerfrei, oder der letzte Wiederherstellungspunkt wurde vor mehr als 50 Minuten erstellt. | Die Migrationsdauer variiert und ist abhängig von der Datenträgergröße. |
Wenn Ihre Computer keinen fehlerfreien Schutzstatus aufweisen, berechnen Sie die genaue Migrationsdauer nach der unten stehenden Formel:
Migrationsdauer = 1 Stunde + 45 Sekunden/GiB
| Computerkonfiguration | Migrationsdauer |
|---|---|
| Ein Computer mit zwei Datenträgern mit je 256 GiB | ~ 4 Stunden 15 Min. [Beide Datenträger werden parallel migriert.] |
| 10 Computer mit jeweils zwei Datenträgern mit je 256 GiB | ~ 4 Stunden 15 Min. [Alle VMs und ihre Datenträger werden parallel migriert] |
| Ein Computer mit vier Datenträgern mit je 512 GiB | ~ 7 Stunden 30 Min. [Beide Datenträger werden parallel migriert.] |
| 10 Computer mit jeweils vier Datenträgern mit je 512 GiB | ~ 7 Stunden 30 Min. [Alle VMs und ihre Datenträger werden parallel migriert] |
Diese Formel dient zum Berechnen der Migrationsdauer und wird im Portal angezeigt.
Definieren der erforderlichen Infrastruktur
Beim Migrieren von Computern von der klassischen zur modernisierten Architektur müssen Sie sicherstellen, dass die erforderliche Infrastruktur bereits im modernisierten Recovery Services-Tresor registriert wurde. Definieren Sie die erforderliche Infrastruktur anhand der Größen- und Kapazitätsdetails der Replikationsappliance.
In der Regel sollte die Anzahl der eingerichteten Replikationsappliances der Anzahl der Prozessserver in Ihrem klassischen Recovery Services-Tresor entsprechen. Wenn also im klassischen Tresor ein Konfigurationsserver und vier Prozessserver vorhanden sind, sollten Sie vier Replikationsappliances im modernisierten Recovery Services-Tresor einrichten.
Preise
Die Site Recovery-Lizenzgebühr wird weiterhin für den klassischen Tresor berechnet, bis der Aufbewahrungszeitraum aller Wiederherstellungspunkte abgelaufen ist. Sobald alle Wiederherstellungspunkte bereinigt wurden, werden auch die Preise im klassischen Tresor deaktiviert. Nachdem der Aufbewahrungszeitraum aller Wiederherstellungspunkte abgelaufen ist, wird das replizierte Element automatisch über einen vom System ausgelösten Löschvorgang entfernt.
Site Recovery startet das Laden der Lizenzgebühr für replizierte Elemente im modernisierten Tresor erst, nachdem der erste Wiederherstellungspunkt generiert und der ältere Tresor bereinigt wurde. Wenn für den klassischen Tresor Tage eines kostenloser Testzeitraums ausstehen, werden dieselben Informationen an den modernisierten Tresor übergeben. Die Preise werden auf dem modernisierten Tresor erst nach Ablauf dieses Testzeitraums aktiviert.
Hinweis
Zu einem bestimmten Zeitpunkt werden die Preise nur auf einem Tresor aktiviert: entweder auf dem klassischen oder auf dem modernisierten Tresor.
Häufig gestellte Fragen
Warum sollte ich meine Computer zur modernisierten Architektur migrieren?
Wichtig: Die klassische Architektur für die Notfallwiederherstellung wird nach und nach außer Betrieb genommen, Benutzer*innen müssen also sicherstellen, dass sie zur neuesten modernisierten Version wechseln. Die folgende Tabelle enthält einen Vergleich der beiden Architekturen, um Ihnen bei der Auswahl der richtigen Option zum Schutz Ihrer Computer im Notfall zu helfen.
| Klassische Architektur | Modernisierte Architektur [Neu] |
|---|---|
| Mehrere Setups für die Ermittlung lokaler Daten erforderlich. | Zentrale Ermittlung des lokalen Rechenzentrums mithilfe des Ermittlungsdiensts. |
| Vielzahl von Schritten für anfängliches Onboarding erforderlich. | Vereinfachung des Onboarding durch Automatisierung der Artefakterstellung und Einführung von Standardeinstellungen zur Reduzierung erforderlicher Eingaben. |
| Verwendung einer manuell heruntergeladenen Datei zum Abrufen des Cloudkontexts. | Einführung des Replikationsschlüssels zum Abrufen des Cloudkontexts beim Einrichten der Appliance. |
| Vielzahl von Schritten für einfachen Replikationsaktivierungsprozess erforderlich. | Vereinfachung der Replikationsaktivierung durch Verringerung der erforderlichen Eingaben und Neudefinition jedes Blatts. |
| Konfigurationsserver ist weiterhin eine lokale Infrastruktur mit umfangreichem Setup für verschiedene Komponenten. | Verbesserung der Appliance durch Konvertierung aller Komponenten in Azure-gehostete Microservices. Dadurch werden Skalierung, Überwachung und Problembehandlung der Appliance vereinfacht. |
| Notwendigkeit eines horizontal skalierten Prozessservers und Masterzielservers auf Azure für Linux-Computern ist eine hindernde Anforderung. | Notwendigkeit der Verwaltung eines separaten Prozessservers und Masterzielserversentfällt. |
| Verwendung einer statischen Passphrase für die Authentifizierung steht mit der geschäftlichen Anforderung des Kunden an eine regelmäßige Kennwortrotation in Konflikt. | Einführung zertifikatbasierter Authentifizierung, die sicherer ist und die Sicherheitsbedenken des Kunden ausräumt. |
| Upgrades auf aktualisierte Versionen müssen manuell ausgeführt werden und sind umständlich. | Einführung automatischer Upgrades sowohl für Appliancekomponenten als auch für den Mobilitätsdienst. |
| Der Konfigurationsserver ist nicht auf hohe Verfügbarkeit ausgelegt, daher besteht die Gefahr eines Absturzes. | Implementierung hoher Applianceverfügbarkeit zur Gewährleistung der Ausfallsicherheit. |
| Stammanmeldeinformationen müssen regelmäßig aktualisiert werden, um fehlerfreie Upgrades sicherzustellen. | Verwaltung von Stammanmeldeinformationen des Computers entfällt für Ausführung automatischer Upgrades. |
| Statische IP-Adresse muss dem Konfigurationsserver zugewiesen werden, um die Konnektivität beizubehalten. | Einführung FQDN-basierter Konnektivität zwischen Appliance und lokalen Computern. |
| Nur dieses virtuelle Netzwerk, für das Site-to-Site-VPN oder Express Route aktiviert ist, sollte verwendet werden. | Notwendigkeit der Verwaltung von Site-to-Site-VPN oder Express Route entfällt für umgekehrte Replikation. |
| Das Drittanbietertool MySQL muss ebenfalls eingerichtet werden. | Die Abhängigkeit von Tools von Drittanbietern wurde entfernt. |
Welche Computer sollten zur modernisierten Architektur migriert werden?
Alle VMware- oder physischen Computer, die mithilfe eines Konfigurationsservers repliziert werden, sollten zur modernisierten Architektur migriert werden.
Wo sollte mein modernisierter Recovery Services-Tresor erstellt werden?
Der modernisierte Recovery Services-Tresor sollte sich in derselben Region und auf demselben Mandanten befinden wie der klassische Tresor. Er kann Teil einer beliebigen Abonnement- oder Ressourcengruppe sein.
Wird meine Replikation fortgesetzt, während die Migration erfolgt?
Nein, die Replikation wird für einige Zeit unterbrochen, während die Migration läuft. Während dieser Zeit steht Ihnen der zuletzt erstellte Wiederherstellungspunkt im klassischen Recovery Services-Tresor für ein Failover zur Verfügung. Sobald die Migration abgeschlossen ist, wird ein neuer Wiederherstellungspunkt im modernisierten Recovery Services-Tresor generiert.
Wann wird mein Migrationsvorgang als abgeschlossen gekennzeichnet?
Der Migrationsvorgang wird erst dann als abgeschlossen gekennzeichnet, wenn der erste Wiederherstellungspunkt im modernisierten Recovery Services-Tresor erfolgreich erstellt wurde.
Welche Vorgänge können über meinen klassischen Recovery Services-Tresor ausgeführt werden, nachdem die Migration erfolgt ist?
Nach der Migration können Sie über Ihren klassischen Tresor ein Failover ausführen. Der Failovervorgang ist im klassischen Tresor weiterhin verfügbar, bis die Wiederherstellungspunkte ablaufen.
Wenn beispielsweise der Aufbewahrungszeitraum für ein repliziertes Element 72 Stunden (drei Tage) beträgt, ist der neueste Wiederherstellungspunkt im klassischen Tresor nach einer erfolgreichen Migration weiterhin für 72 Stunden (drei Tage) verfügbar. Nach der festgelegten Zeit löst Azure Site Recovery automatisch einen Vorgang „Replikation bereinigen“ für das replizierte Element aus und bereinigt alle zugehörigen Speicher- und abrechnungsrelevanten Elemente.
Was geschieht, wenn mein Computer während des Migrationsvorgangs ausfällt?
Jedes replizierte Element, das migriert wird, kann weiterhin den Failovervorgang über den klassischen Recovery Services-Tresor unterstützen, bis der Aufbewahrungszeitraum für den letzten Wiederherstellungspunkt abgelaufen ist. Wenn Sie versuchen, einen Failovervorgang auszuführen, hat dieser Vorrang vor dem Migrationsvorgang, und der Migrationsauftrag wird abgebrochen. Um sicherzustellen, dass Ihr repliziertes Element migriert wird, müssen Sie den Migrationsvorgang zu einem späteren Zeitpunkt erneut auslösen.
Hinweis
Die Compute- und Netzwerkeigenschaften replizierter Elemente können aktualisiert werden, während die Migration ausgeführt wird. Die Änderungen werden jedoch möglicherweise nicht im modernisierten Recovery Services-Tresor repliziert.
Wie viele Computer auf einmal kann ich von einem klassischen zu einem modernisierten Tresor migrieren?
Über das Portal können Sie bis zu 10 Computer auf einmal migrieren.
Muss ich die virtuellen Netzwerke, Speicherkonten und Replikationsrichtlinien, die im neuen Tresor verwendet werden sollen, neu erstellen?
Nein, im modernisierten Tresor werden standardmäßig dieselben Ressourcen wie zuvor verwendet. Sie können diese immer über die Blätter Compute und Netzwerk Ihres replizierten Elements ändern. Sie müssen sicherstellen, dass die Ressourcen weiterhin über den erforderlichen Zugriff verfügen.
Wie werden meine Replikationsrichtlinien in den modernisierten Tresor verschoben?
Als Voraussetzung erstellt Site Recovery Replikationsrichtlinien im modernisierten Tresor, und zwar mit derselben Konfiguration wie im klassischen Tresor. Bevor also ein repliziertes Element verschoben wird, wird die zugehörige Richtlinie im modernisierten Tresor erstellt. Wir empfehlen, Änderungen an der Konfiguration von Replikationsrichtlinien im klassischen Tresor zu vermeiden, nachdem die Migration ausgelöst wurde, da diese Änderungen nicht im modernisierten Tresor widergespiegelt werden. Diese Änderungen sollten erfolgen, bevor der Migrationsprozess gestartet wird.
Der Name der Replikationsrichtlinie, die im modernisierten Tresor erstellt wird, wird im modernisierten Tresor geändert. Ihm wird der Name der Ressourcengruppe und der Tresorname des modernisierten Recovery Services-Tresors vorangestellt. Wenn der Richtlinienname im klassischen Tresor „default replication policy“ lautete, erhält die Richtlinie im modernisierten Tresor den Namen default replication policy contoso-modern-vault_contoso-rg (wenn der Tresorname „contoso-modern-vault“ lautet und die Ressourcengruppe des Tresors „contoso-rg“ heißt).
Kann ich meine Replikationsrichtlinie während oder nach der Migration im klassischen Tresor bearbeiten?
Wenn das Replikat einer Replikationsrichtlinie bereits im modernisierten Tresor erstellt wurde, werden alle Änderungen an der Richtlinie im klassischen Tresor nicht an den modernisierten Tresor verteilt.
Wenn also zehn replizierte Elemente vorhanden sind, die mithilfe einer Richtlinie repliziert werden, und Sie beschließen, fünf dieser Elemente in den modernisierten Tresor zu verschieben, wird eine Kopie der Richtlinie erstellt, bevor die Migration beginnt. Wenn vor der Migration der übrigen fünf Elemente Änderungen an der Richtlinie im klassischen Tresor vorgenommen werden, wird die Richtlinie im modernisierten Tresor nicht aktualisiert. Sie müssen diese Konfigurationsänderungen auch im modernisierten Tresor vornehmen.
Wie migriere ich replizierte Elemente, die in einer Replikationsgruppe (auch „Multi-VM-Konsistenzgruppen“ genannt) vorhanden sind?
Alle replizierten Elemente, die zu einer Replikationsgruppe gehören, werden zusammen migriert. Sie können alle Elemente auszuwählen, indem Sie die Replikationsgruppe auswählen, oder alle überspringen. Wenn der Migrationsprozess für einige Computer in einer Replikationsgruppe erfolgreich, aber für andere nicht erfolgreich ist, wird für die nicht replizierten Elemente ein Rollback in die klassische Version ausgeführt, und der Migrationsprozess kann für diese Elemente erneut ausgelöst werden.
Kann ich mein klassisches Setup mit öffentlichem Endpunkt zu einem modernisierten Setup mit privatem Endpunkt migrieren?
Nein, Sie können nur das klassische Notfallwiederherstellungssetup mit öffentlichem Endpunkt in das modernisierte Setup mit öffentlichem Endpunkt verschieben. Beachten Sie, dass die Migration von nicht privaten Endpunkten zu privaten Endpunkten nicht unterstützt wird, die Migration privater Endpunkte zu privaten Endpunkten wird jedoch unterstützt.