Hyper-V to Azure disaster recovery architecture (Architektura odzyskiwania po awarii z maszyn wirtualnych funkcji Hyper-V na platformę Azure)

W tym artykule opisano architekturę i procesy używane podczas replikacji, przełączania w tryb failover i odzyskiwania maszyn wirtualnych funkcji Hyper-V między lokalnymi hostami funkcji Hyper-V a platformą Azure przy użyciu usługi Azure Site Recovery .

Hosty funkcji Hyper-V można opcjonalnie zarządzać w chmurach prywatnych programu System Center Virtual Machine Manager (VMM).

Składniki architektury — funkcja Hyper-V bez programu VMM

Poniższa tabela i grafika zawierają ogólny widok składników używanych do replikacji funkcji Hyper-V na platformę Azure, gdy hosty funkcji Hyper-V nie są zarządzane przez program VMM.

Składnik	Wymaganie	Szczegóły
Azure	Subskrypcja platformy Azure, konto usługi Azure Storage i sieć platformy Azure.	Replikowane dane z lokalnych obciążeń maszyn wirtualnych są przechowywane na koncie magazynu. Maszyny wirtualne platformy Azure są tworzone przy użyciu replikowanych danych obciążenia w przypadku przejścia w tryb failover z lokacji lokalnej. Maszyny wirtualne platformy Azure nawiązują połączenie z siecią wirtualną platformy Azure, gdy są tworzone.
Funkcja Hyper-V	Podczas wdrażania usługi Site Recovery hosty i klastry funkcji Hyper-V są zbierane w lokacjach funkcji Hyper-V. Na każdym autonomicznym hoście funkcji Hyper-V lub w każdym węźle klastra funkcji Hyper-V należy zainstalować dostawcę usługi Azure Site Recovery i agenta usługi Recovery Services.	Dostawca koordynuje replikację za pomocą usługi Site Recovery przez Internet. Agent usługi Recovery Services obsługuje replikację danych. Komunikacja zarówno ze strony dostawcy, jak i agenta, jest bezpieczna i szyfrowana. Zreplikowane dane w usłudze Azure Storage również są szyfrowane.
Maszyny wirtualne funkcji Hyper-V	Co najmniej jedna maszyna wirtualna uruchomiona na funkcji Hyper-V.	Nic nie musi być jawnie zainstalowane na maszynach wirtualnych.

Architektura funkcji Hyper-V do platformy Azure (bez programu VMM)

Składniki architektury — funkcja Hyper-V z programem VMM

Poniższa tabela i grafika przedstawiają ogólny widok składników używanych do replikacji funkcji Hyper-V na platformę Azure, gdy hosty funkcji Hyper-V są zarządzane w chmurach programu VMM.

Składnik	Wymaganie	Szczegóły
Azure	Subskrypcja platformy Azure, konto usługi Azure Storage i sieć platformy Azure.	Replikowane dane z lokalnych obciążeń maszyn wirtualnych są przechowywane na koncie magazynu. Maszyny wirtualne platformy Azure są tworzone przy użyciu replikowanych danych po przejściu w tryb failover z lokacji lokalnej. Maszyny wirtualne platformy Azure nawiązują połączenie z siecią wirtualną platformy Azure, gdy są tworzone.
Serwer VMM	Serwer VMM ma co najmniej jedną chmurę zawierającą hosty funkcji Hyper-V.	Dostawca usługi Site Recovery jest instalowany na serwerze programu VMM w celu organizowania replikacji za pomocą usługi Site Recovery i rejestrowania serwera w magazynie usługi Recovery Services.
Host funkcji Hyper-V	Co najmniej jeden host/klaster funkcji Hyper-V zarządzany przez program VMM.	Agent usługi Recovery Services jest instalowany na każdym hoście lub w węźle klastra funkcji Hyper-V.
Maszyny wirtualne funkcji Hyper-V	Co najmniej jedna maszyna wirtualna uruchomiona na serwerze hosta funkcji Hyper-V.	Niczego nie trzeba jawnie instalować na maszynach wirtualnych.
Sieć	Sieci logiczne i maszyn wirtualnych skonfigurowane na serwerze VMM. Sieć maszyn wirtualnych powinna być połączona z siecią logiczną skojarzona z chmurą.	Sieci maszyn wirtualnych są mapowane na sieci wirtualne platformy Azure. Po utworzeniu maszyn wirtualnych platformy Azure po przejściu w tryb failover są one dodawane do sieci platformy Azure mapowanej na sieć maszyn wirtualnych.

