Rozwiązywanie problemów z błędami w przypadku przejścia w tryb failover maszyny wirtualnej VMware lub komputera fizycznego na platformie Azure

Uwaga

W tym artykule odwołuje się do systemu CentOS — dystrybucji systemu Linux, która zbliża się do stanu zakończenia życia (EOL). Rozważ odpowiednie użycie i zaplanuj. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.

Podczas pracy w trybie failover maszyny wirtualnej na platformie Azure może wystąpić jeden z następujących błędów. Aby rozwiązać problemy, użyj opisanych kroków dla każdego warunku błędu.

Nie można przejść w tryb failover z powodu błędu o identyfikatorze 28031

Usługa Site Recovery nie mogła utworzyć maszyny wirtualnej w trybie failover na platformie Azure. Może się to zdarzyć z jednego z następujących powodów:

• Nie ma wystarczającego limitu przydziału, aby utworzyć maszynę wirtualną: możesz sprawdzić dostępny limit przydziału, przechodząc do obszaru Subskrypcja —> Użycie i limity przydziału. Możesz otworzyć nowy wniosek o pomoc techniczną, aby zwiększyć limit przydziału.

• Próbujesz przejść do trybu failover maszyn wirtualnych o różnych rozmiarach w tym samym zestawie dostępności. Upewnij się, że wybrano tę samą rodzinę rozmiarów dla wszystkich maszyn wirtualnych w tym samym zestawie dostępności. Zmień rozmiar, przechodząc do pozycji Ustawienia obliczeniowe maszyny wirtualnej, a następnie ponów próbę przejścia w tryb failover.

• Istnieją zasady dotyczące subskrypcji, które uniemożliwiają utworzenie maszyny wirtualnej. Zmień zasady, aby zezwolić na tworzenie maszyny wirtualnej, a następnie ponów próbę przejścia w tryb failover.

Nie można przejść w tryb failover z powodu błędu o identyfikatorze 28092

Usługa Site Recovery nie mogła utworzyć interfejsu sieciowego dla maszyny wirtualnej przełączonej w tryb failover. Upewnij się, że masz wystarczający limit przydziału, aby utworzyć interfejsy sieciowe w subskrypcji. Możesz sprawdzić dostępny limit przydziału, przechodząc do obszaru Subskrypcja —> użycie i limity przydziału. Możesz otworzyć nowy wniosek o pomoc techniczną, aby zwiększyć limit przydziału. Jeśli masz wystarczający limit przydziału, może to być sporadyczne problemy, spróbuj ponownie wykonać operację. Jeśli problem będzie się powtarzać nawet po ponownych próbach, pozostaw komentarz na końcu tego dokumentu.

Nie można przejść w tryb failover z powodu błędu o identyfikatorze 70038

Usługa Site Recovery nie mogła utworzyć klasycznej maszyny wirtualnej w trybie failover na platformie Azure. Może się tak zdarzyć, ponieważ:

• Jeden z zasobów, takich jak sieć wirtualna wymagana do utworzenia maszyny wirtualnej, nie istnieje. Utwórz sieć wirtualną podaną w obszarze Ustawienia sieci maszyny wirtualnej lub zmodyfikuj ustawienie sieci wirtualnej, która już istnieje, a następnie ponów próbę przejścia w tryb failover.

Tryb failover zakończył się niepowodzeniem z identyfikatorem błędu 170010

Usługa Site Recovery nie mogła utworzyć maszyny wirtualnej w trybie failover na platformie Azure. Może się to zdarzyć, ponieważ wewnętrzna aktywność nawodnienia nie powiodła się dla lokalnej maszyny wirtualnej.

Aby uruchomić dowolną maszynę na platformie Azure, środowisko platformy Azure wymaga, aby niektóre sterowniki w stanie uruchamiania rozruchu i usługi, takie jak DHCP, zostały w stanie automatycznego uruchamiania. W związku z tym działanie nawodnienia, w momencie przejścia w tryb failover, konwertuje typ uruchamiania atapi, intelide, storflt, vmbus i sterowniki storvsc w celu uruchomienia rozruchu. Konwertuje również typ uruchamiania kilku usług, takich jak DHCP, na autostart. To działanie może zakończyć się niepowodzeniem z powodu problemów specyficznych dla środowiska.

