Dela via

Felsöka problem med replikering för virtuella VMware-datorer och fysiska servrar

  • Artikel

Den här artikeln beskriver några vanliga problem och specifika fel som kan uppstå när du replikerar lokala virtuella VMware-datorer och fysiska servrar till Azure med Hjälp av Site Recovery.

Steg 1: Övervaka processerverhälsa

Site Recovery använder processervern för att ta emot och optimera replikerade data och skicka dem till Azure.

Vi rekommenderar att du övervakar hälsotillståndet för processservrar i portalen för att säkerställa att de är anslutna och fungerar korrekt och att replikeringen fortsätter för de källdatorer som är associerade med processervern.

  • Lär dig mer om övervakningsprocessens servrar.
  • [Granska metodtips]. (vmware-physical-azure-troubleshoot-process-server.md#best-practices-for-process-server-deployment)
  • Felsöka processerverhälsa.

Steg 2: Felsöka anslutningsproblem och replikeringsproblem

Anslut ivitetsproblem mellan källservern och processervern eller mellan processervern och Azure orsakar ofta inledande och pågående replikeringsfel.

Du kan lösa dessa problem genom att felsöka anslutning och replikering.

Steg 3: Felsöka källdatorer som inte är tillgängliga för replikering

När du försöker välja källdatorn för att aktivera replikering med hjälp av Site Recovery kanske datorn inte är tillgänglig av någon av följande orsaker:

  • Två virtuella datorer med samma instans UUID: Om två virtuella datorer under vCenter har samma UUID-instans visas den första virtuella datorn som identifieras av konfigurationsservern i Azure-portalen. Lös problemet genom att se till att inga två virtuella datorer har samma UUID-instans. Det här scenariot visas ofta i instanser där en virtuell säkerhetskopieringsdator blir aktiv och loggas in i våra identifieringsposter. Se Azure Site Recovery VMware-to-Azure: Så här rensar dubbletter eller inaktuella poster som ska matchas.
  • Felaktiga autentiseringsuppgifter för vCenter-användare: Kontrollera att du har lagt till rätt vCenter-autentiseringsuppgifter när du konfigurerar konfigurationsservern med hjälp av OVF-mallen eller en enhetlig konfiguration. Information om hur du verifierar de autentiseringsuppgifter som du lade till under installationen finns i Ändra autentiseringsuppgifter för automatisk identifiering.
  • otillräcklig behörighet för vCenter: Om de behörigheter som ges för att komma åt vCenter inte har de behörigheter som krävs kan det hända att det inte går att identifiera virtuella datorer. Se till att de behörigheter som beskrivs i Förbereda ett konto för automatisk identifiering läggs till i vCenter-användarkontot.
  • Azure Site Recovery-hanteringsservrar: Om den virtuella datorn används som en hanteringsserver under en eller flera av följande roller – Konfigurationsserver/utskalningsprocessserver/Huvudmålserver kan du inte välja den virtuella datorn från portalen. Det går inte att replikera hanteringsservrar.
  • Redan skyddat/redväxla via Azure Site Recovery-tjänster: Om den virtuella datorn redan är skyddad eller redväxla via Site Recovery är den virtuella datorn inte tillgänglig för att välja skydd i portalen. Se till att den virtuella dator som du letar efter i portalen inte redan skyddas av någon annan användare eller under en annan prenumeration.
  • vCenter är inte anslutet: Kontrollera om vCenter är i ett anslutet tillstånd. Kontrollera genom att gå till Recovery Services-valvet > Site Recovery Infrastructure > Configuration Servers > Klicka på respektive konfigurationsserver > ett blad öppnas till höger med information om associerade servrar. Kontrollera om vCenter är anslutet. Om det är i tillståndet "Inte Anslut ed" löser du problemet och uppdaterar sedan konfigurationsservern på portalen. Därefter visas inte den virtuella datorn i portalen.
  • ESXi avstängd: Om ESXi-värden där den virtuella datorn finns är i ett avaktiverat tillstånd visas inte den virtuella datorn eller kan inte väljas på Azure-portalen. Starta ESXi-värden och uppdatera konfigurationsservern på portalen. Därefter visas den virtuella datorn i portalen.
  • Väntar på omstart: Om det finns en väntande omstart på den virtuella datorn kan du inte välja datorn på Azure-portalen. Se till att slutföra väntande omstartsaktiviteter och uppdatera konfigurationsservern. Därefter visas den virtuella datorn i portalen.
  • DET gick inte att hitta IP-adressen eller så har datorn ingen IP-adress: Om den virtuella datorn inte har någon giltig IP-adress associerad med den kan du inte välja datorn på Azure-portalen. Se till att tilldela en giltig IP-adress till den virtuella datorn och uppdatera konfigurationsservern. Det kan också orsakas om datorn inte har en giltig IP-adress som är associerad med någon av dess nätverkskort. Tilldela antingen en giltig IP-adress till alla nätverkskort eller ta bort det nätverkskort som saknar IP-adressen. Därefter visas den virtuella datorn i portalen.

Felsöka skyddade virtuella datorer som är nedtonade i portalen

Virtuella datorer som replikeras under Site Recovery är inte tillgängliga i Azure-portalen om det finns duplicerade poster i systemet. Läs mer om att ta bort inaktuella poster och lösa problemet.

En annan orsak kan vara att datorn klonades. När datorer flyttas mellan ett hypervisor-nätverk och om BIOS-ID ändras blockerar mobilitetsagenten replikeringen. Replikering av klonade datorer stöds inte av Site Recovery.

Ingen kraschkonsekvent återställningspunkt tillgänglig för den virtuella datorn under de senaste XXX-minuterna

Följande är en lista över några av de vanligaste problemen:

Inledande replikeringsproblem [fel 78169]

Utöver att se till att det inte finns några anslutningsproblem, bandbredd eller tidssynkroniseringsrelaterade problem kontrollerar du att:

  • Inget antivirusprogram blockerar Azure Site Recovery. Läs mer om mappundantag som krävs för Azure Site Recovery.

Källdatorer med hög omsättning [fel 78188]

Möjliga orsaker:

  • Dataändringshastigheten (skrivbyte per sekund) på de listade diskarna på den virtuella datorn är mer än gränserna för lagringskontotypen för replikeringsmål i Azure Site Recovery.
  • Det finns en plötslig ökning av omsättningshastigheten på grund av att en hög mängd data väntar på uppladdning.

Så här löser du problemet:

  • Kontrollera att mållagringskontotypen (Standard eller Premium) etableras enligt omsättningshastighetskravet vid källan.

  • Om du redan replikerar till en Premium-hanterad disk (asrseeddisktyp) kontrollerar du att diskens storlek stöder den observerade omsättningsfrekvensen enligt Site Recovery-gränserna. Du kan öka storleken på asrseeddisken om det behövs. Följ dessa steg:

    • Gå till bladet Diskar på den berörda replikerade datorn och kopiera replikens disknamn
    • Gå till den här replikhanterade disken
    • Du kan se en banderoll på bladet Översikt som säger att en SAS-URL har genererats. Klicka på den här banderollen och avbryt exporten. Ignorera det här steget om du inte ser banderollen.
    • Så snart SAS-URL:en har återkallats går du till bladet Konfiguration för den hanterade disken och ökar storleken så att Azure Site Recovery stöder den observerade omsättningshastigheten på källdisken.

  • Om den observerade omsättningen är tillfällig väntar du några timmar på att den väntande datauppladdningen ska komma ikapp och skapa återställningspunkter.

  • Om disken innehåller icke-kritiska data som tillfälliga loggar, testdata osv. överväg att flytta dessa data någon annanstans eller helt utesluta disken från replikering

  • Om problemet kvarstår använder du Distributionshanteraren för Site Recovery för att planera replikering.

Källdatorer utan pulsslag [fel 78174]

Detta inträffar när Azure Site Recovery Mobility-agenten på källdatorn kommunicerar med konfigurationsservern (CS).

Lös problemet genom att använda följande steg för att verifiera nätverksanslutningen från den virtuella källdatorn till konfigurationsservern:

  1. Kontrollera att källdatorn körs.

  2. Logga in på källdatorn med ett konto som har administratörsbehörighet.

  3. Kontrollera att följande tjänster körs och om inte starta om tjänsterna:

    • Svagents (InMage Scout VX Agent)
    • InMage Scout Application Service

  4. På källdatorn undersöker du loggarna på platsen för felinformation:

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

Processerver utan pulsslag [fel 806]

Om det inte finns några pulsslag från processservern kontrollerar du följande:

  1. Den virtuella processserverdatorn är igång

  2. I följande loggar på processservern finns felinformation:

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

Huvudmålserver utan pulsslag [fel 78022]

Detta inträffar när Azure Site Recovery Mobility-agenten på huvudmålet inte kommunicerar med konfigurationsservern.

Lös problemet genom att använda följande steg för att verifiera tjänststatusen:

  1. Kontrollera att den virtuella huvudmåldatorn körs.
  2. Logga in på den virtuella huvudmåldatorn med ett konto som har administratörsbehörighet.

    • Kontrollera att svagents-tjänsten körs. Starta om tjänsten om den körs

    • Kontrollera loggarna på platsen för felinformation:

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

  3. Om du vill registrera huvudmålet med konfigurationsservern går du till mappen %PROGRAMDATA%\ASR\Agent och kör följande i kommandotolken: 
    cmd
cdpcli.exe --registermt

net stop obengine

net start obengine

exit

Det gick inte att aktivera skyddet för den virtuella datorn [fel 78253]

Det här felet kan inträffa om en replikeringsprincip inte har associerats med konfigurationsservern korrekt. Det kan också inträffa om principen som är associerad med konfigurationsservern inte är giltig.

Om du vill bekräfta orsaken till det här felet går du till återställningsvalvet > och hanterar Site Recovery-infrastrukturen och visar sedan replikeringsprinciperna för VMware och fysiska datorer för att kontrollera statusen för de konfigurerade principerna.

För att lösa problemet kan du associera principen med den konfigurationsserver som används eller skapa en ny replikeringsprincip och associera den. Om principen är ogiltig kan du koppla från och ta bort den.

Fel-ID 78144 – Ingen tillgänglig programkonsekvent återställningspunkt för den virtuella datorn under de senaste ”XXX” minuterna

Förbättringar har gjorts i mobilitetsagenten 9.23 & 9.27-versioner för att hantera VSS-installationsfel. Se till att du har de senaste versionerna för bästa vägledning om felsökning av VSS-fel.

Några av de vanligaste problemen visas:

Orsak 1: Känt problem i SQL Server 2008/2008 R2

Så här åtgärdar du: Det finns ett känt problem med SQL Server 2008/2008 R2. Läs den här KB-artikeln om att Azure Site Recovery Agent eller annan VSS-säkerhetskopiering som inte är komponent misslyckas för en server som är värd för SQL Server 2008 R2

Orsak 2: Azure Site Recovery-jobb misslyckas på servrar som är värdar för någon version av SQL Server-instanser med AUTO_CLOSE DB:er

Så här åtgärdar du: Mer information finns i kb-artikeln

Så här åtgärdar du : Se KB-artikeln

Orsak 3: Känt problem i SQL Server 2016 och 2017

Så här åtgärdar du: Mer information finns i kb-artikeln

Orsak 4: Appkonsekvens är inte aktiverat på Linux-servrar

Så här åtgärdar du: Azure Site Recovery för Linux-åtgärdssystem har stöd för programanpassade skript för appkonsekvens. Det anpassade skriptet med alternativ före och efter används av Azure Site Recovery Mobility Agent för appkonsekvens. Här följer stegen för att aktivera den.

Om du vill felsöka ytterligare kontrollerar du filerna på källdatorn för att få den exakta felkoden för fel:

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

Hur hittar du felen i filen? Sök efter strängen "vacpError" genom att öppna filen vacp.log i ett redigeringsprogram

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

I föregående exempel 2147754994 är felkoden som berättar om felet enligt följande:

VSS-skrivaren är inte installerad – Fel 2147221164

Så här åtgärdar du: För att generera en programkonsekvenstagg använder Azure Site Recovery Microsoft Volume Shadow Copy Service (VSS). Den installerar en VSS-provider för dess åtgärd för att ta ögonblicksbilder av appkonsekvens. Den här VSS-providern är installerad som en tjänst. Om VSS-providertjänsten inte är installerad misslyckas ögonblicksbilden av programkonsekvensen med fel-ID:t 0x80040154 "Klassen är inte registrerad".

Läs artikeln om felsökning av VSS-skrivarinstallation

VSS-skrivaren är inaktiverad – Fel 2147943458

Så här åtgärdar du: För att generera en programkonsekvenstagg använder Azure Site Recovery Microsoft Volume Shadow Copy Service (VSS). Den installerar en VSS-provider för dess åtgärd för att ta ögonblicksbilder av appkonsekvens. Den här VSS-providern är installerad som en tjänst. Om VSS-providertjänsten är inaktiverad misslyckas ögonblicksbilden av programkonsekvensen med fel-ID:t "Den angivna tjänsten är inaktiverad och kan inte startas(0x80070422)".

  • Om VSS är inaktiverat,
    • Kontrollera att starttypen för VSS-providertjänsten är inställd på Automatisk.
    • Starta om följande tjänster:
      • VSS-tjänst
      • VSS-provider för Azure Site Recovery
      • VDS-tjänst

VSS-provider NOT_REGISTERED – Fel 2147754756

Så här åtgärdar du: För att generera en programkonsekvenstagg använder Azure Site Recovery Microsoft Volume Shadow Copy Service (VSS). Kontrollera om VSS-providertjänsten för Azure Site Recovery är installerad eller inte.

  • Försök installera providern igen med hjälp av följande kommandon:
  • Avinstallera befintlig provider: C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Uninstall.cmd
  • Installera om: C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd

Kontrollera att starttypen för VSS-providertjänsten är inställd på Automatisk. – Starta om följande tjänster: – VSS-tjänsten – Azure Site Recovery VSS-provider – VDS-tjänsten

Fel-ID 95001 – Otillräckliga behörigheter hittades

Det här felet uppstår när du försöker aktivera replikering och programmapparna har inte tillräckligt med behörigheter.

Så här åtgärdar du: Lös problemet genom att kontrollera att IUSR-användaren har ägarrollen för alla följande mappar –

  • C\ProgramData\Microsoft Azure Site Recovery\private
  • Installationskatalogen. Om installationskatalogen till exempel är F-enhet anger du rätt behörigheter för att:
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems
  • Mappen \pushinstallsvc i installationskatalogen. Om installationskatalogen till exempel är F-enhet anger du rätt behörigheter för -
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc
  • Mappen \etc i installationskatalogen. Om installationskatalogen till exempel är F-enhet anger du rätt behörigheter för -
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\etc
  • C:\Temp
  • C:\thirdparty\php5nts
  • Alla objekt under följande sökväg -
    • C:\thirdparty\rrdtool-1.2.15-win32-perl58\rrdtool\Release*

Felsöka och hantera tidsändringar på replikerade servrar

Det här felet uppstår när källdatorns tid flyttas framåt och sedan flyttas tillbaka på kort tid för att korrigera ändringen. Du kanske inte märker ändringen eftersom tiden korrigeras snabbt.

Så här åtgärdar du: Lös problemet genom att vänta tills systemtiden överskrider den skeva framtida tiden. Ett annat alternativ är att inaktivera och aktivera replikering igen, vilket endast är möjligt för vidarebefordran av replikering (data som replikeras från lokalt till Azure) och inte gäller för omvänd replikering (data som replikeras från Azure till lokalt).

Nästa steg

Om du behöver mer hjälp kan du publicera din fråga på microsofts Q&A-frågesida för Azure Site Recovery. Vi har en aktiv community och en av våra tekniker kan hjälpa dig.