Rozwiązywanie problemów z błędami z replikacją maszyny wirtualnej z platformy Azure do platformy Azure

W tym artykule opisano sposób rozwiązywania typowych błędów w usłudze Azure Site Recovery podczas replikacji i odzyskiwania maszyn wirtualnych platformy Azure z jednego regionu do innego. Aby uzyskać więcej informacji na temat obsługiwanych konfiguracji, zobacz macierz obsługi replikowania maszyn wirtualnych platformy Azure.

Problemy z limitem przydziału zasobów platformy Azure (kod błędu 150097)

Upewnij się, że twoja subskrypcja jest włączona do tworzenia maszyn wirtualnych platformy Azure w regionie docelowym, który ma być używany jako region odzyskiwania po awarii (DR). Twoja subskrypcja wymaga wystarczającego limitu przydziału, aby utworzyć maszyny wirtualne o niezbędnych rozmiarach. Domyślnie usługa Site Recovery wybiera rozmiar docelowej maszyny wirtualnej, który jest taki sam jak rozmiar źródłowej maszyny wirtualnej. Jeśli pasujący rozmiar nie jest dostępny, usługa Site Recovery automatycznie wybierze najbliższy dostępny rozmiar.

Jeśli nie ma rozmiaru obsługującego konfigurację źródłowej maszyny wirtualnej, zostanie wyświetlony następujący komunikat:

Replication couldn't be enabled for the virtual machine <VmName>.

Możliwe przyczyny

  • Identyfikator subskrypcji nie umożliwia tworzenia żadnych maszyn wirtualnych w lokalizacji regionu docelowego.
  • Identyfikator subskrypcji nie umożliwia tworzenia określonych rozmiarów maszyn wirtualnych w lokalizacji regionu docelowego albo nie ma do tego wystarczającego limitu przydziału.
  • Nie znaleziono odpowiedniego rozmiaru docelowej maszyny wirtualnej zgodnego z liczbą kart sieciowych (2) źródłowej maszyny wirtualnej dla identyfikatora subskrypcji w lokalizacji regionu docelowego.

Rozwiązywanie problemu

Skontaktuj się z pomocą techniczną dotyczącą rozliczeń platformy Azure , aby umożliwić subskrypcji tworzenie maszyn wirtualnych o wymaganych rozmiarach w lokalizacji docelowej. Następnie ponów próbę wykonania operacji, która zakończyła się niepowodzeniem.

Jeśli lokalizacja docelowa ma ograniczenie pojemności, wyłącz replikację do tej lokalizacji. Następnie włącz replikację do innej lokalizacji, w której subskrypcja ma wystarczający limit przydziału, aby utworzyć maszyny wirtualne o wymaganych rozmiarach.

Zaufane certyfikaty główne (kod błędu 151066)

Jeśli nie wszystkie najnowsze zaufane certyfikaty główne są obecne na maszynie wirtualnej, zadanie włączenia replikacji dla Site Recovery może zakończyć się niepowodzeniem. Uwierzytelnianie i autoryzacja wywołań usługi Site Recovery z maszyny wirtualnej kończy się niepowodzeniem bez tych certyfikatów.

Jeśli zadanie włączania replikacji zakończy się niepowodzeniem, zostanie wyświetlony następujący komunikat:

Site Recovery configuration failed.

Możliwa przyczyna

Zaufane certyfikaty główne wymagane do autoryzacji i uwierzytelniania nie są obecne na maszynie wirtualnej.

Rozwiązywanie problemu

Windows

W przypadku maszyny wirtualnej z systemem operacyjnym Windows zainstaluj najnowsze aktualizacje systemu Windows, aby wszystkie zaufane certyfikaty główne znajdują się na maszynie wirtualnej. Postępuj zgodnie z typowym procesem zarządzania aktualizacjami systemu Windows lub zarządzania aktualizacjami certyfikatów w organizacji, aby uzyskać najnowsze certyfikaty główne i zaktualizowaną listę odwołania certyfikatów na maszynach wirtualnych.

  • Jeśli jesteś w środowisku bez połączenia, postępuj zgodnie ze standardowym procesem aktualizacji systemu Windows w organizacji, aby uzyskać certyfikaty.
  • Jeśli wymagane certyfikaty nie są obecne na maszynie wirtualnej, wywołania usługi Site Recovery kończą się niepowodzeniem ze względów bezpieczeństwa.