Aby ręcznie zmienić typ uruchamiania sterowników systemu operacyjnego gościa systemu operacyjnego Windows, wykonaj poniższe kroki:

1. Pobierz skrypt no-hydration i uruchom go w następujący sposób. Ten skrypt sprawdza, czy maszyna wirtualna wymaga nawodnienia.

   .\Script-no-hydration.ps1

   Daje następujący wynik, jeśli wymagane jest nawodnienie:

   REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
   
   This system doesn't meet no-hydration requirement.
   

   Jeśli maszyna wirtualna nie spełnia wymagań dotyczących nawodnienia, skrypt daje wynik "Ten system nie spełnia wymagań dotyczących nawodnienia". W takim przypadku wszystkie sterowniki i usługi są w stanie wymaganym przez platformę Azure, a nawodnienie maszyny wirtualnej nie jest wymagane.

2. Uruchom skrypt no-hydration-set w następujący sposób, jeśli maszyna wirtualna nie spełnia wymagań dotyczących nawodnienia.

   .\Script-no-hydration.ps1 -set

   Spowoduje to przekonwertowanie typu uruchamiania sterowników i da wynik podobny do poniższego:

   REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
   
   Updating registry:  REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc   start =  0
   
   This system is now no-hydration compatible.
   

Tryb failover zakończył się niepowodzeniem z powodu błędu z informacją, że adresy IP repliki dla karty sieciowej maszyny wirtualnej są nieprawidłowe

Test pracy w trybie failover lub operacja trybu failover może zakończyć się niepowodzeniem dla maszyny z powodu błędu "Co najmniej jeden adres IP repliki dla karty sieciowej maszyny wirtualnej jest nieprawidłowy", jeśli nie powiodło się prawidłowe czyszczenie poprzedniej operacji testu pracy w trybie failover. W związku z tym maszyna testowa może nadal znajdować się w środowisku platformy Azure i może używać tego samego adresu IP. Powoduje to, że docelowa konfiguracja maszyny wirtualnej staje się krytyczna.

Aby rozwiązać ten problem, upewnij się, że zostało wykonane kompletne testowe czyszczenie trybu failover, aby operacja przejścia w tryb failover lub testowa mogła zakończyć się powodzeniem.

Nie można nawiązać połączenia/RDP/SSH z maszyną wirtualną w trybie pracy awaryjnej, ponieważ przycisk Połączenie jest wyszarzony na maszynie wirtualnej

Aby uzyskać szczegółowe instrukcje dotyczące rozwiązywania problemów z protokołem RDP, zapoznaj się z naszą dokumentacją tutaj.

Aby uzyskać szczegółowe instrukcje dotyczące rozwiązywania problemów z protokołem SSH, zapoznaj się z naszą dokumentacją tutaj.

Jeśli przycisk Połączenie na maszynie wirtualnej w trybie failover na platformie Azure jest wyszarzany i nie masz połączenia z platformą Azure za pośrednictwem usługi Express Route lub połączenia sieci VPN typu lokacja-lokacja, wówczas

1. Przejdź do pozycji Sieć maszyny>wirtualnej, kliknij nazwę wymaganego interfejsu sieciowego.
2. Przejdź do pozycji Konfiguracje adresów IP, a następnie wybierz pole nazwy wymaganej konfiguracji adresu IP.
3. Aby włączyć publiczny adres IP, wybierz pozycję Włącz.
4. Kliknij pozycję Konfiguruj wymagane ustawienia>Utwórz nowe.
5. Wprowadź nazwę adresu publicznego, wybierz opcje domyślne dla jednostki SKU i przypisania, a następnie wybierz przycisk OK.
6. Teraz, aby zapisać wprowadzone zmiany, wybierz pozycję Zapisz.
7. Zamknij panele i przejdź do sekcji Przegląd maszyny wirtualnej, aby nawiązać połączenie/RDP.

