Rozwiązywanie problemów z powrotem po awarii do lokacji lokalnej z platformy Azure

W tym artykule opisano sposób rozwiązywania problemów, które mogą wystąpić podczas powrotu po awarii maszyn wirtualnych platformy Azure do lokalnej infrastruktury VMware po przejściu w tryb failover na platformę Azure przy użyciu usługi Azure Site Recovery.

Powrót po awarii zasadniczo obejmuje dwa główne kroki. W pierwszym kroku po przejściu w tryb failover należy ponownie włączyć ochronę maszyn wirtualnych platformy Azure w środowisku lokalnym, aby rozpocząć replikację. Drugim krokiem jest uruchomienie trybu failover z platformy Azure w celu powrotu po awarii do lokacji lokalnej.

Typowe problemy

• Jeśli odnajdujesz maszyny wirtualne i chronisz maszyny wirtualne tylko do odczytu, ochrona zakończy się pomyślnie, a tryb failover działa. Podczas ponownego włączania ochrony tryb failover kończy się niepowodzeniem, ponieważ nie można odnaleźć magazynów danych. Objawem jest to, że magazyny danych nie są wyświetlane podczas ponownego włączania ochrony. Aby rozwiązać ten problem, możesz zaktualizować poświadczenia programu vCenter przy użyciu odpowiedniego konta z uprawnieniami, a następnie ponowić próbę wykonania zadania.
• Po powrocie po awarii maszyny wirtualnej z systemem Linux i uruchomieniu jej lokalnie można zobaczyć, że pakiet Programu Network Manager został odinstalowany z maszyny. Ta dezinstalacja występuje, ponieważ pakiet Programu Network Manager jest usuwany po odzyskaniu maszyny wirtualnej na platformie Azure.
• Gdy maszyna wirtualna z systemem Linux jest skonfigurowana przy użyciu statycznego adresu IP i jest przełączona w tryb failover na platformę Azure, adres IP jest uzyskiwany z protokołu DHCP. Po przejściu w tryb failover do środowiska lokalnego maszyna wirtualna będzie nadal używać protokołu DHCP do uzyskania adresu IP. Ręcznie zaloguj się do maszyny, a następnie w razie potrzeby ustaw adres IP z powrotem na adres statyczny. Maszyna wirtualna z systemem Windows może ponownie uzyskać statyczny adres IP.
• Jeśli używasz bezpłatnej wersji ESXi 5.5 lub wersji bezpłatnej vSphere 6 Hypervisor, tryb failover zakończy się powodzeniem, ale powrót po awarii nie powiedzie się. Aby włączyć powrót po awarii, uaktualnij do licencji ewaluacyjnej programu.
• Jeśli nie możesz nawiązać połączenia z serwerem konfiguracji z serwera przetwarzania, użyj programu Telnet, aby sprawdzić łączność z serwerem konfiguracji na porcie 443. Możesz również spróbować wysłać polecenie ping do serwera konfiguracji z serwera przetwarzania. Serwer przetwarzania powinien również mieć puls, gdy jest połączony z serwerem konfiguracji.
• Serwer z systemem Windows Server 2008 R2 SP1 chroniony jako fizyczny serwer lokalny nie może wrócić z platformy Azure do lokacji lokalnej.
• Nie można wrócić po awarii w następujących okolicznościach:
  • Maszyny zmigrowane na platformę Azure.
  • Maszyna wirtualna została przeniesiona do innej grupy zasobów.
  • Usunięto maszynę wirtualną platformy Azure.
  • Wyłączono ochronę maszyny wirtualnej.
  • Maszyna wirtualna została utworzona ręcznie na platformie Azure. Maszyna powinna być początkowo chroniona lokalnie i przełączona w tryb failover na platformę Azure przed ponownym włączaniem ochrony.
  • Host ESXi może zakończyć się niepowodzeniem. Nie można uruchomić powrotu po awarii maszyn wirtualnych VMware ani serwerów fizycznych do hostów funkcji Hyper-V, maszyn fizycznych ani stacji roboczych VMware.

Rozwiązywanie problemów z błędami ponownego włączania ochrony

W tej sekcji opisano typowe błędy ponownego włączania ochrony i sposoby ich poprawiania.

Kod błędu 95226