Aby sprawdzić, czy problem został rozwiązany, przejdź do login.microsoftonline.com przeglądarki na maszynie wirtualnej.

Aby uzyskać więcej informacji, zobacz Konfigurowanie zaufanych katalogów głównych i niedozwolonych certyfikatów.

Linux

Postępuj zgodnie ze wskazówkami dostarczonymi przez dystrybutora wersji systemu operacyjnego Linux, aby uzyskać najnowsze zaufane certyfikaty główne i najnowszą listę odwołania certyfikatów na maszynie wirtualnej.

Ponieważ system SUSE Linux używa linków symbolicznych lub linków symlinków, aby zachować listę certyfikatów, wykonaj następujące kroki:

  1. Zaloguj się jako użytkownik główny . Symbol skrótu (#) jest domyślnym wierszem polecenia.

  2. Aby zmienić katalog, uruchom następujące polecenie:

    cd /etc/ssl/certs

  3. Sprawdź, czy certyfikat głównego urzędu certyfikacji firmy Symantec jest obecny:

    ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

    • Jeśli certyfikat głównego urzędu certyfikacji firmy Symantec nie zostanie znaleziony, uruchom następujące polecenie, aby pobrać plik. Sprawdź, czy występują błędy i postępuj zgodnie z zalecanymi akcjami w przypadku awarii sieci.

      wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

  4. Sprawdź, czy certyfikat głównego urzędu certyfikacji Baltimore jest obecny:

    ls Baltimore_CyberTrust_Root.pem

    • Jeśli certyfikat głównego urzędu certyfikacji Baltimore nie zostanie znaleziony, uruchom następujące polecenie, aby pobrać certyfikat:

      wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem

  5. Sprawdź, czy certyfikat DigiCert_Global_Root_CA jest obecny:

    ls DigiCert_Global_Root_CA.pem

    • Jeśli DigiCert_Global_Root_CA nie zostanie znaleziona, uruchom następujące polecenia, aby pobrać certyfikat:

      wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
      
      openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
      
  6. Aby zaktualizować skróty podmiotu certyfikatu dla nowo pobranych certyfikatów, uruchom skrypt rehash:

    c_rehash

  7. Aby sprawdzić, czy skróty podmiotu jako linki symlinków zostały utworzone dla certyfikatów, uruchom następujące polecenia:

    ls -l | grep Baltimore
    
    lrwxrwxrwx 1 root root   29 Jan  8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem
    
    -rw-r--r-- 1 root root 1303 Jun  5  2014 Baltimore_CyberTrust_Root.pem
    
    ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5
    
    -rw-r--r-- 1 root root 1774 Jun  5  2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
    
    lrwxrwxrwx 1 root root   62 Jan  8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
    
    ls -l | grep DigiCert_Global_Root
    
    lrwxrwxrwx 1 root root   27 Jan  8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem
    
    -rw-r--r-- 1 root root 1380 Jun  5  2014 DigiCert_Global_Root_CA.pem
    
  8. Utwórz kopię pliku VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem z nazwą pliku b204d74a.0:

    cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0

  9. Utwórz kopię pliku Baltimore_CyberTrust_Root.pem z nazwą 653b494a.0:

    cp Baltimore_CyberTrust_Root.pem 653b494a.0

  10. Utwórz kopię pliku DigiCert_Global_Root_CA.pem z nazwą pliku 3513523f.0:

    cp DigiCert_Global_Root_CA.pem 3513523f.0

  11. Sprawdź, czy pliki są obecne:

    ls -l 653b494a.0 b204d74a.0 3513523f.0
    
    -rw-r--r-- 1 root root 1774 Jan  8 09:52 3513523f.0
    
    -rw-r--r-- 1 root root 1303 Jan  8 09:52 653b494a.0
    
    -rw-r--r-- 1 root root 1774 Jan  8 09:52 b204d74a.0
    

Wychodzące adresy URL lub zakresy adresów IP (kod błędu 151037 lub 151072)

Aby replikacja Site Recovery działała, wymagana jest łączność wychodząca z określonymi adresami URL z maszyny wirtualnej. Jeśli maszyna wirtualna znajduje się za zaporą lub używa reguł sieciowej grupy zabezpieczeń do kontrolowania łączności wychodzącej, może wystąpić jeden z tych problemów. Mimo że nadal obsługujemy dostęp wychodzący za pośrednictwem adresów URL, używanie listy dozwolonych zakresów adresów IP nie jest już obsługiwane.

Możliwe przyczyny

  • Nie można ustanowić połączenia z punktami końcowymi Site Recovery z powodu błędu rozpoznawania nazw domen (DNS).
  • Ten problem jest bardziej powszechny podczas ponownego włączania ochrony w przypadku przełączenia maszyny wirtualnej w tryb failover, ale serwer DNS nie jest osiągalny z regionu odzyskiwania po awarii (DR).

Rozwiązywanie problemu

Jeśli używasz niestandardowego systemu DNS, upewnij się, że serwer DNS jest dostępny z regionu odzyskiwania po awarii.

Aby sprawdzić, czy maszyna wirtualna używa niestandardowego ustawienia DNS:

  1. Otwórz pozycję Maszyny wirtualne i wybierz maszynę wirtualną.
  2. Przejdź do ustawień maszyn wirtualnych i wybierz pozycję Sieć.
  3. W obszarze Sieć wirtualna/podsieć wybierz link, aby otworzyć stronę zasobów sieci wirtualnej.
  4. Przejdź do obszaru Ustawienia i wybierz pozycję Serwery DNS.

Spróbuj uzyskać dostęp do serwera DNS z maszyny wirtualnej. Jeśli serwer DNS jest niedostępny, udostępnij go przez przełączenie serwera DNS w tryb failover lub utworzenie wiersza lokacji między siecią odzyskiwania po awarii i systemem DNS.

Uwaga

Jeśli używasz prywatnych punktów końcowych, upewnij się, że maszyny wirtualne mogą rozpoznać prywatne rekordy DNS.

com-error.

Problem 2: konfiguracja Site Recovery nie powiodła się (151196)

Możliwa przyczyna

Nie można ustanowić połączenia z punktami końcowymi uwierzytelniania platformy Microsoft 365 i tożsamości IP4.

Rozwiązywanie problemu

Usługa Azure Site Recovery wymagany dostęp do zakresów adresów IP platformy Microsoft 365 na potrzeby uwierzytelniania. Jeśli używasz reguł sieciowej grupy zabezpieczeń platformy Azure/serwera proxy zapory do kontrolowania wychodzącej łączności sieciowej na maszynie wirtualnej, upewnij się, że używasz reguły sieciowej grupy zabezpieczeń opartej na tagach usługi Azure Active Directory (AAD), aby zezwolić na dostęp do usługi AAD. Nie obsługujemy już reguł sieciowej grupy zabezpieczeń opartej na adresach IP.

Problem 3: konfiguracja Site Recovery nie powiodła się (151197)

Możliwa przyczyna

Nie można ustanowić połączenia z punktami końcowymi usługi Azure Site Recovery.

Rozwiązywanie problemu

Jeśli używasz reguł sieciowej grupy zabezpieczeń platformy Azure/serwera proxy zapory do kontrolowania wychodzącej łączności sieciowej na maszynie wirtualnej, upewnij się, że używasz tagów usługi. Nie obsługujemy już używania listy dozwolonych adresów IP za pośrednictwem sieciowych grup zabezpieczeń dla usługi Azure Site Recovery.

Problem 4: Replikacja kończy się niepowodzeniem, gdy ruch sieciowy korzysta z lokalnego serwera proxy (151072)

Możliwa przyczyna

Niestandardowe ustawienia serwera proxy są nieprawidłowe, a agent usługa mobilności nie automatycznieetował ustawień serwera proxy z programu Internet Explorer (IE).

Rozwiązywanie problemu

  1. Agent usługa mobilności wykrywa ustawienia serwera proxy z programu IE w systemie Windows i /etc/environment w systemie Linux.

  2. Jeśli wolisz ustawić serwer proxy tylko dla usługa mobilności, możesz podać szczegóły serwera proxy w pliku ProxyInfo.conf znajdującym się w lokalizacji:

    • Linux: /usr/local/InMage/config/
    • Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config
  3. Plik ProxyInfo.conf powinien mieć ustawienia serwera proxy w następującym formacie INI .

    [proxy]
    Address=http://1.2.3.4
    Port=567
    

Uwaga

Agent usługa mobilności obsługuje tylko nieuwierzytelnione serwery proxy.

Więcej informacji

Aby określić wymagane adresy URL lub wymagane zakresy adresów IP, postępuj zgodnie ze wskazówkami w temacie Informacje o sieci na platformie Azure do replikacji na platformę Azure.

Nie można odnaleźć dysku na maszynie wirtualnej (kod błędu 150039)

Należy zainicjować nowy dysk dołączony do maszyny wirtualnej. Jeśli dysk nie zostanie znaleziony, zostanie wyświetlony następujący komunikat:

Azure data disk <DiskName> <DiskURI> with logical unit number <LUN> <LUNValue> was not mapped to a corresponding disk being reported from within the VM that has the same LUN value.

Możliwe przyczyny

  • Nowy dysk danych został dołączony do maszyny wirtualnej, ale nie został zainicjowany.
  • Dysk danych wewnątrz maszyny wirtualnej nie zgłasza poprawnie wartości numeru jednostki logicznej (LUN), przy której dysk został dołączony do maszyny wirtualnej.

Rozwiązywanie problemu

Upewnij się, że dyski danych są inicjowane, a następnie ponów próbę wykonania operacji.

Jeśli problem będzie się powtarzać, skontaktuj się z pomocą techniczną.

Wiele dysków dostępnych do ochrony (kod błędu 153039)

Możliwe przyczyny

  • Co najmniej jeden dysk został niedawno dodany do maszyny wirtualnej po ochronie.
  • Co najmniej jeden dysk został zainicjowany po ochronie maszyny wirtualnej.

Rozwiązywanie problemu

Aby ponownie ustawić stan replikacji maszyny wirtualnej w dobrej kondycji, możesz wybrać opcję ochrony dysków lub odrzucić ostrzeżenie.

Aby chronić dyski

  1. Przejdź do pozycji Replikowane elementy> Nazwa >maszyny wirtualnejDyski.

  2. Wybierz niechroniony dysk, a następnie wybierz pozycję Włącz replikację:

    Włącz replikację na dyskach maszyn wirtualnych.

Aby odrzucić ostrzeżenie

  1. Przejdź do pozycji Replikowane elementy>nazwa maszyny wirtualnej.

  2. Wybierz ostrzeżenie w sekcji Przegląd , a następnie wybierz przycisk OK.

    Odrzuć ostrzeżenie o nowym dysku.

Maszyna wirtualna usunięta z magazynu została ukończona z informacjami (kod błędu 150225)

Gdy Site Recovery chroni maszynę wirtualną, tworzy łącza na źródłowej maszynie wirtualnej. Po usunięciu ochrony lub wyłączeniu replikacji Site Recovery usuwa te linki w ramach zadania oczyszczania. Jeśli maszyna wirtualna ma blokadę zasobu, zadanie oczyszczania zostanie ukończone wraz z informacjami. Informacje te mówią, że maszyna wirtualna została usunięta z magazynu usługi Recovery Services, ale niektóre nieaktualne łącza nie mogły zostać wyczyszczone na maszynie źródłowej.

To ostrzeżenie można zignorować, jeśli nigdy nie zamierzasz ponownie chronić tej maszyny wirtualnej. Jeśli jednak musisz później chronić tę maszynę wirtualną, wykonaj kroki opisane w tej sekcji, aby wyczyścić linki.

Ostrzeżenie

Jeśli nie wykonasz czyszczenia:

  • Po włączeniu replikacji za pomocą magazynu usługi Recovery Services maszyna wirtualna nie zostanie wyświetlona.
  • Jeśli spróbujesz chronić maszynę wirtualną przy użyciu opcjiOdzyskiwanie po awariiustawień>maszyny> wirtualnej, operacja zakończy się niepowodzeniem, ponieważ nie można włączyć replikacji komunikatu z powodu istniejących nieaktualnych łączy zasobów na maszynie wirtualnej.

Rozwiązywanie problemu

Uwaga

Site Recovery nie usuwa źródłowej maszyny wirtualnej ani nie wpływa na nią w żaden sposób podczas wykonywania tych kroków.

  1. Usuń blokadę z maszyny wirtualnej lub grupy zasobów maszyny wirtualnej. Na przykład na poniższej ilustracji blokada zasobu na maszynie wirtualnej o nazwie MoveDemo musi zostać usunięta:

    Usuń blokadę z maszyny wirtualnej.

  2. Pobierz skrypt, aby usunąć nieaktualną konfigurację Site Recovery.

  3. Uruchom skrypt ,Cleanup-stale-asr-config-Azure-VM.ps1. Podaj identyfikator subskrypcji, grupę zasobów maszyny wirtualnej i nazwę maszyny wirtualnej jako parametry.

  4. Jeśli zostanie wyświetlony monit o podanie poświadczeń platformy Azure, podaj je. Następnie sprawdź, czy skrypt działa bez żadnych błędów.

Replikacja nie jest włączona na maszynie wirtualnej ze nieaktualnymi zasobami (kod błędu 150226)

Możliwe przyczyny

Maszyna wirtualna ma nieaktualną konfigurację z poprzedniej ochrony Site Recovery.

Nieaktywna konfiguracja może wystąpić na maszynie wirtualnej platformy Azure, jeśli włączono replikację dla maszyny wirtualnej platformy Azure przy użyciu Site Recovery, a następnie:

  • Wyłączono replikację, ale źródłowa maszyna wirtualna miała blokadę zasobów.
  • Magazyn Site Recovery został usunięty bez jawnego wyłączenia replikacji na maszynie wirtualnej.
  • Usunięto grupę zasobów zawierającą magazyn Site Recovery bez jawnego wyłączania replikacji na maszynie wirtualnej.

Rozwiązywanie problemu

Uwaga

Site Recovery nie usuwa źródłowej maszyny wirtualnej ani nie wpływa na nią w żaden sposób podczas wykonywania tych kroków.

  1. Usuń blokadę z maszyny wirtualnej lub grupy zasobów maszyny wirtualnej. Na przykład na poniższej ilustracji blokada zasobu na maszynie wirtualnej o nazwie MoveDemo musi zostać usunięta:

    Usuń blokadę z maszyny wirtualnej.

  2. Pobierz skrypt, aby usunąć nieaktualną konfigurację Site Recovery.

  3. Uruchom skrypt ,Cleanup-stale-asr-config-Azure-VM.ps1. Podaj identyfikator subskrypcji, grupę zasobów maszyny wirtualnej i nazwę maszyny wirtualnej jako parametry.

  4. Jeśli zostanie wyświetlony monit o podanie poświadczeń platformy Azure, podaj je. Następnie sprawdź, czy skrypt działa bez żadnych błędów.

Nie można wybrać maszyny wirtualnej lub grupy zasobów w zadaniu włączania replikacji

Problem 1: Grupa zasobów i źródłowa maszyna wirtualna znajdują się w różnych lokalizacjach

Site Recovery obecnie wymaga, aby grupa zasobów regionu źródłowego i maszyny wirtualne znajdowały się w tej samej lokalizacji. Jeśli tak nie jest, nie będzie można znaleźć maszyny wirtualnej ani grupy zasobów podczas próby zastosowania ochrony.

Aby obejść ten problem, można włączyć replikację z maszyny wirtualnej zamiast magazynu usługi Recovery Services. Przejdź do pozycjiŹródłowe właściwości>maszyny wirtualnej>Odzyskiwanie po awarii i włącz replikację.

Problem 2: Grupa zasobów nie jest częścią wybranej subskrypcji

Być może nie można odnaleźć grupy zasobów w momencie ochrony, jeśli grupa zasobów nie jest częścią wybranej subskrypcji. Upewnij się, że grupa zasobów należy do używanej subskrypcji.

Problem 3. Nieaktualna konfiguracja

Jeśli na maszynie wirtualnej platformy Azure istnieje nieaktualna konfiguracja Site Recovery, może nie być widoczna maszyna wirtualna, którą chcesz włączyć na potrzeby replikacji. Ten warunek może wystąpić, jeśli włączono replikację dla maszyny wirtualnej platformy Azure przy użyciu Site Recovery, a następnie:

  • Magazyn Site Recovery został usunięty bez jawnego wyłączenia replikacji na maszynie wirtualnej.
  • Usunięto grupę zasobów zawierającą magazyn Site Recovery bez jawnego wyłączania replikacji na maszynie wirtualnej.
  • Wyłączono replikację, ale źródłowa maszyna wirtualna miała blokadę zasobów.

Rozwiązywanie problemu

Uwaga

Pamiętaj, aby zaktualizować moduł przed użyciem skryptu AzureRM.Resources wymienionego w tej sekcji. Site Recovery nie usuwa źródłowej maszyny wirtualnej ani nie wpływa na nią w żaden sposób podczas wykonywania tych kroków.

  1. Usuń blokadę, jeśli istnieje, z maszyny wirtualnej lub grupy zasobów maszyny wirtualnej. Na przykład na poniższej ilustracji blokada zasobu na maszynie wirtualnej o nazwie MoveDemo musi zostać usunięta:

    Usuń blokadę z maszyny wirtualnej.

  2. Pobierz skrypt, aby usunąć nieaktualną konfigurację Site Recovery.

  3. Uruchom skrypt ,Cleanup-stale-asr-config-Azure-VM.ps1. Podaj identyfikator subskrypcji, grupę zasobów maszyny wirtualnej i nazwę maszyny wirtualnej jako parametry.

  4. Jeśli zostanie wyświetlony monit o podanie poświadczeń platformy Azure, podaj je. Następnie sprawdź, czy skrypt działa bez żadnych błędów.

Nie można wybrać maszyny wirtualnej do ochrony

Możliwa przyczyna

Maszyna wirtualna ma rozszerzenie zainstalowane w stanie niepowodzeniem lub nie odpowiada

Rozwiązywanie problemu

Przejdź do pozycji Rozszerzeniaustawień>maszyn>wirtualnych i sprawdź wszystkie rozszerzenia w stanie niepowodzenia. Odinstaluj wszelkie nieudane rozszerzenie, a następnie spróbuj ponownie, aby chronić maszynę wirtualną.

Stan aprowizacji maszyny wirtualnej jest nieprawidłowy (kod błędu 150019)

Aby włączyć replikację na maszynie wirtualnej, jego stan aprowizacji musi mieć wartość Powodzenie. Wykonaj następujące kroki, aby sprawdzić stan aprowizacji:

  1. W Azure Portal wybierz Eksplorator zasobów z pozycji Wszystkie usługi.
  2. Rozwiń listę Subskrypcje i wybierz swoją subskrypcję.
  3. Rozwiń listę ResourceGroups (Grupy zasobów ) i wybierz grupę zasobów maszyny wirtualnej.
  4. Rozwiń listę Zasoby i wybierz maszynę wirtualną.
  5. Sprawdź pole provisioningState w widoku wystąpienia po prawej stronie.

Rozwiązywanie problemu

  • Jeśli stan provisioningState ma wartość Niepowodzenie, skontaktuj się z pomocą techniczną, aby uzyskać szczegółowe informacje w celu rozwiązania problemu.
  • Jeśli parametr provisioningState to Aktualizowanie, może być wdrażane inne rozszerzenie. Sprawdź, czy na maszynie wirtualnej istnieją jakieś trwające operacje, poczekaj na ich zakończenie, a następnie ponów próbę wykonania zadania Site Recovery zakończonego niepowodzeniem w celu włączenia replikacji.

Nie można wybrać docelowej maszyny wirtualnej

Problem 1: Maszyna wirtualna jest dołączona do sieci, która jest już zamapowana na sieć docelową

Podczas konfigurowania odzyskiwania po awarii, jeśli źródłowa maszyna wirtualna jest częścią sieci wirtualnej, a inna maszyna wirtualna z tej samej sieci wirtualnej jest już mapowana z siecią w docelowej grupie zasobów, pole listy rozwijanej wyboru sieci jest domyślnie niedostępne (wygląda na wygaszone).

Lista wyboru sieci jest niedostępna.

Problem 2: Maszyna wirtualna została wcześniej chroniona, a następnie wyłączona replikacja

Wyłączenie replikacji maszyny wirtualnej nie powoduje usunięcia mapowania sieci. Mapowanie musi zostać usunięte z magazynu usługi Recovery Services, w którym była chroniona maszyna wirtualna. Wybierz magazyn usługi Recovery Services i przejdź do pozycji Zarządzanie>Site Recovery Infrastruktura>dla maszyn wirtualnych platformy> AzureMapowanie sieci.

Usuń mapowanie sieci.

Sieć docelowa skonfigurowana podczas konfigurowania odzyskiwania po awarii może zostać zmieniona po początkowej konfiguracji i po ochronie maszyny wirtualnej. Aby zmodyfikować mapowanie sieci , wybierz nazwę sieci:

Modyfikowanie mapowania sieci.

COM+ lub VSS (kod błędu 151025)

Po wystąpieniu błędu usługi COM+ lub kopiowania woluminów w tle (VSS) zostanie wyświetlony następujący komunikat:

Site Recovery extension failed to install.

Możliwe przyczyny

  • Usługa aplikacji systemu COM+ jest wyłączona.
  • Usługa kopiowania woluminów w tle jest wyłączona.

Rozwiązywanie problemu

Ustaw usługę kopiowania woluminów w tle i aplikację systemową COM+ na tryb automatycznego lub ręcznego uruchamiania.

  1. Otwórz konsolę Usługi w systemie Windows.

  2. Upewnij się, że usługa com+ system application i kopiowania woluminów w tle nie są ustawione na Wyłączone jako typ uruchamiania.

    Sprawdź typ uruchamiania modelu COM oraz systemową aplikację i usługę kopiowania woluminów w tle.

Nieobsługiwany rozmiar dysku zarządzanego (kod błędu 150172)

Po wystąpieniu tego błędu zostanie wyświetlony następujący komunikat:

Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.

Możliwa przyczyna

Dysk jest mniejszy niż obsługiwany rozmiar 1024 MB.

Rozwiązywanie problemu

Upewnij się, że rozmiar dysku mieści się w obsługiwanym zakresie rozmiaru, a następnie spróbuj ponownie wykonać operację.

Ochrona nie jest włączona, gdy program GRUB używa nazwy urządzenia (kod błędu 151126)

Możliwe przyczyny

Pliki konfiguracji Grand Unified Bootloader (GRUB) systemu Linux (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg lub /etc/default/grub) mogą określać rzeczywiste nazwy urządzeń zamiast uniwersalnych unikatowych wartości identyfikatora (UUID) dla root parametrów i resume . Site Recovery wymaga identyfikatorów UUD, ponieważ nazwy urządzeń mogą ulec zmianie. Po ponownym uruchomieniu maszyna wirtualna może nie mieć takiej samej nazwy w trybie failover, co powoduje problemy.

Poniższe przykłady to wiersze z plików GRUB, w których nazwy urządzeń są wyświetlane zamiast wymaganych identyfikatorów UUID:

  • Plik /boot/grub2/grub.cfg:

    linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts

  • Plik: /boot/grub/menu.lst

    kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

Rozwiązywanie problemu

Zastąp każdą nazwę urządzenia odpowiednim identyfikatorem UUID:

  1. Znajdź identyfikator UUID urządzenia, wykonując polecenie blkid <device name>. Przykład:

    blkid /dev/sda1
    /dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
    blkid /dev/sda2
    /dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"
    
  2. Zastąp nazwę urządzenia identyfikatorem UUID w formatach root=UUID=<UUID> i resume=UUID=<UUID>. Na przykład po zamianie wiersz z /boot/grub/menu.lst będzie wyglądać podobnie do następującego wiersza:

    kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314

  3. Ponów próbę ochrony.

Ochrona nie powiodła się, ponieważ urządzenie GRUB nie istnieje (kod błędu 151124)

Możliwa przyczyna

Pliki konfiguracji GRUB (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg lub /etc/default/grub) mogą zawierać parametry rd.lvm.lv lub rd_LVM_LV. Te parametry identyfikują urządzenia Menedżera woluminów logicznych (LVM), które mają zostać odnalezione podczas rozruchu. Jeśli te urządzenia LVM nie istnieją, sam system chroniony nie zostanie uruchomiony i zostanie zablokowany w procesie rozruchu. Ten sam problem będzie również widoczny w przypadku maszyny wirtualnej trybu failover. Oto kilka przykładów:

  • Plik: /boot/grub2/grub.cfg w systemie RHEL7:

    linux16 /vmlinuz-3.10.0-957.el7.x86_64 root=/dev/mapper/rhel_mup--rhel7u6-root ro crashkernel=128M\@64M rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet LANG=en_US.UTF-8

  • Plik: /etc/default/grub w systemie RHEL7:

    GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet

  • Plik: /boot/grub/menu.lst w systemie RHEL6:

    kernel /vmlinuz-2.6.32-754.el6.x86_64 ro root=UUID=36dd8b45-e90d-40d6-81ac-ad0d0725d69e rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=rootvg/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=rootvg/lv_swap rd_NO_DM rhgb quiet

W każdym przykładzie program GRUB musi wykryć dwa urządzenia LVM z nazwami root i swap z grupy rootvgwoluminów .

Rozwiązywanie problemu

Jeśli urządzenie LVM nie istnieje, utwórz je lub usuń odpowiednie parametry z plików konfiguracji GRUB. Następnie spróbuj ponownie włączyć ochronę.

usługa mobilności aktualizacja została zakończona z ostrzeżeniami (kod błędu 151083)

Site Recovery usługa mobilności ma wiele składników, z których jeden jest nazywany sterownikiem filtru. Sterownik filtru jest ładowany do pamięci systemowej tylko podczas ponownego uruchamiania systemu. Za każdym razem, gdy aktualizacja usługa mobilności zawiera zmiany sterownika filtru, maszyna jest aktualizowana, ale nadal jest wyświetlane ostrzeżenie, że niektóre poprawki wymagają ponownego uruchomienia. Zostanie wyświetlone ostrzeżenie, ponieważ poprawki sterowników filtru mogą obowiązywać tylko wtedy, gdy zostanie załadowany nowy sterownik filtru, który występuje tylko podczas ponownego uruchamiania.

Uwaga

Jest to tylko ostrzeżenie. Istniejąca replikacja nadal działa nawet po aktualizacji nowego agenta. Możesz uruchomić ponownie za każdym razem, gdy chcesz korzystać z zalet nowego sterownika filtru, ale stary sterownik filtru nadal działa, jeśli nie uruchamiasz ponownie.

Oprócz sterownika filtru korzyści wynikające z innych ulepszeń i poprawek w aktualizacji usługa mobilności zaczęły obowiązywać bez konieczności ponownego uruchamiania.

Ochrona nie jest włączona, jeśli istnieje dysk zarządzany repliki

Ten błąd występuje, gdy dysk zarządzany repliki już istnieje, bez oczekiwanych tagów, w docelowej grupie zasobów.

Możliwa przyczyna

Ten problem może wystąpić, jeśli maszyna wirtualna była wcześniej chroniona i gdy replikacja została wyłączona, dysk repliki nie został usunięty.

Rozwiązywanie problemu

Usuń dysk repliki zidentyfikowany w komunikacie o błędzie i ponów próbę zadania ochrony, które zakończyło się niepowodzeniem.

Włączanie ochrony nie powiodło się, ponieważ instalator nie może odnaleźć dysku głównego (kod błędu 151137)

Ten błąd występuje w przypadku maszyn z systemem Linux, na których dysk systemu operacyjnego jest szyfrowany przy użyciu usługi Azure Disk Encryption (ADE). Jest to prawidłowy problem tylko w wersji agenta 9.35.

Możliwe przyczyny

Instalator nie może odnaleźć dysku głównego, który hostuje główny system plików.

Rozwiązywanie problemu

Wykonaj następujące kroki, aby rozwiązać ten problem.

  1. Znajdź bity agenta w katalogu /var/lib/waagent na maszynach RHEL i CentOS przy użyciu poniższego polecenia:

    # find /var/lib/ -name Micro\*.gz

    Oczekiwane dane wyjściowe:

    /var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz

  2. Utwórz nowy katalog i zmień katalog na ten nowy.

  3. Wyodrębnij plik agenta znajdujący się w pierwszym kroku tutaj, używając poniższego polecenia:

    tar -xf <Tar Ball File>

  4. Otwórz plik prereq_check_installer.json i usuń następujące wiersze. Zapisz plik po tym.

       {
          "CheckName": "SystemDiskAvailable",
          "CheckType": "MobilityService"
       },
    
  5. Wywołaj instalatora przy użyciu polecenia :

    ./install -d /usr/local/ASR -r MS -q -v Azure

  6. Jeśli instalator zakończy się pomyślnie, ponów próbę włączenia zadania replikacji.

Rozwiązywanie problemów i obsługa zmian czasu na replikowanych serwerach

Ten błąd występuje, gdy czas maszyny źródłowej przechodzi do przodu, a następnie przechodzi z powrotem w krótkim czasie, aby poprawić zmianę. Możesz nie zauważyć zmiany, ponieważ czas jest bardzo szybko poprawiany.

Jak rozwiązać ten problem: aby rozwiązać ten problem, poczekaj, aż czas systemowy przekroczy niesymetryczny czas w przyszłości. Inną opcją jest wyłączenie i ponowne włączenie replikacji, co jest możliwe tylko w przypadku replikacji do przodu (dane replikowane z regionu podstawowego do pomocniczego) i nie ma zastosowania do replikacji odwrotnej (dane replikowane z regionu pomocniczego do regionu podstawowego).

Następne kroki

Replikowanie maszyn wirtualnych platformy Azure do innego regionu platformy Azure