Allgemeine Fragen: Hyper-V-Notfallwiederherstellung in Azure

Dieser Artikel enthält Antworten auf häufig gestellte Fragen zum Replizieren lokaler Hyper-V-VMs zu Azure.

Allgemein

Wie werden Site Recovery-Preise kalkuliert?

Nähere Informationen finden Sie unter Site Recovery – Preise.

Wie zahle ich für Azure-VMs?

Während der Replikation werden Daten zu Azure-Speicher repliziert, und Sie bezahlen keine VM-Änderungen. Wenn Sie einen Failover zu Azure ausführen, erstellt Site Recovery automatisch Azure-IaaS-VMs. Danach werden Ihnen die Computeressourcen in Rechnung gestellt, die Sie in Azure nutzen.

Gibt es einen Kostenunterschied bei der Replikation zu einem Speicherkonto vom Typ „Allgemein v2“?

Normalerweise treten erhöhte Transaktionskosten bei GPv2-Speicherkonten auf, da viele Transaktionen über Azure Site Recovery durchgeführt werden. Erfahren Sie mehr, um die Änderung einschätzen zu können.

Kann Site Recovery bei reservierten Instanzen verwendet werden?

Ja. Sie können reservierte Azure-VMs in der Region für die Notfallwiederherstellung erwerben, die dann von den Site Recovery-Failovervorgängen verwendet werden. Es ist keine zusätzliche Konfiguration erforderlich.

Azure

Was benötige ich in Hyper-V, um die Replikation mit Site Recovery zu orchestrieren?

Was Sie für Hyper-V-Hostserver benötigen, richtet sich nach dem Bereitstellungsszenario. Sehen Sie sich die Voraussetzungen für Hyper-V an:

Kann ich virtuelle Computer schützen, wenn Hyper-V auf einem Clientbetriebssystem ausgeführt wird?

Nein. VMs müssen sich auf einem Hyper-V-Hostserver befinden, der auf einem unterstützten Windows-Servercomputer ausgeführt wird. Wenn Sie einen Clientcomputer schützen müssen, können Sie diesen als physischen Computer in Azure oder in einem sekundären Rechenzentrum replizieren.

Müssen Hyper-V-Hosts sich in VMM-Clouds befinden?

Wenn Sie die Replikation in einem sekundären Rechenzentrum durchführen möchten, müssen Hyper-V-VMs auf Hyper-V-Hostservern in einer VMM-Cloud angeordnet sein. Falls Sie in Azure replizieren möchten, können Sie virtuelle Computer mit oder ohne VMM-Clouds replizieren. Weitere Informationen zur Hyper-V-Replikation in Azure.

Kann ich virtuelle Hyper-V-Computer der 2. Generation in Azure replizieren?

Ja. Während des Failovers konvertiert Site Recovery Computer der 2. Generation in die 1. Generation. Beim Failback werden die Computer wieder in die 2. Generation zurückkonvertiert. Weitere Informationen.

Kann ich Site Recovery mit VMM bereitstellen, wenn ich nur über einen VMM-Server verfüge?

Ja. Sie können VMs auf Hyper-V-Servern in der VMM-Cloud in Azure replizieren, oder Sie können zwischen VMM-Clouds auf demselben Server replizieren. Für die Replikation „lokal zu lokal“ empfehlen wir Ihnen, sowohl am primären Standort als auch am sekundären Standort jeweils einen VMM-Server zu verwenden.

Was muss ich in Azure tun?

Sie benötigen ein Azure-Abonnement, einen Recovery Services-Tresor, ein Speicherkonto und ein virtuelles Netzwerk. Tresor, Speicherkonto und Netzwerk müssen sich in derselben Region befinden.

Welches Azure-Speicherkonto benötige ich?

Sie benötigen ein LRS- oder GRS-Speicherkonto. Wir empfehlen Ihnen die Verwendung von GRS, damit Resilienz für die Daten besteht, wenn es zu einem regionalen Ausfall kommt oder wenn die primäre Region nicht wiederhergestellt werden kann. Storage Premium wird unterstützt.

