Rozwiązywanie problemów z błędami z replikacją maszyny wirtualnej z platformy Azure do platformy 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.

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 wymaganych rozmiarów 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 znajdują się na maszynie wirtualnej, zadanie włączenia replikacji dla usługi 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 odłączonym, 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 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 błędów 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 to 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 nie znaleziono DigiCert_Global_Root_CA, 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 symlinki 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ą pliku 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 usługi Site Recovery działała, łączność wychodząca z określonymi adresami URL jest wymagana z maszyny wirtualnej. Jeśli maszyna wirtualna znajduje się za zaporą lub używa reguł sieciowej grupy zabezpieczeń w celu 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 usługi Site Recovery z powodu błędu rozpoznawania nazw domen (DNS).
• Ten problem występuje częściej podczas ponownego włączania ochrony, gdy maszyna wirtualna została przełączona 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 Ustawienia maszyn wirtualnych i wybierz pozycję Sieć.
3. W obszarze Sieć wirtualna/podsieć wybierz link, aby otworzyć stronę zasobu sieci wirtualnej.
4. Przejdź do 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 linii lokacji między siecią odzyskiwania po awarii a usługą DNS.

Uwaga

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

Problem 2. Konfiguracja usługi Site Recovery nie powiodła się (151196)

Możliwa przyczyna

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

Rozwiązywanie problemu

Usługa Azure Site Recovery wymaga dostępu do zakresów adresów IP platformy Microsoft 365 na potrzeby uwierzytelniania. Jeśli używasz reguł/serwera proxy sieciowej grupy zabezpieczeń platformy Azure 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 Microsoft Entra, aby umożliwić dostęp do identyfikatora Entra firmy Microsoft. Nie obsługujemy już reguł sieciowej grupy zabezpieczeń opartej na adresach IP.

Problem 3. Konfiguracja usługi 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 używa 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 spróbuj ponownie wykonać operację.

• Windows: dołączanie i inicjowanie nowego dysku.
• Linux: zainicjuj nowy dysk danych w systemie Linux.

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 wirtualnej Dyski.

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

   

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.

   

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

Gdy usługa Site Recovery chroni maszynę wirtualną, tworzy łącza na źródłowej maszynie wirtualnej. Po usunięciu ochrony lub wyłączeniu replikacji usługa 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 linki 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ć łącza.

Ostrzeżenie

Jeśli nie wykonasz oczyszczania:

• 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 maszyny> wirtualnej Ustawienia> Disaster Recovery, operacja zakończy się niepowodzeniem z powodu nieaktywnego łącza zasobów na maszynie wirtualnej.

Rozwiązywanie problemu

Uwaga

Usługa 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:

   

2. Pobierz skrypt, aby usunąć nieaktualną konfigurację usługi 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 nieaktywną konfigurację z poprzedniej ochrony usługi Site Recovery.

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

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

Rozwiązywanie problemu

Uwaga

Usługa 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:

   

2. Pobierz skrypt, aby usunąć nieaktualną konfigurację usługi 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

Usługa Site Recovery wymaga obecnie, 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 odnaleźć 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

Jeśli grupa zasobów nie jest częścią wybranej subskrypcji, może nie być możliwe znalezienie grupy zasobów w momencie ochrony. 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 usługi 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 usługi Site Recovery, a następnie:

• Magazyn usługi Site Recovery został usunięty bez jawnego wyłączania replikacji na maszynie wirtualnej.
• Usunięto grupę zasobów zawierającą magazyn usługi 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. Usługa 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:

   

2. Pobierz skrypt, aby usunąć nieaktualną konfigurację usługi 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 niepowodzenia lub nie odpowiada

Rozwiązywanie problemu

Przejdź do pozycji Maszyny> wirtualne Ustawienia> Rozszerzenia i sprawdź, czy istnieją 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 witrynie Azure Portal wybierz Eksplorator zasobów z pozycji Wszystkie usługi.
2. Rozwiń listę Subskrypcje i wybierz swoją subskrypcję.
3. Rozwiń listę 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 to Niepowodzenie, skontaktuj się z pomocą techniczną, aby uzyskać szczegółowe informacje, aby rozwiązać problem.
• Jeśli parametr provisioningState to Aktualizowanie, może zostać wdrożone inne rozszerzenie. Sprawdź, czy na maszynie wirtualnej istnieją jakieś trwające operacje, poczekaj na ich zakończenie, a następnie spróbuj ponownie wykonać zadanie usługi Site Recovery zakończone niepowodzeniem, aby włączyć replikację.

Nie można wybrać docelowej maszyny wirtualnej

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

Podczas konfiguracji 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 (jest wyświetlane wygaszone).

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>infrastrukturą>usługi Site Recovery dla mapowania sieci maszyn wirtualnych platformy>Azure.

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:

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

Po wystąpieniu błędu com+ lub usługi 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ę com+ System Application and Volume Shadow Copy Service na automatyczny lub ręczny tryb uruchamiania.

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

2. Upewnij się, że usługa com+ System Application and Volume Shadow Copy Service nie jest ustawiona na Wyłączone jako typ uruchamiania.

   

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 rozmiarów, 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/grub2/grub2 lub /etc/default/grub/ grub) mogą określać rzeczywiste nazwy urządzeń zamiast uniwersalnych unikatowych wartości identyfikatora (UUID) dla root parametrów i resume . Usługa Site Recovery wymaga identyfikatorów UUID, ponieważ nazwy urządzeń mogą ulec zmianie. Po ponownym uruchomieniu maszyna wirtualna może nie wymyślić tej 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>. Na 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 swoim 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/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ą, 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 o nazwach 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 zakończyła się z ostrzeżeniami (kod błędu 151083)

Usługa 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 nowy sterownik filtru jest ładowany, co ma miejsce 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 zawsze, 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, a 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 spróbuj ponownie wykonać zadanie 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 9.35 agenta.

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 katalog.

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 ze zmianami czasu na replikowanych serwerach i obsługa ich

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 poprawiony.

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 do przekazywania replikacji (dane replikowane z regionu podstawowego do pomocniczego) i nie ma zastosowania do replikacji odwrotnej (dane replikowane z pomocniczego do regionu podstawowego).

Następne kroki

Replikowanie maszyn wirtualnych platformy Azure do innego regionu świadczenia usługi Azure.