Znane problemy — Usługa Azure Site Recovery w usłudze Azure Stack Hub

W tym artykule opisano znane problemy z usługą Azure Site Recovery w usłudze Azure Stack Hub. Skorzystaj z poniższych sekcji, aby uzyskać szczegółowe informacje na temat bieżących znanych problemów i ograniczeń w usłudze Azure Site Recovery w usłudze Azure Stack Hub.

Obsługiwany maksymalny rozmiar dysku to 1022 GB

W przypadku ochrony maszyny wirtualnej usługa Azure Site Recovery musi dodać dodatkowe 1 GB danych do istniejącego dysku. Ponieważ usługa Azure Stack Hub ma twarde ograniczenie maksymalnego rozmiaru dysku o rozmiarze 1023 GB, maksymalny rozmiar dysku chronionego przez usługę Site Recovery musi być równy lub mniejszy niż 1022.

Podczas próby ochrony maszyny wirtualnej przy użyciu dysku 1023 Gb następuje następujące zachowanie:

• Włączenie ochrony kończy się powodzeniem, ponieważ dysk inicjuje tylko 1 GB jest tworzony i gotowy do użycia. W tym kroku nie ma błędu.

• Replikacja jest blokowana w xx% zsynchronizowane i po pewnym czasie kondycja replikacji staje się krytyczna z powodu błędu AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. Błąd występuje, ponieważ podczas replikacji usługa Site Recovery próbuje zmienić rozmiar dysku inicjowania na 1024 GB i zapisać go. Ta operacja kończy się niepowodzeniem, ponieważ usługa Azure Stack Hub nie obsługuje dysków 1024 GB.

  

• Dysk inicjowania utworzony dla tego dysku (w subskrypcji docelowej) jest nadal o rozmiarze 1 GB, a dziennik aktywności pokazuje kilka błędów zapisu dysku z komunikatem o błędzie Wartość "1024" parametru "diskSizeGb" jest poza zakresem. Wartość "1024" musi należeć do przedziału od "1" do "1023" włącznie.

  

Bieżącym obejściem tego problemu jest utworzenie nowego dysku (z 1022 GB lub mniej), dołączenie go do źródłowej maszyny wirtualnej, skopiowanie danych z dysku 1023 GB na nowy, a następnie usunięcie dysku 1023 GB ze źródłowej maszyny wirtualnej. Po wykonaniu tej procedury, a maszyna wirtualna ma wszystkie dyski mniejsze lub równe 1022 GB, można włączyć ochronę przy użyciu usługi Azure Site Recovery.

Ponowne zabezpieczenie: dostępne miejsca dysków danych na urządzeniu

1. Upewnij się, że maszyna wirtualna urządzenia ma wystarczającą ilość miejsc dysku danych, ponieważ dyski repliki do ponownej ochrony są dołączone do urządzenia.

2. Początkowa dozwolona liczba dysków, które są ponownie chronione w tym samym czasie, wynosi 31. Domyślny rozmiar urządzenia utworzonego na podstawie elementu marketplace jest Standard_DS4_v2, który obsługuje maksymalnie 32 dyski danych, a samo urządzenie używa jednego dysku danych.

3. Jeśli suma chronionych maszyn wirtualnych jest większa niż 31, wykonaj jedną z następujących akcji:

   • Podziel maszyny wirtualne, które wymagają ponownej ochrony na mniejsze grupy, aby upewnić się, że liczba dysków ponownie chronionych w tym samym czasie nie przekracza maksymalnej liczby dysków danych, które obsługuje urządzenie.
   • Zwiększ rozmiar maszyny wirtualnej urządzenia usługi Azure Site Recovery.

   Uwaga

   Nie testujemy i nie weryfikujemy dużych jednostek SKU maszyny wirtualnej dla maszyny wirtualnej urządzenia.

4. Jeśli próbujesz ponownie chronić maszynę wirtualną, ale na urządzeniu nie ma wystarczającej liczby miejsc do przechowywania dysków replikacji, zostanie wyświetlony komunikat o błędzie Wystąpił błąd wewnętrzny. Możesz sprawdzić liczbę dysków danych aktualnie na urządzeniu lub zalogować się do urządzenia, przejść do Podgląd zdarzeń i otworzyć dzienniki usługi Azure Site Recovery w obszarze Dzienniki aplikacji i usług:

   

   

   Znajdź najnowsze ostrzeżenie, aby zidentyfikować problem.

Wersja jądra maszyny wirtualnej z systemem Linux nie jest obsługiwana

1. Sprawdź wersję jądra, uruchamiając polecenie uname -r.

   

   Aby uzyskać więcej informacji na temat obsługiwanych wersji jądra systemu Linux, zobacz Macierz platformy Azure do pomoc techniczna platformy Azure.

2. W przypadku obsługiwanej wersji jądra tryb failover, który powoduje ponowne uruchomienie maszyny wirtualnej, może spowodować, że maszyna wirtualna przełączona w tryb failover zostanie zaktualizowana do nowszej wersji jądra, która może nie być obsługiwana. Aby uniknąć aktualizacji z powodu ponownego uruchomienia maszyny wirtualnej trybu failover, uruchom polecenie sudo apt-mark hold linux-image-azure linux-headers-azure , aby aktualizacja wersji jądra mogła kontynuować.

3. W przypadku nieobsługiwanej wersji jądra sprawdź starszą wersję jądra, do której można wycofać polecenie, uruchamiając odpowiednie polecenie dla maszyny wirtualnej:

   • Debian/Ubuntu: dpkg --list | grep linux-image

   Na poniższej ilustracji przedstawiono przykład maszyny wirtualnej z systemem Ubuntu w wersji 5.4.0-1103-azure, która nie jest obsługiwana. Po uruchomieniu polecenia zobaczysz obsługiwaną wersję 5.4.0-1077-azure, która jest już zainstalowana na maszynie wirtualnej. Dzięki tym informacjom można przywrócić obsługiwaną wersję.

   

