Dela via

Felsöka återställning efter fel till lokala enheter från Azure

  • Artikel

Den här artikeln beskriver hur du felsöker problem som kan uppstå när du växlar tillbaka virtuella Azure-datorer till din lokala VMware-infrastruktur efter redundansväxling till Azure med hjälp av Azure Site Recovery.

Återställning efter fel omfattar i princip två huvudsakliga steg. För det första steget måste du efter redundansväxlingen återaktivera skyddet av virtuella Azure-datorer till lokala datorer så att de börjar replikera. Det andra steget är att köra en redundansväxling från Azure för att återställa till din lokala plats.

Vanliga problem

  • Om du utför en skrivskyddad vCenter-identifiering av användare och skyddar virtuella datorer, så lyckas skyddet och redundansen fungerar. Under återaktiveringen misslyckas redundansväxlingen eftersom datalager inte kan identifieras. Ett symptom är att datalager inte visas under återaktivering av skyddet. För att lösa det här problemet kan du uppdatera vCenter-autentiseringsuppgifterna med ett lämpligt konto som har behörighet och sedan försöka utföra jobbet igen.
  • När du växlar tillbaka en virtuell Linux-dator och kör den lokalt kan du se att Network Manager-paketet har avinstallerats från datorn. Den här avinstallationen beror på att Network Manager-paketet tas bort när den virtuella datorn återställs i Azure.
  • När en virtuell Linux-dator konfigureras med en statisk IP-adress och växlas över till Azure hämtas IP-adressen från DHCP. När du redundansväxlar till en lokal plats fortsätter den virtuella datorn att använda DHCP för att hämta IP-adressen. Logga in på datorn manuellt och ställ sedan tillbaka IP-adressen till en statisk adress om det behövs. En virtuell Windows-dator kan hämta sin statiska IP-adress igen.
  • Om du använder antingen den kostnadsfria versionen av ESXi 5.5 eller den kostnadsfria versionen vSphere 6 Hypervisor lyckas redundansväxlingen, men återställning efter fel lyckas inte. Om du vill aktivera återställning efter fel uppgraderar du till programmets utvärderingslicens.
  • Om du inte kan nå konfigurationsservern från processervern använder du Telnet för att kontrollera anslutningen till konfigurationsservern på port 443. Du kan också försöka pinga konfigurationsservern från processervern. En processserver bör också ha pulsslag när den är ansluten till konfigurationsservern.
  • En Windows Server 2008 R2 SP1-server som skyddas som en fysisk lokal server kan inte återställas från Azure till en lokal plats.
  • Du kan inte växla tillbaka under följande omständigheter:
    • Du migrerade datorer till Azure.
    • Du har flyttat en virtuell dator till en annan resursgrupp.
    • Du har tagit bort den virtuella Azure-datorn.
    • Du har inaktiverat skyddet för den virtuella datorn.
    • Du skapade den virtuella datorn manuellt i Azure. Datorn ska först ha skyddats lokalt och redväxats till Azure innan den återaktiverats.
    • Du kan bara misslyckas med en ESXi-värd. Du kan inte återställa virtuella VMware-datorer eller fysiska servrar till Hyper-V-värdar, fysiska datorer eller VMware-arbetsstationer.

Felsöka återaktiveringsfel

Det här avsnittet beskriver vanliga återaktiveringsfel och hur du korrigerar dem.

Felkod 95226

Återaktiveringen av skyddet misslyckades eftersom den virtuella Azure-datorn inte kunde nå den lokala konfigurationsservern.

Det här felet inträffar i följande fall:

  • Den virtuella Azure-datorn kan inte nå den lokala konfigurationsservern. Den virtuella datorn kan inte identifieras och registreras på konfigurationsservern.
  • InMage Scout-programtjänsten körs inte på den virtuella Azure-datorn efter redundansväxlingen. Tjänsten behövs för kommunikation med den lokala konfigurationsservern.

Lös problemet så här:

  • Kontrollera att Azure VM-nätverket tillåter att den virtuella Azure-datorn kommunicerar med den lokala konfigurationsservern. Du kan antingen konfigurera en plats-till-plats-VPN till ditt lokala datacenter eller konfigurera en Azure ExpressRoute-anslutning med privat peering i den virtuella Azure-datorns virtuella nätverk.
  • Om den virtuella datorn kan kommunicera med den lokala konfigurationsservern loggar du in på den virtuella datorn. Kontrollera sedan InMage Scout-tillämpningstjänsten. Om du ser att den inte körs startar du tjänsten manuellt. Kontrollera att tjänststarttypen är inställd på Automatisk.

Felkod 78052

Det gick inte att slutföra skyddet för den virtuella datorn.

Det här problemet kan inträffa om det redan finns en virtuell dator med samma namn på huvudmålservern som du återställer till efter fel.

Lös problemet så här:

  • Välj en annan huvudmålserver på en annan värd så att återaktivering av skyddet skapar datorn på en annan värd, där namnen inte kolliderar.
  • Du kan också använda VMotion för att flytta huvudmålet till en annan värd där namnkollisionen inte sker. Om den befintliga virtuella datorn är en avvikande dator byter du namn på den så att den nya virtuella datorn kan skapas på samma ESXi-värd.

Felkod 78093

Den virtuella datorn körs inte, svarar inte eller är inte tillgänglig.

Lös problemet så här:

Om du vill återaktivera skyddet av en redundansväxlad virtuell dator måste den virtuella Azure-datorn köras så att mobilitetstjänsten registreras hos konfigurationsservern lokalt och kan börja replikera genom att kommunicera med processervern. Om datorn är i ett felaktigt nätverk eller inte körs (svarar inte eller har stängts av) kan konfigurationsservern inte nå mobilitetstjänsten på den virtuella datorn för att återaktivera skyddet.

  • Starta om den virtuella datorn så att den kan börja kommunicera lokalt.
  • Starta om jobbet för återaktivering av skyddet när du har startat den virtuella Azure-datorn.

Felkod 8061

Datalagringen är inte tillgänglig från ESXi-värden.

Kontrollera kraven för huvudmålet och datalager som stöds för återställning efter fel.

Felsöka problem med återställning efter fel

I det här avsnittet beskrivs vanliga fel som kan uppstå vid återställning efter fel.

Felkod 8038

Det gick inte att ta upp den lokala virtuella datorn på grund av felet.

Det här problemet uppstår när den lokala virtuella datorn tas upp på en värd som inte har tillräckligt med minne etablerat.

Lös problemet så här:

  • Etablera mer minne på ESXi-värden.
  • Dessutom kan du använda VMotion för att flytta den virtuella datorn till en annan ESXi-värd som har tillräckligt med minne för att starta den virtuella datorn.