Benötigt mein Azure-Konto Berechtigungen zum Erstellen von virtuellen Computern?

Wenn Sie ein Abonnementadminstrator sind, besitzen Sie die erforderlichen Replikationsberechtigungen. Wenn nicht, benötigen Sie Berechtigungen zum Erstellen einer Azure-VM in der Ressourcengruppe und dem virtuellen Netzwerk, die Sie beim Konfigurieren von Site Reocvery angeben, und Schreibberechtigungen für das ausgewählte Speicherkonto. Weitere Informationen

Werden Replikationsdaten an Site Recovery gesendet?

Nein. Site Recovery fängt replizierte Daten nicht ab und besitzt keine Informationen dazu, was auf Ihren virtuellen Computern ausgeführt wird. Replikationsdaten werden zwischen Hyper-V-Hosts und Azure-Speicher ausgetauscht. Site Recovery hat keine Möglichkeit, diese Daten abzufangen. Nur die Metadaten, die zum Orchestrieren von Replikation und Failover erforderlich sind, werden an den Site Recovery-Dienst gesendet.

Site Recovery ist nach ISO 27001:2013, 27018, HIPAA und DPA zertifiziert und durchläuft gerade die Prüfungen für SOC2 und FedRAMP JAB.

Können wir lokale Metadaten innerhalb einer geografischer Region halten?

Ja. Wenn Sie einen Tresor in einer Region erstellen, stellen wir sicher, dass alle von Site Recovery verwendeten Metadaten innerhalb der geografischen Begrenzung der Region bleiben.

Verschlüsselt Site Recovery die Replikation?

Ja, sowohl Verschlüsselung bei der Übertragung als auch Verschlüsselung in Azure wird unterstützt.

Bereitstellung

Was kann ich mit der Hyper-V-zu-Azure-Replikation tun?

  • Notfallwiederherstellung: Sie können die vollständige Notfallwiederherstellung einrichten. In diesem Szenario replizieren Sie lokale Hyper-V-VMs zu Azure-Speicher:
    • Sie können VMs in Azure replizieren. Wenn Ihre lokale Infrastruktur nicht verfügbar ist, führen Sie ein Failover zu Azure aus.
    • Wenn Sie ein Failover ausführen, werden Azure-VMs aus replizierten Daten erstellt. Sie können auf Apps und Workloads auf den Azure-VMs zugreifen.
    • Wenn Ihr lokales Datencenter wieder verfügbar ist, können Sie ein Failback von Azure zu Ihrem lokalen Standort ausführen.
  • Migration: Sie können mit Site Recovery lokale Hyper-V-VMs zum Azure-Speicher migrieren. Dann führen Sie ein Failover vom lokalen Standort zu Azure aus. Nach dem Failover sind Ihre Apps und Workloads verfügbar und werden auf virtuellen Azure-Computern ausgeführt.

Was benötige ich lokal?

Sie benötigen eine oder mehrere VMs, die auf einem oder mehreren eigenständigen oder gruppierten Hyper-V-Hosts ausgeführt werden. Sie können auch VMs replizieren, die auf von System Center Virtual Machine Manager (VMM) verwalteten Hosts ausgeführt werden.

  • Wenn VMM nicht ausgeführt wird, sammeln Sie während der Bereitstellung von Site Recovery Hyper-V-Hosts und -Cluster in Hyper-V-Standorten. Installieren Sie die Site Recovery-Agents (den Azure Site Recovery-Anbieter und den Recovery Services-Agent) auf allen Hyper-V-Computern.
  • Wenn sich die Hyper-V-Hosts in einer VMM-Cloud befinden, orchestrieren Sie die Replikation in VMM. Installieren Sie den Site Recovery-Anbieter auf dem VMM-Server und den Recovery Services-Agent auf allen Hyper-V-Computern. Stellen Sie eine Zuordnung zwischen logischen Netzwerken für VMM/VM-Netzwerken und Azure-VNets her.
  • Erfahren Sie mehr über die Hyper-V-zu-Azure-Architektur.