Nie można nawiązać połączenia/połączenia RDP/SSH — maszyna wirtualna Połączenie dostępny

Jeśli przycisk Połączenie na maszynie wirtualnej w trybie failover na platformie Azure jest dostępny (nie jest wyszaryzony), sprawdź diagnostykę rozruchu na maszynie wirtualnej i sprawdź błędy zgodnie z opisem w tym artykule.

1. Jeśli maszyna wirtualna nie została uruchomiona, spróbuj przejąć tryb failover do starszego punktu odzyskiwania.

2. Jeśli aplikacja wewnątrz maszyny wirtualnej nie działa, spróbuj przejąć tryb failover do punktu odzyskiwania spójnego z aplikacją.

3. Jeśli maszyna wirtualna jest przyłączona do domeny, upewnij się, że kontroler domeny działa prawidłowo. Można to zrobić, wykonując poniższe kroki:

   a. Utwórz nową maszynę wirtualną w tej samej sieci.

   b. Upewnij się, że jest w stanie dołączyć do tej samej domeny, w której powinna pojawić się maszyna wirtualna przełączona w tryb failover.

   c. Jeśli kontroler domeny nie działa prawidłowo, spróbuj zalogować się do maszyny wirtualnej w trybie failover przy użyciu konta administratora lokalnego.

4. Jeśli używasz niestandardowego serwera DNS, upewnij się, że jest dostępny. Można to zrobić, wykonując poniższe kroki:

   a. Tworzenie nowej maszyny wirtualnej w tej samej sieci i

   b. Sprawdź, czy maszyna wirtualna może rozpoznać nazwy przy użyciu niestandardowego serwera DNS

Uwaga

Włączenie dowolnego ustawienia innego niż diagnostyka rozruchu wymaga zainstalowania agenta maszyny wirtualnej platformy Azure na maszynie wirtualnej przed przejściem w tryb failover

Nie można otworzyć konsoli szeregowej po przejściu w tryb failover maszyny opartej na interfejsie UEFI na platformie Azure

Jeśli możesz nawiązać połączenie z maszyną przy użyciu protokołu RDP, ale nie możesz otworzyć konsoli szeregowej, wykonaj poniższe kroki:

• Jeśli system operacyjny maszyny to Red Hat lub Oracle Linux 7.*/8.0, uruchom następujące polecenie na maszynie wirtualnej platformy Azure w trybie failover z uprawnieniami głównymi. Uruchom ponownie maszynę wirtualną po poleceniu .

  grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
  

• Jeśli system operacyjny komputera to CentOS 7.*, uruchom następujące polecenie na maszynie wirtualnej platformy Azure w trybie failover z uprawnieniami głównymi. Uruchom ponownie maszynę wirtualną po poleceniu .

  grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
  

Nieoczekiwany komunikat zamknięcia (zdarzenie o identyfikatorze 6008)

Podczas rozruchu maszyny wirtualnej z systemem Windows po przejściu w tryb failover, jeśli na odzyskanej maszynie wirtualnej zostanie wyświetlony nieoczekiwany komunikat o zamknięciu, oznacza to, że stan zamknięcia maszyny wirtualnej nie został przechwycony w punkcie odzyskiwania używanym do przejścia w tryb failover. Dzieje się tak w przypadku odzyskiwania do punktu, gdy maszyna wirtualna nie została w pełni zamknięta.

Zwykle nie jest to przyczyna problemu i zwykle może być ignorowana w przypadku nieplanowanych trybów failover. Jeśli planowane jest przełączenie w tryb failover, upewnij się, że maszyna wirtualna została prawidłowo zamknięta przed przejściem w tryb failover i zapewnij wystarczający czas, aż oczekujące dane replikacji będą wysyłane lokalnie na platformę Azure. Następnie użyj opcji Najnowsze na ekranie trybu failover, aby wszystkie oczekujące dane na platformie Azure były przetwarzane do punktu odzyskiwania, który jest następnie używany do pracy w trybie failover maszyny wirtualnej.