Ponowne włączanie ochrony nie powiodło się, ponieważ maszyna wirtualna platformy Azure nie mogła nawiązać połączenia z lokalnym serwerem konfiguracji.

Ten błąd występuje, gdy:

• Maszyna wirtualna platformy Azure nie może nawiązać połączenia z lokalnym serwerem konfiguracji. Nie można odnaleźć i zarejestrować maszyny wirtualnej na serwerze konfiguracji.
• Usługa aplikacji InMage Scout nie jest uruchamiana na maszynie wirtualnej platformy Azure po przejściu w tryb failover. Usługa jest wymagana do komunikacji z lokalnym serwerem konfiguracji.

Aby rozwiązać ten problem:

• Sprawdź, czy sieć maszyny wirtualnej platformy Azure umożliwia maszynie wirtualnej platformy Azure komunikowanie się z lokalnym serwerem konfiguracji. Możesz skonfigurować międzylokacyjną sieć VPN z lokalnym centrum danych lub skonfigurować połączenie usługi Azure ExpressRoute z prywatną komunikacją równorzędną w sieci wirtualnej maszyny wirtualnej platformy Azure.
• Jeśli maszyna wirtualna może komunikować się z lokalnym serwerem konfiguracji, zaloguj się do maszyny wirtualnej. Następnie sprawdź usługę aplikacji InMage Scout. Jeśli widzisz, że nie jest ona uruchomiona, uruchom usługę ręcznie. Sprawdź, czy typ uruchomienia usługi jest ustawiony na Wartość Automatyczna.

Kod błędu 78052

Nie można ukończyć ochrony dla maszyny wirtualnej.

Ten problem może występować, jeśli na głównym serwerze docelowym, do którego wracasz po awarii, istnieje już maszyna wirtualna o takiej samej nazwie.

Aby rozwiązać ten problem:

• Wybierz inny główny serwer docelowy na innym hoście, aby ponowne włączenie ochrony powodowało utworzenie maszyny na innym hoście, na którym nazwy nie będą ze sobą kolidować.
• Możesz również użyć narzędzia VMotion, aby przenieść główny serwer docelowy na inny host, na którym nie występuje kolizja nazw. Jeśli istniejąca maszyna wirtualna jest bezpańską maszyną, zmień jej nazwę, aby można było utworzyć nową maszynę wirtualną na tym samym hoście ESXi.

Kod błędu 78093

Maszyna wirtualna nie jest uruchomiona, nie odpowiada lub nie jest dostępna.

Aby rozwiązać ten problem:

W celu ponownego włączenia ochrony maszyny wirtualnej w trybie failover należy uruchomić maszynę wirtualną platformy Azure, aby usługa mobilności zarejestrowała się na serwerze konfiguracji lokalnie i mogła rozpocząć replikację, komunikując się z serwerem przetwarzania. Jeśli maszyna znajduje się w nieprawidłowej sieci lub nie jest uruchomiona (nie odpowiada lub jest wyłączona), serwer konfiguracji nie może nawiązać połączenia z usługą mobilności na maszynie wirtualnej w celu rozpoczęcia ponownego włączania ochrony.

• Uruchom ponownie maszynę wirtualną, aby mogła ona rozpocząć komunikację lokalną.
• Uruchom ponownie zadanie ponownego włączania ochrony po uruchomieniu maszyny wirtualnej platformy Azure.

Kod błędu 8061

Magazyn danych nie jest dostępny z hosta ESXi.

Sprawdź wymagania wstępne głównego serwera docelowego i obsługiwane magazyny danych pod kątem powrotu po awarii.

Rozwiązywanie problemów z błędami powrotu po awarii

W tej sekcji opisano typowe błędy, które mogą wystąpić podczas powrotu po awarii.

Kod błędu 8038

Nie można wyświetlić lokalnej maszyny wirtualnej z powodu błędu.

Ten problem występuje, gdy lokalna maszyna wirtualna jest wywoływana na hoście, który nie ma wystarczającej ilości aprowizowanej pamięci.

Aby rozwiązać ten problem:

• Aprowizuj więcej pamięci na hoście ESXi.
• Ponadto możesz użyć narzędzia VMotion, aby przenieść maszynę wirtualną do innego hosta ESXi, który ma wystarczającą ilość pamięci, aby uruchomić maszynę wirtualną.