Kann ich VMs, die sich in einem Hyper-V-Cluster befinden, replizieren?

Ja, Site Recovery unterstützt gruppierte Hyper-V-Hosts. Beachten Sie dabei Folgendes:

  • Alle Knoten des Clusters müssen beim selben Tresor registriert werden.
  • Wenn Sie VMM nicht verwenden, müssen alle Hyper-V-Hosts im Cluster derselben Hyper-V-Site hinzugefügt werden.
  • Installieren Sie den Azure Site Recovery-Anbieter und den Recovery Services-Agent auf allen Hyper-V-Hosts im Cluster, und fügen Sie alle Hosts einer Hyper-V-Site hinzu.
  • Im Cluster müssen keine bestimmten Schritte ausgeführt werden.
  • Wenn Sie das Bereitstellungsplanertool für Hyper-V ausführen, werden vom Tool die Profildaten dazu gesammelt, welcher Knoten ausgeführt wird, sowie dazu, wo die VM ausgeführt wird. Vom Tool können keine Daten zu einem deaktivierten Knoten gesammelt werden. Dieser wird jedoch überwacht. Sobald der Knoten betriebsbereit ist, beginnt das Tool mit dem Sammeln der VM-Profildaten (sofern die VM Teil der VM-Profilliste ist und auf dem Knoten ausgeführt wird).
  • Wenn eine VM auf einem Hyper-V-Host in einem Site Recovery-Tresor zu einem anderen Hyper-V-Host im selben Cluster oder zu einem eigenständigen Host migriert wird, hat dies keine Auswirkung auf die Replikation für die VM. Der Hyper-V-Host muss bestimmte Voraussetzungen erfüllen und in einem Site Recovery-Tresor konfiguriert werden.

Kann ich virtuelle Computer schützen, wenn Hyper-V auf einem Clientbetriebssystem ausgeführt wird?

Nein. VMs müssen sich auf einem Hyper-V-Hostserver befinden, der auf einem unterstützten Windows-Servercomputer ausgeführt wird. Wenn Sie einen Clientcomputer schützen müssen, können Sie diesen als physischen Computer in Azure replizieren.

Kann ich virtuelle Hyper-V-Computer der 2. Generation in Azure replizieren?

Ja. Während des Failovers konvertiert Site Recovery Computer der 2. Generation in die 1. Generation. Beim Failback werden die Computer wieder in die 2. Generation zurückkonvertiert.

Kann ich Site Recovery-Szenarien mit einem SDK automatisieren?

Ja. Sie können Site Recovery-Workflows mithilfe von REST-API, PowerShell oder Azure SDK automatisieren. Derzeit unterstützte Szenarios für die Replikation von Hyper-V zu Azure mithilfe von PowerShell:

Replikation

Zu welchem Speicher werden lokale virtuelle Computer repliziert?

Daten werden zu Azure-Speicher repliziert. Wenn Sie ein Failover zu Azure ausführen, erstellt Site Recovery automatisch Azure-VMs aus dem Speicherkonto.

Welche Apps kann ich replizieren?

Sie können jede App oder Arbeitsauslastung, auf einer Hyper-V-VM ausführen, die mit den Replikationsanforderungen kompatibel ist. Site Recovery bietet Unterstützung für die anwendungsorientierte Replikation, sodass für Apps ein Failover und ein Failback zum „intelligenten Zustand“ ausgeführt werden kann. Site Recovery kann in Microsoft-Anwendungen wie SharePoint, Exchange, Dynamics, SQL Server und Active Directory integriert werden. Zudem kann Site Recovery eng in die Produkte führender Anbieter wie Oracle, SAP, IBM und Red Hat eingebunden werden. Erfahren Sie mehr über den Schutz von Workloads.