Architektura funkcji Hyper-V do platformy Azure (z programem VMM)

Konfigurowanie wychodzącej łączności sieciowej

Aby usługa Site Recovery działała zgodnie z oczekiwaniami, należy zmodyfikować wychodzącą łączność sieciową, aby umożliwić replikację środowiska.

Uwaga

Usługa Site Recovery nie obsługuje sterowania łącznością sieciową za pomocą uwierzytelniającego serwera proxy.

Połączenia ruchu wychodzącego dla adresów URL

Jeśli używasz serwera proxy zapory opartego na adresach URL do kontrolowania łączności wychodzącej, zezwól na dostęp do następujących adresów URL:

Nazwa/nazwisko	Handlowych	Instytucje rządowe	Opis
Storage	*.blob.core.windows.net	*.blob.core.usgovcloudapi.net	Umożliwia zapisanie danych z maszyny wirtualnej na koncie magazynu pamięci podręcznej znajdującym się w regionie źródłowym.
Identyfikator usługi Microsoft Entra	login.microsoftonline.com	login.microsoftonline.us	Umożliwia autoryzację i uwierzytelnianie przy użyciu adresów URL usługi Site Recovery.
Replikacja	*.hypervrecoverymanager.windowsazure.com	*.hypervrecoverymanager.windowsazure.com	Umożliwia komunikację między maszyną wirtualną a usługą Site Recovery.
Service Bus	*.servicebus.windows.net	*.servicebus.usgovcloudapi.net	Umożliwia maszynie wirtualnej zapisywanie danych monitorowania i danych diagnostycznych usługi Site Recovery.

Proces replikacji

Proces replikacji i odzyskiwania

Włączanie ochrony

1. Po włączeniu ochrony dla maszyny wirtualnej funkcji Hyper-V, w witrynie Azure Portal lub środowisku lokalnym, zostanie uruchomione zadanie Włącz ochronę.
2. To zadanie sprawdza, czy maszyna spełnia wymagania wstępne, a następnie wywołuje metodę CreateReplicationRelationship, aby skonfigurować replikację za pomocą określonych ustawień.
3. Zadanie uruchamia replikację początkową, wywołując metodę StartReplication, aby zainicjować pełną replikację maszyny wirtualnej i wysłać dyski wirtualne maszyny wirtualnej na platformę Azure.
4. Zadanie można monitorować na karcie Zadania .

Początkowa replikacja danych

1. Po wyzwoleniu replikacji początkowej wykonywana jest migawka maszyny wirtualnej funkcji Hyper-V.
2. Wirtualne dyski twarde na maszynie wirtualnej są replikowane pojedynczo, dopóki nie zostaną skopiowane na platformę Azure. Może to chwilę potrwać w zależności od rozmiaru maszyny wirtualnej i przepustowości sieci. Dowiedz się, jak zwiększyć przepustowość sieci.
3. Jeśli zmiany dysku wystąpią podczas replikacji początkowej, monitor replikacji repliki funkcji Hyper-V śledzi zmiany jako dzienniki replikacji funkcji Hyper-V (hrl). Te pliki dziennika znajdują się w tym samym folderze co dyski. Każdy dysk ma skojarzony plik hrl, który jest wysyłany do pomocniczego magazynu. Pliki migawki i dziennika zużywają zasoby dysku w trakcie replikacji początkowej.
4. Po zakończeniu replikacji początkowej migawka maszyny wirtualnej jest usuwana.
5. Różnicowe zmiany dysku w dzienniku są synchronizowane i scalane z dyskiem nadrzędnym.