4. Wróć do obsługiwanej wersji jądra, wykonując następujące kroki:

   1. Najpierw utwórz kopię pliku /etc/default/grub w przypadku wystąpienia błędu, na przykład sudo cp /etc/default/grub /etc/default/grub.bak.

   2. Następnie zmodyfikuj /etc/default/grub , aby ustawić GRUB_DEFAULT na poprzednią wersję, której chcesz użyć. Możesz mieć coś podobnego do GRUB_DEFAULT="Opcje zaawansowane dla systemu Ubuntu Ubuntu z systemem Linux>5.4.0-1077-azure".

      

   3. Wybierz pozycję Zapisz , aby zapisać plik, a następnie wybierz pozycję Zakończ.

   4. Uruchom polecenie sudo update-grub , aby zaktualizować plik grub.

   5. Na koniec uruchom ponownie maszynę wirtualną i kontynuuj wycofywanie do obsługiwanej wersji jądra.

5. Jeśli nie masz starej wersji jądra, do której można wycofać, poczekaj na aktualizację agenta mobilności, aby jądro mogło być obsługiwane. Aktualizacja zostanie ukończona automatycznie, jeśli jest gotowa i możesz sprawdzić wersję w portalu, aby potwierdzić:

   

Ponowne włączanie ponownej synchronizacji ręcznej nie jest jeszcze obsługiwane

Po zakończeniu ponownej ochrony zadania replikacja jest uruchamiana w sekwencji. Podczas replikacji mogą wystąpić przypadki wymagające ponownej synchronizacji, co oznacza, że nowa replikacja początkowa jest wyzwalana w celu zsynchronizowania wszystkich zmian.

Istnieją dwa typy ponownej synchronizacji:

• Automatyczna ponowna synchronizacja. Nie wymaga żadnej akcji użytkownika i jest wykonywana automatycznie. Użytkownicy mogą zobaczyć niektóre zdarzenia wyświetlane w portalu:

  

• Ręczna ponowna synchronizacja. Wymaga, aby akcja użytkownika wyzwalała ponowną synchronizację ręcznie i jest wymagana w następujących wystąpieniach:

  • Brak konta magazynu wybranego do ponownego włączania ochrony.

  • Brak dysku replikacji na urządzeniu.

  • Zapis replikacji przekracza pojemność dysku replikacji na urządzeniu.

    Napiwek

    Możesz również znaleźć ręczne przyczyny ponownej synchronizacji w bloku zdarzeń, aby ułatwić podjęcie decyzji, czy wymagana jest ręczna ponowna synchronizacja.

Znane problemy związane z automatyzacją programu PowerShell

• Jeśli pozostawisz i $failbackExtensionName pozostawisz $failbackPolicyName wartość pustą lub null, ponowne włączenie ochrony może zakończyć się niepowodzeniem. Zobacz poniższe przykłady:

  

  

• Zawsze określ wartości $failbackPolicyName i $failbackExtensionName, jak pokazano w poniższym przykładzie:

  $failbackPolicyName = "failback-default-replication-policy"
  $failbackExtensionName = "default-failback-extension"
  $parameters = @{
      "properties" = @{
          "customProperties" = @{
              "instanceType" = "AzStackToAzStackFailback"
              "applianceId" = $applianceId
              "logStorageAccountId" = $LogStorageAccount.Id
              "policyName" = $failbackPolicyName
              "replicationExtensionName" = $failbackExtensionName
          }
      }
  }
  $result = Invoke-AzureRmResourceAction -Action "reprotect" ` -ResourceId $protectedItemId ` -Force -Parameters $parameters 
  

Ostrzeżenie agenta usługa mobilności

Podczas replikowania wielu maszyn wirtualnych może zostać zmieniona kondycja chronionego elementu na błąd Ostrzeżenie w zadaniach usługi Site Recovery.

Ten komunikat o błędzie powinien być ostrzeżeniem i nie jest problemem blokującym dla rzeczywistych procesów replikacji lub trybu failover.

Napiwek

Możesz sprawdzić stan odpowiedniej maszyny wirtualnej, aby upewnić się, że jest w dobrej kondycji.

Usunięcie maszyny wirtualnej urządzenia (źródła) blokuje usunięcie magazynu (docelowego)

Aby usunąć magazyn usługi Azure Site Recovery w miejscu docelowym, należy najpierw usunąć wszystkie chronione maszyny wirtualne. Jeśli najpierw usuniesz maszynę wirtualną urządzenia, magazyn usługi Site Recovery zablokuje usunięcie chronionych zasobów i próba usunięcia samego magazynu również zakończy się niepowodzeniem. Usunięcie grupy zasobów kończy się również niepowodzeniem, a jedynym sposobem usunięcia magazynu jest usunięcie subskrypcji użytkownika usługi Azure Stack Hub, w której jest tworzony magazyn.

Aby uniknąć tego problemu, przed usunięciem maszyny wirtualnej urządzenia najpierw usuń ochronę ze wszystkich elementów w magazynie. Dzięki temu magazyn może ukończyć oczyszczanie zasobów na urządzeniu (po stronie źródłowej). Po usunięciu chronionych elementów można usunąć magazyn i usunąć maszynę wirtualną urządzenia.

Następne kroki

• Usługa Azure Site Recovery w usłudze Azure Stack Hub
• Planowanie pojemności usługi Azure Site Recovery w usłudze Azure Stack Hub