Was ist ein Replikationsprozess?

  1. Wenn die erste Replikation ausgelöst wird, wird eine Hyper-V-Momentaufnahme für den virtuellen Computer erstellt.
  2. Virtuelle Festplatten auf der VM werden nacheinander repliziert, bis alle in Azure kopiert wurden. Die Dauer ist abhängig von der Größe der VM und von der Netzwerkbandbreite. Erfahren Sie, wie die Netzwerkbandbreite vergrößert werden kann.
  3. Falls während der ersten Replikation Datenträgeränderungen auftreten, werden die Änderungen mit dem Replication Tracker für Hyper-V-Replikate in Form von Hyper-V-Replikationsprotokollen (.hrl) nachverfolgt. Diese Protokolldateien befinden sich im gleichen Ordner wie die Datenträger. Jeder Datenträger verfügt über eine zugeordnete HRL-Datei, die an den sekundären Speicher gesendet wird. Beachten Sie, dass die Momentaufnahme- und Protokolldateien Festplattenressourcen belegen, während die anfängliche Replikation durchgeführt wird.
  4. Nach Abschluss der ersten Replikation wird die Momentaufnahme des virtuellen Computers gelöscht.
  5. Alle Datenträgeränderungen im Protokoll werden synchronisiert und mit dem übergeordneten Datenträger zusammengeführt.
  6. Nach Abschluss der ersten Replikation wird der Auftrag „Schutz auf dem virtuellen Computer abschließen“ ausgeführt. Er konfiguriert Einstellungen für das Netzwerk und andere Einstellungen für die Zeit nach der Replikation, sodass die VM geschützt ist.
  7. In dieser Phase können Sie die Einstellungen der VM überprüfen, um sicherzustellen, dass sie bereit für das Failover ist. Sie können einen Notfallwiederherstellungsdrill (Testfailover) für die VM ausführen, um zu überprüfen, ob das Failover wie erwartet ausgeführt wird.
  8. Nach der ersten Replikation beginnt die Deltareplikation gemäß der Replikationsrichtlinie.
  9. Änderungen werden in HRL-Dateien protokolliert. Jedem für die Replikation konfigurierten Datenträger ist eine HRL-Datei zugeordnet.
  10. Das Protokoll wird an das Speicherkonto des Kunden gesendet. Beim Übermitteln eines Protokolls an Azure werden Änderungen am primären Datenträger in einer anderen Protokolldatei im gleichen Ordner nachverfolgt.
  11. Während der Erst- und der Deltareplikation können Sie die VM im Azure-Portal überwachen.

Erfahren Sie mehr zum Replikationsprozess.

Kann ich über ein Site-to-Site-VPN zu Azure replizieren?

Azure Site Recovery repliziert Daten über einen öffentlichen Endpunkt in ein Azure Storage-Konto oder verwaltete Datenträger. Die Replikation kann jedoch auch über ein Site-to-Site-VPN ausgeführt werden. Die Site-to-Site-VPN-Konnektivität ermöglicht Organisationen, vorhandene Netzwerke mit Azure oder Azure-Netzwerken miteinander zu verbinden. Site-to-Site-VPN erfolgt über IPSec-Tunneling über das Internet, wobei vorhandene lokale Edgenetzwerkgeräte und Netzwerk-Appliances in Azure genutzt werden, z. B. native Funktionen wie Azure Virtual Private Network (VPN) Gateway oder Optionen von Drittanbietern wie Check Point CloudGaurd, Palo Alto NextGen Firewall. Das Replizieren auf Azure mit Standort-zu-Standort-VPN-Verbindung wird nur unterstützt, wenn private Endpunkte verwendet werden.

Warum kann ich nicht über VPN replizieren?

Wenn Sie nach Azure replizieren, erreicht der Replikationsdatenverkehr die öffentlichen Endpunkte eines Azure Storage-Kontos. Daher kann die Replikation über das öffentliche Internet nur mit ExpressRoute (Microsoft-Peering) erfolgen und VPN funktioniert nicht.

Welche Anforderungen stellt die Replikation an virtuelle Computer?

Für die Replikation muss auf einer Hyper-V-VM ein unterstütztes Betriebssystem ausgeführt werden. Darüber hinaus muss der virtuelle Computer die Anforderungen für Azure-VMs erfüllen. Erfahren Sie mehr in der Unterstützungsmatrix.