Nie można wybrać magazynu danych

Ten problem jest wskazywany, gdy nie możesz wyświetlić magazynu danych w witrynie Azure Portal podczas próby ponownego włączenia ochrony maszyny wirtualnej, która napotkała przejście w tryb failover. Dzieje się tak, ponieważ obiekt docelowy wzorca nie jest rozpoznawany jako maszyna wirtualna w obszarze vCenters dodanych do usługi Azure Site Recovery.

Aby uzyskać więcej informacji na temat ponownego włączania ochrony maszyny wirtualnej, zobacz Ponowne włączanie ochrony maszyn i powrót po awarii do lokacji lokalnej po przejściu w tryb failover na platformę Azure.

W celu rozwiązania tego problemu:

Ręcznie utwórz obiekt docelowy główny w programie vCenter, który zarządza maszyną źródłową. Magazyn danych będzie dostępny po kolejnych operacjach odnajdywania i odświeżania sieci szkieletowej programu vCenter.

Uwaga

Wykonanie operacji odnajdywania i odświeżania sieci szkieletowej może potrwać do 30 minut.

Rejestracja głównego obiektu docelowego systemu Linux z cs kończy się niepowodzeniem z powodu błędu TLS 35

Rejestracja głównego obiektu docelowego usługi Azure Site Recovery z serwerem konfiguracji kończy się niepowodzeniem z powodu włączenia uwierzytelnionego serwera proxy w głównym obiekcie docelowym.

Ten błąd jest wskazywany przez następujące ciągi w dzienniku instalacji:

RegisterHostStaticInfo encountered exception config/talwrapper.cpp(107)[post] CurlWrapper Post failed : server : 10.38.229.221, port : 443, phpUrl : request_handler.php, secure : true, ignoreCurlPartialError : false with error: [at curlwrapperlib/curlwrapper.cpp:processCurlResponse:231]   failed to post request: (35) - SSL connect error. 

W celu rozwiązania tego problemu:

1. Na maszynie wirtualnej serwera konfiguracji otwórz wiersz polecenia i sprawdź ustawienia serwera proxy przy użyciu następujących poleceń:

   cat /etc/environment echo $http_proxy echo $https_proxy

2. Jeśli dane wyjściowe poprzednich poleceń pokazują, że zdefiniowano ustawienia http_proxy lub https_proxy, użyj jednej z następujących metod, aby odblokować komunikację master target z serwerem konfiguracji:

   • Pobierz narzędzie PsExec.

   • Użyj narzędzia , aby uzyskać dostęp do kontekstu użytkownika systemu i określić, czy adres serwera proxy jest skonfigurowany.

   • Jeśli serwer proxy jest skonfigurowany, otwórz program IE w kontekście użytkownika systemu przy użyciu narzędzia PsExec.

     psexec -s -i "%programfiles%\Internet Explorer\iexplore.exe"

   • Aby upewnić się, że główny serwer docelowy może komunikować się z serwerem konfiguracji:

     • Zmodyfikuj ustawienia serwera proxy w programie Internet Explorer, aby pominąć główny adres IP serwera docelowego za pośrednictwem serwera proxy.
       Or
     • Wyłącz serwer proxy na głównym serwerze docelowym.

Następne kroki

• Rozwiązywanie problemów z połączeniem RDP z maszyną wirtualną z systemem Windows
• Rozwiązywanie problemów z połączeniem SSH z maszyną wirtualną z systemem Linux

Jeśli potrzebujesz dodatkowej pomocy, opublikuj zapytanie na stronie pytań i odpowiedzi firmy Microsoft dla usługi Site Recovery lub pozostaw komentarz na końcu tego dokumentu. Mamy aktywną społeczność, która powinna być w stanie Ci pomóc.