Finalizowanie procesu ochrony

1. Po zakończeniu replikacji początkowej zostanie uruchomiona ochrona Finalizowanie w zadaniu maszyny wirtualnej. Konfiguruje sieci i inne ustawienia po replikacji, tak aby maszyna wirtualna była chroniona.
2. Na tym etapie możesz sprawdzić ustawienia maszyny wirtualnej, aby upewnić się, że jest gotowa do pracy w trybie failover. Możesz uruchomić próbne odzyskiwanie po awarii (test pracy w trybie failover) dla maszyny wirtualnej, aby sprawdzić, czy przechodzi w tryb failover zgodnie z oczekiwaniami.

Replikacja różnicowa

1. Po replikacji początkowej rozpoczyna się replikacja różnicowa zgodnie z zasadami replikacji.
2. Monitor replikacji funkcji Hyper-V Replica śledzi zmiany wirtualnego dysku twardego jako pliki hrl. Z każdym dyskiem skonfigurowanym pod kątem replikacji jest skojarzony plik hrl.
3. Dziennik jest wysyłany do konta magazynu klienta. Gdy dziennik jest przesyłany na platformę Azure, zmiany na dysku podstawowym są śledzone w innym pliku dziennika w tym samym folderze.
4. Podczas replikacji początkowej i różnicowej można monitorować maszynę wirtualną w witrynie Azure Portal.

Proces ponownej synchronizacji

1. Jeśli replikacja różnicowa nie powiedzie się, a pełna replikacja byłaby kosztowna pod względem przepustowości lub czasu, maszyna wirtualna jest oznaczana do ponownej synchronizacji.

   • Jeśli na przykład pliki hrl będą zajmować 50% rozmiaru dysku, to maszyna wirtualna zostanie oznaczona do ponownej synchronizacji.
   • Domyślnie ponowna synchronizacja ma być uruchamiana automatycznie poza godzinami pracy.

2. Ponowne synchronizowanie wysyła tylko dane różnicowe.

   • Minimalizuje ilość danych wysyłanych przez obliczenia sum kontrolnych źródłowych i docelowych maszyn wirtualnych.
   • Używa on algorytmu fragmentowania stałego bloku, w którym pliki źródłowe i docelowe są podzielone na stałe fragmenty.
   • Są generowane sumy kontrolne dla każdego fragmentu. Są one porównywane w celu określenia, które bloki ze źródła należy zastosować do obiektu docelowego.

3. Po ukończeniu ponownej synchronizacji replikacja różnicowa powinna zostać wznowiona.

4. Jeśli nie chcesz czekać na domyślną ponowną synchronizację poza godzinami, możesz ponownie zsynchronizować maszynę wirtualną ręcznie. Jeśli na przykład wystąpi awaria. W tym celu w witrynie Azure Portal wybierz ponownie synchronizację maszyny wirtualnej.>

   

Ponów próbę procesu

Jeśli wystąpi błąd replikacji, może zostać użyty wbudowany mechanizm ponawiania. Ponowienie próby jest klasyfikowane zgodnie z opisem w tabeli.