Warum ist ein zusätzliches Storage Standard-Konto erforderlich, wenn ich meine VM-Datenträger in Storage Premium repliziere?

Wenn Sie Ihre lokalen virtuellen Computer/physischen Server in Storage Premium replizieren, werden alle Daten auf den Datenträgern des geschützten Computers im Storage Premium-Konto repliziert. Zum Speichern von Replikationsprotokollen ist ein zusätzliches Storage Standard-Konto erforderlich. Nachdem die Anfangsphase der Replikation von Datenträgerdaten abgeschlossen ist, werden alle Änderungen an den Daten der lokalen Datenträger kontinuierlich nachverfolgt und als Replikationsprotokolle in diesem zusätzlichen Standard Storage-Konto gespeichert.

Wie oft kann ich zu Azure replizieren?

Hyper-V-VMs können alle 30 Sekunden (außer bei Storage Premium) oder alle 5 Minuten repliziert werden.

Können Azure Site Recovery und das Hyper-V-Replikat auf einem Hyper-V-Computer gleichzeitig konfiguriert werden?

Ja, Azure Site Recovery und das Hyper-V-Replikat können zusammen für einen Computer konfiguriert werden. Der Computer muss jedoch als physischer Computer geschützt werden und wird mithilfe eines Konfigurations-/Prozessservers in Azure repliziert. Weitere Informationen zum Schützen physischer Computer finden Sie hier.

Kann ich die Replikation erweitern?

Eine erweiterte oder verkettete Replikation wird nicht unterstützt. Fordern Sie dieses Feature im Feedbackforum.

Kann ich eine erste Offlinereplikation durchführen?

Dies wird nicht unterstützt. Fordern Sie dieses Feature im Feedbackforum.

Kann ich Datenträger ausschließen?

Ja, sie können Datenträger von der Replikation ausschließen.

Kann ich virtuelle Computer mit dynamischen Datenträgern replizieren?

Dynamische Datenträger können repliziert werden. Der Betriebssystem-Datenträger muss ein Basisdatenträger sein.

Kann ich Site Recovery zusammen mit anderen Sicherungs- oder Notfallwiederherstellungstools aktivieren?

Nein, das Aktivieren von Site Recovery zusammen mit anderen Sicherungs- oder Notfallwiederherstellungsressourcen auf demselben Hostcomputer wird nicht unterstützt. Die anderen Tools können Ressourcen, die für einen reibungslosen Betrieb von Site Recovery erforderlich sind, sperren. Dies kann dazu führen, dass die fortlaufende Replikation unterbrochen wird.

Sicherheit

Welchen Zugriff auf Hyper-V-Hosts benötigt Site Recovery?

Site Recovery benötigt Zugriff auf Hyper-V-Hosts, um die VMs zu replizieren, die Sie auswählen. Folgendes wird von Site Recovery auf Hyper-V-Hosts installiert:

  • Wenn Sie VMM nicht ausführen, werden der Site Recovery-Anbieter und der Recovery Services-Agent auf allen Hosts installiert.
  • Wenn Sie VMM ausführen, wird der Recovery Services-Agent auf allen Hosts installiert. Der Anbieter wird auf dem VMM-Server ausgeführt.

Was wird von Site Recovery auf Hyper-V-VMs installiert?

Von Site Recovery wird nichts explizit auf Hyper-V-VMs installiert, die für die Replikation aktiviert sind.

Failover und Failback

Wie führe ich ein Failover zu Azure aus?

Sie können ein geplantes oder ungeplantes Failover von lokalen Hyper-V-VMs zu Azure ausführen.

  • Wenn Sie ein geplantes Failover durchführen, werden die Quell-VMs heruntergefahren, um sicherzustellen, dass kein Datenverlust auftritt.
  • Sie können ein ungeplantes Failover ausführen, wenn kein Zugriff auf Ihren primären Standort möglich ist.
  • Sie können ein Failover für einen einzelnen Computer ausführen oder Wiederherstellungspläne erstellen, um das Failover von mehreren Computern zu orchestrieren.
  • Das Failover besteht aus zwei Teilen:
    • Nachdem die erste Phase des Failovers abgeschlossen ist, sollten Sie die erstellten Replikat-VMs in Azure sehen können. Sie können der VM bei Bedarf eine öffentliche IP-Adresse zuweisen.
    • Anschließend führen Sie ein Commit für das Failover durch, um von der Replikat-VM in Azure auf die Workload zuzugreifen.

