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ż tworzony jest dysk o pojemności tylko 1 GB, który jest gotowy do użycia. W tym kroku nie ma błędu.

• Replikacja jest blokowana na xx% zsynchronizowane, a po pewnym czasie stan replikacji stanie się krytyczny z błędem 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 inicjujący utworzony dla tego dysku (w subskrypcji docelowej) jest nadal o rozmiarze 1 GB, a dziennik aktywności pokazuje kilka niepowodzeń operacji zapisu na dysku z komunikatem o błędzie Wartość "1024" parametru "disk.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 danych: sloty dysków danych dostępne w urządzeniu

1. Upewnij się, że maszyna wirtualna ma wystarczającą ilość gniazd dysków danych, ponieważ dyski repliki do ponownej ochrony są dołączone do niej.

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 witryny Marketplace to 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.

   Notatka

   Nie testujemy i nie weryfikujemy dużych SKU VM 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 dla 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 azure to Azure support matrix.

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 w wyniku ponownego uruchomienia maszyny wirtualnej po przełączeniu awaryjnym, uruchom polecenie sudo apt-mark hold linux-image-azure linux-headers-azure, aby aktualizacja wersji jądra mogła się odbyć.

3. W przypadku nieobsługiwanej wersji jądra sprawdź, czy istnieje starsza wersja jądra, do której można się cofnąć, uruchamiając odpowiednie polecenie dla swojej 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ę /etc/default/grub na wypadek 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 Zapisz, aby zapisać plik, a następnie wybierz Zakończ.

   4. Uruchom 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żesz wycofać się, poczekaj na aktualizację agenta mobilności, aby jądro mogło być wspierane. 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 zadania ponownej ochrony, 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 ponownej 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 $failbackPolicyName i $failbackExtensionName puste lub null, ponowne włączenie ochrony może zakończyć się niepowodzeniem. Zobacz następujące przykłady:

  

  

• Zawsze określ $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ługi mobilności

Podczas replikowania wielu maszyn wirtualnych może zostać wyświetlony błąd Kondycja chronionego elementu zmieniona na 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 skarbca jest usunięcie subskrypcji użytkownika platformy Azure Stack Hub, w której utworzono skarbiec.

Aby uniknąć tego problemu, najpierw usuń ochronę ze wszystkich elementów w skarbcu, zanim usuniesz maszynę wirtualną aplikacji. Umożliwia to magazynowi ukończenie oczyszczania zasobów na urządzeniu (po stronie źródła). Po usunięciu chronionych elementów można usunąć magazyn i usunąć maszynę wirtualną urządzenia.

Następne kroki

• Azure Site Recovery na platformie Azure Stack Hub
• planowanie pojemności usługi Azure Site Recovery w usłudze Azure Stack Hub