Kategoria	Szczegóły
Błąd nieodwracalny	Nie jest podejmowana próba ponowienia. Maszyna wirtualna będzie mieć stan Krytyczny i będzie wymagana interwencja administratora. Przykłady tych błędów obejmują uszkodzony łańcuch wirtualnego dysku twardego, nieprawidłowy stan repliki maszyny wirtualnej, błędy uwierzytelniania sieci, błędy autoryzacji i nie znaleziono błędów maszyny wirtualnej (w przypadku autonomicznych serwerów funkcji Hyper-V.
Błędy odwracalne	Ponowne próby są wykonywane co interwał replikacji przy użyciu wycofywania wykładniczego zwiększającego interwał ponawiania prób od początku pierwszej próby o 1, 2, 4, 8 i 10 minut. Jeśli błąd będzie się powtarzać, ponowne próby będą wykonywane co 30 minut. Przykłady z nich obejmują błędy sieci, błędy niskiego dysku i niskie warunki pamięci.

Proces pracy w trybie failover i podczas powrotu po awarii

1. Planowane lub nieplanowane przejście w tryb failover można uruchomić z maszyn wirtualnych funkcji Hyper-V do platformy Azure. Jeśli zostanie uruchomione planowane przejście w tryb failover, źródłowe maszyny wirtualne zostaną wyłączone w celu zapewnienia, że nie będzie miała miejsca utrata danych. Uruchom nieplanowany tryb failover, jeśli lokacja główna nie jest dostępna.
2. W tryb failover można przełączyć pojedynczą maszynę lub można utworzyć plany odzyskiwania, aby zaaranżować tryb failover na wielu maszynach.
3. Uruchamiasz tryb failover. Po zakończeniu pierwszego etapu pracy w trybie failover powinno być możliwe wyświetlenie utworzonych maszyn wirtualnych repliki na platformie Azure. Jeśli jest to wymagane, do maszyny wirtualnej można przypisać publiczny adres IP.
4. Następnie zatwierdź tryb failover, aby rozpocząć uzyskiwanie dostępu do obciążenia z repliki maszyny wirtualnej platformy Azure.

Po ponownym uruchomieniu infrastruktury lokalnej możesz wrócić po awarii. Powrót po awarii występuje w trzech etapach:

1. Uruchom planowane przejście w tryb failover z platformy Azure do lokacji lokalnej:

   • Zminimalizuj przestoje: jeśli używasz tej opcji, usługa Site Recovery synchronizuje dane przed przejściem w tryb failover. Sprawdza ona zmienione bloki danych i pobiera je do lokacji lokalnej, podczas gdy maszyna wirtualna platformy Azure działa, minimalizując przestój. Po ręcznym określeniu, że przejście w tryb failover powinno zostać zakończone, maszyna wirtualna platformy Azure zostanie zamknięta, zostaną skopiowane wszelkie końcowe zmiany różnicowe, a tryb failover zostanie uruchomiony.
   • Pełne pobieranie: z tą opcją dane są synchronizowane podczas pracy w trybie failover. Ta opcja pobiera cały dysk. Jest to szybsze, ponieważ nie są obliczane sumy kontrolne, ale jest więcej przestojów. Użyj tej opcji, jeśli od jakiegoś czasu uruchomiono replikę maszyn wirtualnych platformy Azure lub jeśli lokalna maszyna wirtualna została usunięta.
   • Tworzenie maszyny wirtualnej: możesz wybrać opcję powrotu po awarii do tej samej maszyny wirtualnej lub do alternatywnej maszyny wirtualnej. Możesz określić, że usługa Site Recovery powinna utworzyć maszynę wirtualną, jeśli jeszcze nie istnieje.

2. Po zakończeniu synchronizacji początkowej należy wybrać opcję ukończenia pracy w trybie failover. Po zakończeniu możesz zalogować się do lokalnej maszyny wirtualnej, aby sprawdzić, czy wszystko działa zgodnie z oczekiwaniami. W witrynie Azure Portal widać, że maszyny wirtualne platformy Azure zostały zatrzymane.

3. Następnie należy zatwierdzić przejście w tryb failover, aby zakończyć pracę, i ponownie rozpocząć uzyskiwanie dostępu do obciążenia z lokalnej maszyny wirtualnej.

4. Po powrocie obciążeń po awarii włączysz replikację odwrotną, aby lokalne maszyny wirtualne ponownie replikowały na platformę Azure.

Następne kroki

Postępuj zgodnie z tym samouczkiem , aby rozpocząć pracę z replikacją funkcji Hyper-V do platformy Azure.