Aktivieren des VM-Schutzes in Azure Site Recovery
Sobald das Ziel und die Quellumgebungen konfiguriert sind, können Sie mit dem Aktivieren des Schutzes von VMs (von der Quelle bis zum Ziel) beginnen. Die gesamte Konfiguration erfolgt in der Zielumgebung im Site Recovery Tresor selbst.
Voraussetzungen
Sie können die Replikationsrichtlinie für die jeweiligen VMs konfigurieren, die Sie im Site Recovery Tresor schützen möchten. Diese virtuellen Computer befinden sich in der Quellumgebung, in der sie eine bestimmte Ressourcengruppenstruktur, virtuelle Netzwerke, öffentliche IP-Adressen und NSGs konfiguriert haben.
Site Recovery hilft beim Replizieren aller VM-Daten selbst. Stellen Sie jedoch sicher, dass die folgenden Voraussetzungen erfüllt sind:
Die Zielnetzwerkkonnektivität ist konfiguriert.
Die virtuellen Zielnetzwerke werden konfiguriert, wobei alle geschützten VMs verbunden sind, wenn ein Failover auftritt.
Das Zielbenutzerabonnement verfügt über genügend Computekontingentzuteilung für alle VMs, die Sie möglicherweise für ein Failover planen.
Diese virtuellen Netzwerke können auf die gleiche Weise wie die Quellnetzwerke konfiguriert werden, oder sie können je nach Plan und Ziel der Notfallwiederherstellung einen anderen Entwurf haben.
Stellen Sie sicher, dass die neuen öffentlichen und privaten IP-Adressen für die spezifischen Workloads, die Sie schützen, wie erwartet funktionieren (wenn Failover auftreten, verfügen die VMs mit Failovern über IP-Adressen aus der Zielumgebung).
Die gewünschte Ressourcengruppenkonfiguration wird erstellt.
Beim Konfigurieren der Replikation können Sie auch die Ressourcengruppen erstellen, aber für eine Produktionsumgebung sollten Sie sie gemäß Ihrer Benennungsrichtlinie und -struktur vorab erstellen.
Stellen Sie sicher, dass die richtige RBAC zugewiesen ist und das Tagging aktiviert ist – alles gemäß Ihrer Unternehmensrichtlinie.
Das "Cachespeicherkonto" wird erstellt und ist verfügbar.
Das "Cachespeicherkonto" ist ein temporäres Speicherkonto, das im Replikationsprozess verwendet wird.
Hinweis
Der Umfang dieses Speicherkontos ist komplex, und im Artikel Planen der Kapazität für die Notfallwiederherstellung von Hyper-V-V-Computern werden diese Konzepte erläutert. Informationen zu Azure Site Recovery in Azure Stack Hub finden Sie im Artikel Kapazitätsplanung.
Aktivieren der Replikation
Öffnen Sie in der Zielumgebung im Azure Stack Hub-Benutzerportal den Site Recovery-Tresor, und wählen Sie Workloads schützen aus:
Wählen Sie die von Ihnen konfigurierte Anwendung aus, und überprüfen Sie, ob sie fehlerfrei ist:
Auf dem Blatt werden Sie dann aufgefordert, die Quellumgebung und das Quellabonnement auszuwählen. Sie sollten alle Azure Stack Hub-Benutzerabonnements sehen, auf die der von Ihnen konfigurierte Benutzer (oder SPN) Zugriff hat.
Wählen Sie das Abonnement aus, das die Quellworkloads enthält, und wählen Sie die VMs aus, für die Sie den Schutz aktivieren möchten. Sie können bis zu 10 VMs gleichzeitig schützen. PowerShell-Skripts sind verfügbar, die größere Bereitstellungen ermöglichen können.
Azure Site Recovery repliziert alle Datenträger, die an den virtuellen Computer angefügt sind. In dieser Version sind alle Datenträger geschützt.
Wählen Sie im nächsten Schritt die Konfiguration der Zielumgebung aus. Diese Konfiguration umfasst die Netzwerke, mit dem die VMs eine Verbindung herstellen, und das Cachespeicherkonto, das sie verwenden. Sie müssen PowerShell verwenden, um die Replikationsrichtlinie zu konfigurieren. Es stehen Skripts zur Verfügung, mit denen der Anpassungsprozess gestartet werden kann.
Überprüfen Sie die ausgewählte Konfiguration, und aktivieren Sie die Replikation:
Überprüfen des Replikationsstatus und Bearbeiten von Einstellungen
Im Site Recovery-Tresor werden auf dem Blatt Replizierte Elemente alle VMs angezeigt, für die Sie die Replikation aktiviert haben:
Wenn Sie diese Elemente auswählen, können Sie den aktuellen Status anzeigen, die Einstellungen dieses geschützten Elements bearbeiten oder Aktionen wie ein Testfailover auslösen:
Grundlegendes zu den verschiedenen Zuständen für geschützte VMs
Sobald ein virtueller Computer geschützt und Daten repliziert wurden, können Sie weitere Aufgaben ausführen:
Ausführen eines Testfailovers:
- Sie können ein Testfailover ausführen, um Ihre Replikations- und Notfallwiederherstellungsstrategie zu überprüfen, ohne dass Daten verloren gehen oder Ausfallzeiten auftreten. Ein Testfailover hat keinerlei Auswirkungen auf die laufende Replikation oder Ihre Produktionsumgebung. Sie können ein Testfailover auf einer bestimmten VM oder auf einem Wiederherstellungsplan ausführen, der mehrere VMs enthält.
Ein Testfailover simuliert das Failover dieser VM (von der Quelle zum Ziel), indem die Ziel-VM erstellt wird. Beim Ausführen eines Testfailovers können Sie Folgendes auswählen:
Der Wiederherstellungspunkt, auf den ein Failover ausgeführt werden soll:
- Neuester Wiederherstellungspunkt (niedrigster RPO): Diese Option verarbeitet zunächst alle Daten, die an den Site Recovery-Dienst gesendet wurden, um einen Wiederherstellungspunkt für jeden virtuellen Computer zu erstellen, bevor ein Failover darauf ausgeführt wird. Diese Option stellt die niedrigste RPO (Recovery Point Objective) bereit, da auf der nach dem Failover erstellten VM alle Daten in Site Recovery repliziert werden, wenn das Failover ausgelöst wird.
- Zuletzt verarbeitet (niedrigste RTO): Führt ein Failover aller VMs im Plan auf den neuesten Wiederherstellungspunkt durch, der von Site Recovery verarbeitet wird. Um den letzten Wiederherstellungspunkt für eine bestimmte VM zu finden, überprüfen Sie Letzte Wiederherstellungspunkte in den Einstellungen der VM. Diese Option bietet eine niedrige Recovery Time Objective (RTO), da keine Zeit für die Verarbeitung unverarbeiteter Daten aufgewendet wird.
- Neueste App-konsistent: Führt ein Failover aller VMs im Plan auf den neuesten anwendungskonsistenten Wiederherstellungspunkt durch, der von Site Recovery verarbeitet wird. Um den letzten Wiederherstellungspunkt für eine bestimmte VM zu finden, überprüfen Sie Letzte Wiederherstellungspunkte in den Einstellungen der VM.
- Benutzerdefiniert: Verwenden Sie diese Option, um ein Failover eines bestimmten virtuellen Computers auf einen bestimmten Wiederherstellungspunkt durchzuführen.
Sie können das Netzwerk zu diesem Zeitpunkt nicht auswählen. Das Testfailovernetzwerk ist für jede geschützte VM konfiguriert. Wenn Sie dies ändern müssen, wechseln Sie zurück zu den Eigenschaften des geschützten virtuellen Computers, und wählen Sie dann Anzeigen oder bearbeiten aus.
Das Testfailover kann dazu beitragen, das Anwendungsverhalten bei einem Failover zu überprüfen. Ihre Quell-VM wird jedoch möglicherweise noch ausgeführt. Sie müssen dieses Verhalten berücksichtigen, wenn Sie ein Testfailover ausführen.
Hinweis
Azure Site Recovery repliziert den virtuellen Computer vollständig, wenn ein Testfailover ausgeführt wird. Der virtuelle Computer wird in Quell- und Zielumgebungen ausgeführt. Sie müssen dies berücksichtigen, da sich dies auf das Verhalten Ihrer App auswirken kann.
Wenn das Testfailover abgeschlossen ist, können Sie Testfailover bereinigen auswählen. Diese Option löscht die Testfailover-VM und alle Testressourcen.
Failover:
Im Falle eines Problems in der Quellumgebung können Sie ein Failover für die VMs auf die Zielumgebung ausführen.
Wenn Sie den Failoverprozess starten, können Sie den Computer herunterfahren, bevor Sie mit dem Failover beginnen. Da diese Option den gesamten virtuellen Computer von der Quelle zum Ziel verschiebt, sollte die Quell-VM heruntergefahren werden, bevor Sie diese Option auswählen.
Hinweis
Wenn in den letzten 180 Tagen kein Testfailover durchgeführt wurde, empfiehlt Site Recovery, vor einem tatsächlichen Failover ein Failover durchzuführen. Das Überspringen der Validierung der Replikation per Testfailover kann zu Datenverlusten oder unvorhersehbaren Ausfallzeiten führen.
Nach Abschluss des Failoverprozesses müssen Sie die Änderungen committen, um den Failoverprozess vollständig abzuschließen. Wenn Sie nicht zuerst einen Commit ausführen, versuchen Sie erneut zu schützen, löst die Aktion zum erneuten Schützen zuerst einen Commit aus und setzt dann mit dem erneuten Schützen fort (daher dauert es länger, da beide Vorgänge erforderlich sind).
Nachdem die Quellumgebung wieder fehlerfrei ist, können Sie einen Failbackprozess starten. Dieser Prozess wird in zwei Schritten ausgeführt:
- Führen Sie erneut schützen aus, um mit der Replikation der Daten in der Quelle zu beginnen.
- Nachdem die Daten vollständig repliziert wurden, führen Sie die geplanter Failover aus, um die Ressource zurück in die ursprüngliche Umgebung zu verschieben.
Im folgenden Abschnitt finden Sie eine Liste der Überlegungen, die in jeder dieser Phasen erforderlich sind.
Hinweis
Derzeit wird das erneute Aktivieren des Schutzes (nach einem Failbackprozess) nicht unterstützt. Sie müssen den Schutz deaktivieren, den Agent entfernen und dann den Schutz für diesen virtuellen Computer erneut aktivieren. Dieser Prozess kann automatisiert werden, und wir stellen Skripts bereit, die Ihnen den Einstieg erleichtern.
Deinstallieren der Azure Site Recovery-VM-Erweiterung
Wenn Sie die Azure Site Recovery-Erweiterung deinstallieren, wird der Mobilitätsdienst, der auf dieser VM ausgeführt wird, nicht entfernt. Dies blockiert jeglichen zukünftigen Schutz und erfordert manuelle Schritte, um den Schutz für diese VM erneut zu aktivieren.
Nachdem Sie die Azure Site Recovery-VM-Erweiterung entfernt haben, müssen Sie den Mobilitätsdienst deinstallieren, der auf dieser VM ausgeführt wird. Lesen Sie hierzu die folgenden Schritte zum Deinstallieren Mobilitätsdienst.
Hinweis
Wenn Sie planen, den Schutz für diesen virtuellen Computer erneut zu aktivieren, stellen Sie nach der Ausführung der vorherigen Schritte sicher, dass Sie den virtuellen Computer neu starten, bevor Sie versuchen, den Schutz mithilfe von Azure Site Recovery hinzuzufügen.
Überlegungen
Die folgenden Informationen sind für normale Vorgänge nicht erforderlich. Diese Hinweise können Ihnen jedoch helfen, die Prozesse im Hintergrund besser zu verstehen.
Für jeden Status gibt es mehrere Überlegungen:
Erneutes Schützen:
Stellen Sie sicher, dass das ursprüngliche Quellabonnement, die anfängliche Ressourcengruppe und das virtuelle Netzwerk/Subnetz der ersten primären NIC weiterhin auf dem primären Stempel vorhanden sind. Sie können diese Informationen mithilfe von PowerShell aus dem geschützten Element abrufen:
Get-AzResource -ResourceID "/subscriptions/<subID>/resourceGroups/<RGname>/providers/Microsoft.DataReplication/replicationVaults/<vaultName>/protectedItems/<vmName>"Die folgende Abbildung zeigt die Beispielausgabe dieses Befehls:
Stellen Sie vor dem Ausführen des erneuten Schutzes für Linux-VMs sicher, dass das Zertifikat des Site Recovery-Diensts auf den Linux-VMs vertrauenswürdig ist, die Sie erneut schützen möchten. Diese Vertrauensstellung entsperrt die VM-Registrierung beim Site Recovery-Dienst, der erneut geschützt werden muss.
Für Ubuntu/Debian-VMs:
sudo cp /var/lib/waagent/Certificates.pem /usr/local/share/ca-certificates/Certificates.crt sudo update-ca-certificatesFür Red Hat-VMs:
sudo update-ca-trust force-enable sudo cp /var/lib/waagent/Certificates.pem /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust extractStellen Sie sicher, dass für die Site Recovery Anwendung VM genügend Datenträgerslots zur Verfügung stehen. Die Replikatdatenträger für den erneuten Schutz sind an die Anwendung angefügt (weitere Informationen finden Sie in der Kapazitätsplanung).
Während des erneuten Schutzvorgangs wird die Quell-VM (die die QuelleAzStackVirtualMachineId auf dem Quellstempel enthalten würde) heruntergefahren, sobald der erneute Schutz ausgelöst wird, und die daran angefügten Betriebssystemdatenträger und -datenträger werden getrennt und als Replikatdatenträger an die Anwendung angefügt, wenn es sich um die alten Datenträger handelt. Der Betriebssystemdatenträger wird durch einen temporären Betriebssystemdatenträger mit der Größe 1 GB ersetzt.
Auch wenn ein Datenträger als Replikat beim erneuten Schützen wiederverwendet werden kann, er sich jedoch in einem anderen Abonnement als der Anwendung VM befindet, wird aus diesem ein neuer Datenträger in demselben Abonnement und derselben Ressourcengruppe wie der Anwendung erstellt, sodass der neue Datenträger an den Anwendung angefügt werden kann.
Die angefügten Datenträger des Anwendung sollten nicht manuell geändert/angefügt/getrennt/geändert werden, da eine erneute manuelle Neusynchronisierung in der öffentlichen Vorschau nicht unterstützt wird (siehe Artikel bekannte Probleme). Der erneute Schutz kann nicht wiederhergestellt werden, wenn die Replikatdatenträger entfernt werden.
Failback (geplanter Failover): Failback eines erneut geschützten Elements vom Zielstempel auf den Quellstempel:
- Stellen Sie sicher, dass das ursprüngliche Quellabonnement, die anfängliche Ressourcengruppe und das virtuelle Netzwerk/Subnetz der ursprünglichen primären NIC weiterhin auf dem Quellstempel vorhanden sind. Sie können diese Informationen mithilfe von PowerShell aus dem geschützten Element abrufen.
- Die VM mit der SourceAzStackVirtualMachineId auf dem Quellstempel wird mit den Replikatdatenträgern und neu erstellten NICs erstellt, falls sie nicht vorhanden ist. oder es wird durch einen Replikatbetriebssystemdatenträger und datenträger ersetzt, sofern vorhanden.
- Wenn die VM mit der QuelleAzStackVirtualMachineId auf dem primären Stempel vorhanden ist, werden alle daran angefügten Datenträger getrennt, aber nicht gelöscht, und die NICs bleiben gleich.
- Wenn der virtuelle Computer mit der QuelleAzStackVirtualMachineId auf dem primären Stempel vorhanden ist und sich in einem anderen Abonnement als der Anwendung VM befindet, werden neue Datenträger in derselben Abonnement- und Ressourcengruppe erstellt wie die Failback-VM aus dem Replikat, die vom Anwendung getrennt ist, sodass die neuen Datenträger an die Failback-VM angefügt werden können.
Committen, dass das Failover/Failback abgeschlossen ist. Der failoverfähige virtuelle Computer auf dem Wiederherstellungsstempel wird gelöscht, nachdem das Failback committ wurde.
Wenn Sie den Azure Site Recovery-Ressourcenanbieter deinstallieren, werden auch alle Tresore entfernt, die in diesen Azure Stack Hub-Zielstempeln erstellt wurden. Dies ist eine Azure Stack Hub-Operatoraktion ohne Warnungen oder Warnungen für Benutzer, wenn dies geschieht.