Wie greife ich nach einem Failover auf virtuelle Azure-Computer zu?

Nach einem Failover können Sie über eine sichere Internetverbindung, eine Site-to-Site-VPN-Verbindung oder über Azure ExpressRoute auf die Azure-VMs zugreifen. Sie müssen eine Reihe von Vorbereitungen treffen, um eine Verbindung herzustellen. Weitere Informationen

Sind Daten, mit denen ein Failover ausgeführt wurde, stabil?

Azure ist auf Resilienz ausgelegt. Site Recovery ist für ein Failover zu einem sekundären Azure-Rechenzentrum (gemäß Azure-SLA) konzipiert. Wenn ein Failover auftritt, stellen wir sicher, dass Ihre Metadaten und Tresore innerhalb der gleichen geografischen Region bleiben, die Sie für Ihren Tresor ausgewählt haben.

Erfolgt ein Failover automatisch?

Ein Failover erfolgt nicht automatisch. Sie initiieren Failover mit einem Mausklick im Portal, oder Sie können PowerShell verwenden, um ein Failover auszulösen.

Wie führe ich ein Failback aus?

Sobald Ihre lokale Infrastruktur wieder funktioniert und ausgeführt werden kann, können Sie ein Failback ausführen. Das Failback erfolgt in drei Phasen:

  1. Starten Sie ein geplantes Failover von Azure zum lokalen Standort. Hierzu haben Sie verschiedene Möglichkeiten:

    • Weniger Ausfallzeiten: Wenn Sie diese Option verwenden, synchronisiert Site Recovery Daten vor dem Failover. und überprüft auf geänderte Datenblocks. Diese werden dann an den lokalen Standort heruntergeladen, während die Azure-VM weiterhin ausgeführt wird und die Downtime minimiert. Wenn Sie manuell angeben, dass das Failover abgeschlossen werden soll, wird die Azure-VM heruntergefahren, endgültige Deltaänderungen werden kopiert und das Failover startet.
    • Vollständiger Download: Bei dieser Option werden Daten während des Failovers synchronisiert. Mit dieser Option wird der gesamte Datenträger heruntergeladen. Dies erfolgt schneller, da keine Prüfsummen berechnet werden. Jedoch kommt es zu mehr Downtime. Verwenden Sie diese Option, wenn Sie die Azure-Replikat-VMs für einige Zeit ausgeführt haben oder die lokale VM gelöscht wurde.
  2. Sie können wählen, ob Sie das Failback zur gleichen VM oder zu einer alternativen VM ausführen. Sie können angeben, dass Site Recovery die VM erstellen sollte, wenn sie nicht bereits vorhanden ist.

  3. Nach Beendigung der Erstsynchronisierung wählen Sie aus, dass das Failover abgeschlossen werden soll. Sobald es abgeschlossen ist, können Sie sich bei der lokalen VM anmelden, um zu überprüfen, ob alles wie erwartet funktioniert. Im Azure-Portal können Sie sehen, dass die Azure-VMs angehalten wurden.

  4. Committen Sie das Failover, um es abzuschließen, und greifen wieder von der lokalen VM auf die Workload zu.

  5. Nachdem Failbacks für die Workloads ausgeführt wurden, aktivieren Sie die umgekehrte Replikation, sodass die lokalen VMs erneut in Azure replizieren.

Kann ich ein Failback zu einem anderen Speicherort ausführen?

Ja, wenn Sie ein Failover zu Azure ausgeführt haben, können Sie ein Failback zu einem anderen Speicherort ausführen, wenn der ursprüngliche nicht verfügbar ist. Weitere Informationen