Beheben von Problemen bei der Replikation von VMware-VMs und physischen Servern

  • Artikel

Dieser Artikel beschreibt einige häufig auftretende Probleme und bestimmte Fehler bei der Replikation von lokalen VMware-VMs und physischen Servern in Azure mithilfe von Site Recovery.

Schritt 1: Überwachen der Integrität des Prozessservers

Site Recovery verwendet den Prozessserver, um replizierte Daten zu empfangen, zu optimieren und an Azure zu senden.

Wir empfehlen, dass Sie die Integrität von Prozessservern im Portal überwachen, um sicherzustellen, dass sie verbunden sind und ordnungsgemäß funktionieren, und dass die Replikation für die dem Prozessserver zugeordneten Quellcomputer fortschreitet.

  • Erfahren Sie mehr zur Überwachung von Prozessservern.
  • [Bewährte Methoden überprüfen].(vmware-physical-azure-troubleshoot-process-server.md#best-practices-for-process-server-deployment)
  • Problembehandlung bei der Integrität des Prozessservers

Schritt 2: Problembehandlung bei Konnektivität und Replikation

Konnektivitätsprobleme zwischen dem Quellserver und dem Prozessserver oder zwischen dem Prozessserver und Azure führen häufig zu anfänglichen und fortlaufenden Replikationsfehlern.

Informationen zum Beheben dieser Probleme finden Sie unter Problembehandlung der Konnektivität und Replikation.

Schritt 3: Problembehandlung bei Quellcomputern, die für die Replikation nicht zur Verfügung stehen

Wenn Sie versuchen, den Quellcomputer auszuwählen, um Replikation mithilfe von Site Recovery zu aktivieren, steht der Computer möglicherweise aus einem der folgenden Gründe nicht zur Verfügung:

  • Zwei VMs mit derselben Instanz-UUID: Wenn zwei VMs im vCenter dieselbe Instanz-UUID haben, wird die erste vom Konfigurationsserver ermittelte VM im Azure-Portal angezeigt. Um dieses Problem zu beheben, stellen Sie sicher, dass keine zwei virtuellen Computer über dieselbe Instanz-UUID verfügen. Dieses Szenario tritt häufig in Instanzen auf, bei denen ein virtueller Sicherungscomputer aktiv und in unseren Ermittlungsdatensätzen protokolliert wird. Informationen zum Beheben dieses Problems finden Sie unter Azure Site Recovery VMware-zu-Azure: Bereinigen von doppelten oder veralteten Einträgen.
  • Falsche vCenter-Benutzeranmeldeinformationen: Stellen Sie sicher, dass Sie während der Einrichtung des Konfigurationsservers mithilfe der OVF-Vorlage oder des einheitlichen Setups die richtigen vCenter-Anmeldeinformationen hinzugefügt haben. Informationen zum Überprüfen der Anmeldeinformationen, die Sie während der Einrichtung hinzugefügt haben, finden Sie unter Ändern der Anmeldeinformationen für die automatische Ermittlung.
  • Unzureichende vCenter-Berechtigungen: Wenn die für den Zugriff auf vCenter bereitgestellten Berechtigungen nicht die erforderlichen Berechtigungen umfassen, kann die Ermittlung von virtuellen Computern möglicherweise fehlschlagen. Stellen Sie sicher, dass die unter Vorbereiten eines Kontos für die automatische Ermittlung beschriebenen Berechtigungen dem vCenter-Benutzerkonto hinzugefügt werden.
  • Azure Site Recovery-Verwaltungsserver: Wenn die VM als Verwaltungsserver in mindestens einer der folgenden Rollen – Konfigurationsserver, horizontal skalierender Prozessserver, Masterzielserver – verwendet wird, dann können Sie die VM im Portal nicht auswählen. Verwaltungsserver können nicht repliziert werden.
  • Bereits geschützt/Failover durch Azure Site Recovery-Dienste ausgeführt: Wenn der virtuelle Computer bereits mithilfe von Site Recovery geschützt wird bzw. ein Failover dafür ausgeführt wurde, steht er nicht mehr zur Auswahl für den Schutz im Portal zur Verfügung. Stellen Sie sicher, dass der gesuchte virtuelle Computer im Portal noch nicht von einem anderen Benutzer oder unter einem anderen Abonnement geschützt wurde.
  • vCenter nicht verbunden: Überprüfen Sie, ob sich vCenter im verbundenen Status befindet. Dazu wechseln Sie zu Recovery Services-Tresor > Site Recovery-Infrastruktur > Konfigurationsserver > Auf den jeweiligen Konfigurationsserver klicken > auf der rechten Seite wird ein Blatt mit Details zu zugeordneten Servern geöffnet. Überprüfen Sie, ob vCenter verbunden ist. Wenn es sich im Status „Nicht verbunden“ befindet, beheben Sie das Problem, und dann aktualisieren Sie den Konfigurationsserver im Portal. Danach ist die VM im Portal nicht aufgeführt.
  • ESXi ausgeschaltet: Wenn der ESXi-Host, auf dem sich die VM befindet, ausgeschaltet ist, ist die VM im Azure-Portal nicht aufgeführt oder kann nicht ausgewählt werden. Schalten Sie den ESXi-Host ein, und aktualisieren Sie den Konfigurationsserver im Portal. Danach wird die VM im Portal aufgeführt.
  • Ausstehender Neustart: Wenn auf der VM ein Neustart aussteht, können Sie den Computer im Azure-Portal nicht auswählen. Schließen Sie die ausstehenden Neustartaktivitäten ab, und aktualisieren Sie den Konfigurationsserver. Danach wird die VM im Portal aufgeführt.
  • IP nicht gefunden oder Computer hat keine IP-Adresse:: Wenn der VM keine gültige IP-Adresse zugeordnet ist, dann können Sie den Computer im Azure-Portal nicht auswählen. Weisen Sie der VM eine gültige IP-Adresse zu, und aktualisieren Sie den Konfigurationsserver. Es kann auch verursacht werden, wenn der Computer keine gültige IP-Adresse hat, die einer seiner NICs zugeordnet ist. Weisen Sie entweder allen NICs eine gültige IP-Adresse zu, oder entfernen Sie die NIC, der keine IP-Adresse zugewiesen ist. Danach wird der virtuelle Computer im Portal aufgeführt.

Problembehandlung – geschützte virtuelle Computer im Portal grau dargestellt

Virtuelle Computer, die unter Site Recovery repliziert werden, sind im Azure-Portal nicht verfügbar, wenn doppelte Einträge im System vorhanden sind. Erfahren Sie mehr über das Löschen von veralteten Einträgen und die Lösung des Problems.

Ein weiterer Grund könnte sein, dass der Computer geklont wurde. Wenn Computer zwischen einem Hypervisor wechseln und sich die BIOS-ID ändert, dann blockiert der Mobilitäts-Agent die Replikation. Die Replikation geklonter Computer wird von Site Recovery nicht unterstützt.

In den letzten „XXX“ Minuten stand kein absturzkonsistenter Wiederherstellungspunkt für die VM zur Verfügung

Im Folgenden finden Sie eine Liste der häufigsten Probleme:

Probleme bei der Erstreplikation [Fehler 78169]

Stellen Sie sicher, dass es keine Probleme im Zusammenhang mit Konnektivität, Bandbreite oder Zeitsynchronisierung gibt, und stellen Sie zusätzlich Folgendes sicher:

  • Azure Site Recovery wird von keiner Antivirensoftware blockiert. Erfahren Sie mehr zu Ordnerausschlüssen, die für Azure Site Recovery erforderlich sind.

Quellcomputer mit hoher Änderungsrate [Fehler 78188]

Mögliche Ursachen:

  • Die Änderungsrate der Daten (geschriebene Byte/Sekunde) auf den aufgelisteten Datenträgern der VM übersteigt die unterstützten Grenzwerte von Azure Site Recovery für den Typ des Speicherkontos des Replikationsziels.
  • Es gibt eine Spitze im Churn, weshalb für große Mengen an Daten der Upload aussteht.

So lösen Sie das Problem:

  • Stellen Sie sicher, dass der Typ des Zielspeicherkontos (Standard oder Premium) den Churn-Anforderungen der Quelle entsprechend bereitgestellt wird.

  • Wenn Sie bereits auf einen verwalteten Premium-Datenträger (vom Typ „asrseeddisk“) replizieren, stellen Sie sicher, dass die Größe des Datenträgers die beobachtete Änderungsrate gemäß den Site Recovery-Grenzwerten unterstützt. Sie können die Größe von „asrseeddisk“ wenn nötig erhöhen. Folgen Sie diesen Schritten:

    • Navigieren Sie zum Blatt „Datenträger“ des betroffenen replizierten Computers, und kopieren Sie den Replikatdatenträgernamen.
    • Navigieren Sie zu diesem verwalteten Replikatdatenträger.
    • Auf dem Blatt „Übersicht“ wird möglicherweise ein Banner angezeigt, das besagt, dass eine SAS-URL generiert wurde. Klicken Sie auf dieses Banner, und brechen Sie den Export ab. Ignorieren Sie diesen Schritt, wenn das Banner nicht angezeigt wird.
    • Nachdem die SAS-URL widerrufen wurde, wechseln Sie zum Blatt Konfiguration des verwalteten Datenträgers und vergrößern diesen so, dass Azure Site Recovery den beobachteten Churn auf dem Quelldatenträger unterstützt.

  • Wenn der beobachtete Churn nur vorrübergehend ist, warten Sie einige Stunden, bis der anstehende Daten-Upload aufgeholt hat, und erstellen Sie Wiederherstellungspunkte.

  • Wenn der Datenträger unkritische Daten wie temporäre Protokolle, Testdaten usw. enthält, erwägen Sie, diese Daten an einen anderen Ort zu verschieben oder diesen Datenträger komplett von der Replikation auszuschließen

  • Wenn das Problem weiterhin besteht, können Sie die Replikation mithilfe des Bereitstellungsplaners von Site Recovery planen.

Quellcomputer ohne Heartbeat [Fehler 78174]

Dieser Fehler tritt auf, wenn der Azure Site Recovery-Mobility-Agent auf dem Quellcomputer mit dem Konfigurationsserver kommuniziert.

Führen Sie die folgenden Schritte durch, um die Netzwerkverbindung zwischen der Quell-VM und dem Konfigurationsserver zu überprüfen:

  1. Stellen Sie sicher, dass der Quellcomputer ausgeführt wird.

  2. Melden Sie sich beim Quellcomputer mit einem Administratorkonto an.

  3. Stellen Sie sicher, dass die folgenden Dienste ausgeführt werden. Wenn diese nicht ausgeführt werden, starten Sie sie neu.

    • Svagents (InMage Scout VX-Agent)
    • InMage Scout-Anwendungsdienst

  4. Sehen Sie sich die Fehlerdetails in den Protokollen an folgendem Speicherort auf dem Quellcomputer an:

    C:\Program Files (X86)\Microsoft Azure Site Recovery\agent\svagents.log

Prozessserver ohne Heartbeat [Fehler 806]

Wenn es keinen Heartbeat vom Prozessserver gibt, überprüfen Sie Folgendes:

  1. Die Prozessserver-VM ist aktiv und wird ausgeführt.

  2. Überprüfen Sie die folgenden Protokolle auf dem Prozessserver auf Fehlerdetails:

    C:\ProgramData\ASR\home\svsystems\eventmanager*.log
    und
    C:\ProgramData\ASR\home\svsystems\monitor_protection*.log

Masterzielserver ohne Heartbeat [Fehler 78022]

Dieser Fehler tritt auf, wenn der Azure Site Recovery-Mobility-Agent auf dem Masterziel nicht mit dem Konfigurationsserver kommuniziert.

Führen Sie zur Problembehebung die folgenden Schritte durch, um den Dienststatus zu überprüfen:

  1. Stellen Sie sicher, dass die Masterziel-VM ausgeführt wird.
  2. Melden Sie sich bei der Masterziel-VM mit einem Administratorkonto an.

    • Stellen Sie sicher, dass der svagents-Dienst ausgeführt wird. Wird der Dienst ausgeführt, starten Sie Ihn neu.

    • Sehen Sie sich die Fehlerdetails in den Protokollen an folgendem Speicherort an:

      C:\Program Files (X86)\Microsoft Azure Site Recovery\agent\svagents.log

  3. Navigieren Sie zum Registrieren des Masterziels beim Konfigurationsserver zu Ordner %PROGRAMDATA%\ASR\Agent, und führen Sie Folgendes an der Eingabeaufforderung aus: 
    cmd
cdpcli.exe --registermt

net stop obengine

net start obengine

exit

Der Schutz konnte für den virtuellen Computer nicht erfolgreich aktiviert werden. [Fehler 78253]

Dieser Fehler kann auftreten, wenn dem Konfigurationsserver eine Replikationsrichtlinie nicht ordnungsgemäß zugeordnet wurde. Er kann auch auftreten, wenn die dem Konfigurationsserver zugeordnete Richtlinie ungültig ist.

Um die Ursache dieses Fehlers zu finden, navigieren Sie zum Wiederherstellungstresor > verwalten Sie Site Recovery Infrastruktur, und zeigen Sie dann die Replikationsrichtlinien für VMware und physische Computer an, um die Status der konfigurierten Richtlinien zu überprüfen.

Um das Problem zu beheben, können Sie die Richtlinie dem verwendeten Konfigurationsserver zuordnen oder eine neue Replikationsrichtlinie erstellen und ihm zuordnen. Wenn die Richtlinie ungültig ist, können Sie die Zuordnung aufheben und löschen.

Fehler-ID 78144: In den letzten „XXX“ Minuten stand kein anwendungskonsistenter Wiederherstellungspunkt für den virtuellen Computer zur Verfügung.

Es wurden Verbesserungen an den Versionen 9.23 und 9.27 von Mobility Agent vorgenommen, um das Verhalten bei VSS-Installationsfehlern zu optimieren. Stellen Sie sicher, dass Sie die neuesten Versionen verwenden, um eine optimale Anleitung zur Fehlerbehebung bei VSS-Fehlern zu erhalten.

Einige der häufigsten Probleme sind hier aufgeführt:

Ursache 1: Bekanntes Problem in SQL Server 2008/2008 R2

Lösung: Es gibt ein bekanntes Problem mit SQL Server 2008/2008 R2. Weitere Informationen finden Sie in diesem KB-Artikel: Fehler bei Azure Site Recovery-Agent oder einer anderen komponentenfreien VSS-Sicherung für einen Server, der SQL Server 2008 R2 hostet.

Ursache 2: Azure Site Recovery-Aufträge schlagen auf Servern fehl, die eine beliebige Version von SQL Server-Instanzen mit AUTO_CLOSE DBs hosten

Lösung: Siehe Artikel in der Wissensdatenbank

Lösung: Siehe Wissensdatenbank-Artikel

Ursache 3: Bekanntes Problem in SQL Server 2016 und 2017

Lösung: Siehe Artikel in der Wissensdatenbank

Ursache 4: App-Konsistenz ist auf Linux-Servern nicht aktiviert

Lösung: Azure Site Recovery für Linux-Betriebssysteme unterstützt benutzerdefinierte Anwendungsskripts für App-Konsistenz. Das benutzerdefinierte Skript mit „Pre“- und „Post“-Optionen wird vom Mobilitäts-Agent von Azure Site Recovery für die App-Konsistenz verwendet. Die Schritte für die Aktivierung finden Sie hier.

Überprüfen Sie zur weiteren Problembehandlung die Dateien auf dem Quellcomputer, um den genauen Fehlercode zu erhalten:

C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\ApplicationPolicyLogs\vacp.log

Wie können die Fehler in der Datei gefunden werden? Suchen Sie nach der Zeichenfolge „vacpError“, indem Sie die Datei „vacp.log“ in einem Editor öffnen.

Ex: vacpError:220#Following disks are in FilteringStopped state [\\.\PHYSICALDRIVE1=5, ]#220|^|224#FAILED: CheckWriterStatus().#2147754994|^|226#FAILED to revoke tags.FAILED: CheckWriterStatus().#2147754994|^|

Im obigen Beispiel ist 2147754994 der Fehlercode, der Sie über den Fehler informiert, wie hier dargestellt:

VSS Writer ist nicht installiert – Fehler 2147221164

Lösung: Azure Site Recovery verwendet den Microsoft-Volumeschattenkopie-Dienst (VSS), um ein Tag für die Anwendungskonsistenz zu erstellen. Es installiert einen VSS-Anbieter für den Betrieb, um Momentaufnahmen zur Anwendungskonsistenz zu erstellen. Dieser VSS-Anbieter wird als Dienst installiert. Falls der VSS-Anbieterdienst nicht installiert ist, tritt bei der Erstellung der Momentaufnahme zur Anwendungskonsistenz ein Fehler mit der ID „0x80040154“ auf – „Klasse nicht registriert“.

Weitere Informationen finden Sie im Artikel zur Problembehandlung bei der VSS Writer-Installation.

VSS Writer ist deaktiviert – Fehler 2147943458

Lösung: Azure Site Recovery verwendet den Microsoft-Volumeschattenkopie-Dienst (VSS), um ein Tag für die Anwendungskonsistenz zu erstellen. Es installiert einen VSS-Anbieter für den Betrieb, um Momentaufnahmen zur Anwendungskonsistenz zu erstellen. Dieser VSS-Anbieter wird als Dienst installiert. Falls der VSS-Anbieterdienst deaktiviert ist, tritt bei der Erstellung der Momentaufnahme zur Anwendungskonsistenz ein Fehler mit der ID „0x80070422“ auf – „Der angegebene Dienst ist deaktiviert und kann nicht gestartet werden“.

  • Wenn VSS deaktiviert ist:
    • Stellen Sie sicher, dass der Starttyp des VSS-Anbieterdiensts auf Automatic (Automatisch) festgelegt ist.
    • Starten Sie die folgenden Dienste neu:
      • VSS-Dienst
      • Azure Site Recovery-VSS-Anbieter
      • VDS-Dienst

VSS PROVIDER NOT_REGISTERED – Fehler 2147754756

Lösung: Azure Site Recovery verwendet den Microsoft-Volumeschattenkopie-Dienst (VSS), um ein Tag für die Anwendungskonsistenz zu erstellen. Überprüfen Sie, ob der Azure Site Recovery VSS-Anbieterdienst installiert ist.

  • Wiederholen Sie die Installation des Anbieters mit den folgenden Befehlen:
  • Vorhandenen Anbieter deinstallieren: C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Uninstall.cmd
  • Neuinstallation von: C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd

Stellen Sie sicher, dass der Starttyp des VSS-Anbieterdiensts auf Automatic (Automatisch) festgelegt ist. – Starten Sie die folgenden Dienste neu: – VSS-Dienst – Azure Site Recovery-VSS-Anbieter – VDS-Dienst

Fehler-ID 95001: Unzureichende Berechtigungen

Dieser Fehler tritt auf, wenn Sie versuchen, die Replikation zu aktivieren und die Anwendungsordner nicht über ausreichende Berechtigungen verfügen.

Lösung: Um dieses Problem zu beheben, stellen Sie sicher, dass der IUSR-Benutzer über die Rolle „Besitzer“ für alle folgenden Ordner verfügt –

  • C\ProgramData\Microsoft Azure Site Recovery\private
  • Das Installationsverzeichnis. Wenn das Installationsverzeichnis z. B. das F-Laufwerk ist, dann stellen Sie die richtigen Berechtigungen bereit für:
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems
  • Den Ordner \pushinstallsvc im Installationsverzeichnis. Wenn das Installationsverzeichnis z. B. das F-Laufwerk ist, stellen Sie die richtigen Berechtigungen bereit für –
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc
  • Den Ordner \etc im Installationsverzeichnis. Wenn das Installationsverzeichnis z. B. das F-Laufwerk ist, stellen Sie die richtigen Berechtigungen bereit für –
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\etc
  • C:\Temp
  • C:\thirdparty\php5nts
  • Für alle Elemente im folgenden Pfad –
    • C:\thirdparty\rrdtool-1.2.15-win32-perl58\rrdtool\Release*

Behandeln von Problemen mit Zeitänderungen auf replizierten Servern

Dieser Fehler tritt auf, wenn sich die Zeit des Quellcomputers vorwärts und dann innerhalb kurzer Zeit zurückbewegt, um die Änderung zu korrigieren. Möglicherweise wird die Änderung nicht bemerkt, da die Zeit schnell korrigiert wird.

Lösung: Um dieses Problem zu beheben, warten Sie, bis die Systemzeit die verzerrte zukünftige Zeit überschreitet. Eine weitere Option besteht darin, die Replikation zu deaktivieren und erneut zu aktivieren. Dies funktioniert nur für die vorwärtsgerichtete Replikation (Daten, die von einem lokalen System auf Azure repliziert werden) und nicht für die umgekehrte Replikation (Daten, die von Azure auf einem lokalen System repliziert werden).

Nächste Schritte

Wenn Sie weitere Hilfe benötigen, können Sie Ihre Frage auf der Microsoft Q&A-Seite für Azure Site Recovery stellen. Unsere Community ist sehr aktiv, und einer unserer Techniker kann Sie bei Ihrem Problem unterstützen.