Udostępnij za pośrednictwem

Architektura odzyskiwania po awarii z programu VMware do platformy Azure — klasyczna

  • Artykuł

W tym artykule opisano architekturę i procesy używane podczas wdrażania replikacji odzyskiwania po awarii, trybu failover i odzyskiwania maszyn wirtualnych VMware między lokalną lokacją programu VMware a platformą Azure przy użyciu usługi Azure Site Recovery — wersja klasyczna.

Aby uzyskać szczegółowe informacje na temat zmodernizowanej architektury, zobacz ten artykuł

Składniki architektury

Poniższa tabela i grafika przedstawiają ogólny widok składników używanych do odzyskiwania po awarii maszyn wirtualnych VMware/maszyn fizycznych na platformie Azure.

Składnik Wymaganie Szczegóły
Azure Subskrypcja platformy Azure, konto usługi Azure Storage na potrzeby pamięci podręcznej, dysku zarządzanego i sieci platformy Azure. Replikowane dane z lokalnych maszyn wirtualnych są przechowywane w usłudze Azure Storage. Maszyny wirtualne platformy Azure są tworzone przy użyciu replikowanych danych podczas uruchamiania trybu failover ze środowiska lokalnego na platformę Azure. Maszyny wirtualne platformy Azure nawiązują połączenie z siecią wirtualną platformy Azure, gdy są tworzone.
Maszyna serwera konfiguracji Pojedyncza maszyna lokalna. Zalecamy uruchomienie go jako maszyny wirtualnej VMware, którą można wdrożyć z pobranego szablonu OVF.

Na maszynie są uruchamiane wszystkie lokalne składniki usługi Site Recovery, które obejmują serwer konfiguracji, serwer przetwarzania i główny serwer docelowy.		 Serwer konfiguracji: koordynuje komunikację między środowiskiem lokalnym a platformą Azure i zarządza replikacją danych.

Serwer przetwarzania: instalowany domyślnie na serwerze konfiguracji. Odbiera dane replikacji; optymalizuje ją za pomocą buforowania, kompresji i szyfrowania; wysyła go do usługi Azure Storage. Serwer przetwarzania instaluje także usługę Azure Site Recovery Mobility Service na maszynach wirtualnych, które będą replikowane, i przeprowadza automatycznie odnajdywanie lokalnych maszyn wirtualnych. W miarę rozwoju wdrożenia można dodać dodatkowe, oddzielne serwery przetwarzania, aby obsługiwać większy ruch związany z replikacją.

Główny serwer docelowy: instalowany domyślnie na serwerze konfiguracji. Obsługuje dane replikacji podczas powrotu po awarii z platformy Azure. W przypadku dużych wdrożeń można dodać dodatkowy, oddzielny główny serwer docelowy na potrzeby powrotu po awarii.
Serwery VMware Maszyny wirtualne VMware są hostowane na lokalnych serwerach vSphere ESXi. Zalecamy serwer vCenter do zarządzania hostami. Podczas wdrażania usługi Site Recovery serwery VMware są dodawane do magazynu usługi Recovery Services.
Zreplikowane maszyny Usługa mobilności jest instalowana na każdej replikowanej maszynie wirtualnej VMware. Zalecamy zezwolenie na automatyczną instalację z serwera przetwarzania. Alternatywnie możesz zainstalować usługę ręcznie lub użyć metody zautomatyzowanego wdrażania, takiej jak program Configuration Manager.

Diagram przedstawiający relacje architektury replikacji Z programu VMware do platformy Azure.

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 maszyn wirtualnych VMware/fizycznych korzystających z architektury klasycznej nie obsługuje używania serwera proxy uwierzytelniania do kontrolowania łączności sieciowej. To samo jest obsługiwane w przypadku korzystania z zmodernizowanej architektury.

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 Reklama 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.
Microsoft Entra ID 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.us 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.

Aby uzyskać wyczerpującą listę adresów URL, które mają być filtrowane pod kątem komunikacji między lokalną infrastrukturą usługi Azure Site Recovery i usługami platformy Azure, zapoznaj się z sekcją wymagań sieciowych w artykule dotyczącym wymagań wstępnych.

Proces replikacji

  1. Po włączeniu replikacji maszyny wirtualnej rozpoczyna się replikacja początkowa do usługi Azure Storage przy użyciu określonych zasad replikacji. Należy zwrócić uwagę na następujące kwestie:

    • W przypadku maszyn wirtualnych VMware replikacja jest na poziomie bloku, niemal ciągła przy użyciu agenta usługa mobilności uruchomionego na maszynie wirtualnej.
    • Wszystkie ustawienia zasad replikacji są stosowane:
      • Próg celu punktu odzyskiwania. To ustawienie nie ma wpływu na replikację. Pomaga to w monitorowaniu. Zostanie zgłoszone zdarzenie i opcjonalnie wysłana wiadomość e-mail, jeśli bieżący cel punktu odzyskiwania przekroczy określony limit progowy.
      • Przechowywanie punktów odzyskiwania. To ustawienie określa, jak daleko w czasie chcesz przejść po wystąpieniu zakłóceń. Maksymalny okres przechowywania wynosi 15 dni na dysku zarządzanym.
      • Migawki spójne na poziomie aplikacji. Migawka spójna na poziomie aplikacji może być wykonywana co 1 do 12 godzin, w zależności od potrzeb aplikacji. Migawki to standardowe migawki obiektów blob platformy Azure. Agent mobilności uruchomiony na maszynie wirtualnej żąda migawki usługi VSS zgodnie z tym ustawieniem i zakładki, które wskazują punkt w czasie jako punkt spójny aplikacji w strumieniu replikacji.

      Uwaga

      Wysoki okres przechowywania punktu odzyskiwania może mieć wpływ na koszt magazynu, ponieważ może być konieczne zapisanie większej liczby punktów odzyskiwania.

  2. Ruch jest replikowany do publicznych punktów końcowych usługi Azure Storage za pośrednictwem Internetu. Alternatywnie możesz użyć usługi Azure ExpressRoute z komunikacją równorzędną firmy Microsoft. Replikowanie ruchu przez wirtualną sieć prywatną typu lokacja-lokacja (VPN) z lokacji lokalnej do platformy Azure nie jest obsługiwane.

  3. Początkowa operacja replikacji gwarantuje, że całe dane na maszynie w momencie włączenia replikacji są wysyłane na platformę Azure. Po zakończeniu replikacji początkowej rozpoczyna się replikacja zmian różnicowych na platformę Azure. Śledzone zmiany maszyny są wysyłane do serwera przetwarzania.

  4. Komunikacja odbywa się w następujący sposób:

    • Maszyny wirtualne komunikują się z lokalnym serwerem konfiguracji na porcie HTTPS 443 przychodzącym na potrzeby zarządzania replikacją.
    • Serwer konfiguracji organizuje replikację za pomocą platformy Azure za pośrednictwem portu HTTPS 443 wychodzącego.
    • Maszyny wirtualne wysyłają dane replikacji do serwera przetwarzania (uruchomionego na maszynie serwera konfiguracji) na porcie HTTPS 9443 przychodzącym. Ten port można zmodyfikować.
    • Serwer przetwarzania odbiera dane replikacji, optymalizuje je i szyfruje oraz wysyła je do usługi Azure Storage za pośrednictwem portu 443 wychodzącego.

  5. Dzienniki danych replikacji najpierw trafiają na konto magazynu pamięci podręcznej na platformie Azure. Te dzienniki są przetwarzane i dane są przechowywane na dysku zarządzanym platformy Azure (nazywanym dyskiem inicjanym usługi Azure Site Recovery). Punkty odzyskiwania są tworzone na tym dysku.

Diagram przedstawiający proces replikacji z programu VMware do platformy Azure.

Proces ponownej synchronizacji

  1. Czasami podczas replikacji początkowej lub podczas przesyłania zmian różnicowych mogą wystąpić problemy z łącznością sieciową między maszyną źródłową a serwerem przetwarzania lub między serwerem przetwarzania na platformie Azure. Jeden z tych elementów może prowadzić do niepowodzeń w transferze danych na platformę Azure.
  2. Aby uniknąć problemów z integralnością danych i zminimalizować koszty transferu danych, usługa Site Recovery oznacza maszynę do ponownej synchronizacji.
  3. Maszynę można również oznaczyć do ponownej synchronizacji w sytuacjach, takich jak w następujących sytuacjach, aby zachować spójność między maszyną źródłową a danymi przechowywanymi na platformie Azure
    • Jeśli maszyna zostanie wymusi wyłączenie
    • Jeśli maszyna przechodzi zmiany konfiguracyjne, takie jak zmiana rozmiaru dysku (modyfikowanie rozmiaru dysku z 2 TB do 4 TB)
  4. Ponowne synchronizowanie wysyła tylko dane różnicowe na platformę Azure. Transfer danych między środowiskiem lokalnym a platformą Azure przez zminimalizowanie przez obliczanie sum kontrolnych danych między maszyną źródłową a danymi przechowywanymi na platformie Azure.
  5. Domyślnie ponowna synchronizacja ma być uruchamiana automatycznie poza godzinami pracy. Jeśli nie chcesz czekać na domyślną ponowną synchronizację poza godzinami, możesz ponownie zsynchronizować maszynę wirtualną ręcznie. Aby to zrobić, przejdź do witryny Azure Portal, wybierz ponownie synchronizację maszyny wirtualnej.>
  6. Jeśli domyślna ponowna synchronizacja zakończy się niepowodzeniem poza godzinami pracy i wymagana jest ręczna interwencja, na określonym komputerze w witrynie Azure Portal zostanie wygenerowany błąd. Możesz usunąć błąd i ręcznie wyzwolić ponowną synchronizację.
  7. Po zakończeniu ponownej synchronizacji replikacja zmian różnicowych zostanie wznowiona.

Zarządzanie zasadami replikacji

  • Ustawienia zasad replikacji można dostosować podczas włączania replikacji.
  • Zasady replikacji można utworzyć w dowolnym momencie, a następnie zastosować je po włączeniu replikacji.

Spójność wielu maszyn wirtualnych

Jeśli chcesz, aby maszyny wirtualne były replikowane razem i współużytkowały punkty odzyskiwania spójne na poziomie awarii i aplikacji w trybie failover, możesz zebrać je razem w grupie replikacji. Spójność wielu maszyn wirtualnych ma wpływ na wydajność obciążeń i powinna być używana tylko dla maszyn wirtualnych z uruchomionymi obciążeniami, które wymagają spójności na wszystkich maszynach.

Migawki i punkty odzyskiwania

Punkty odzyskiwania są tworzone na podstawie migawek dysków maszyn wirtualnych wykonanych w określonym punkcie w czasie. Podczas przełączania maszyny wirtualnej w tryb failover należy użyć punktu odzyskiwania, aby przywrócić maszynę wirtualną w lokalizacji docelowej.

W przypadku przełączania w tryb failover zwykle chcemy upewnić się, że maszyna wirtualna zaczyna się od braku uszkodzenia lub utraty danych, a dane maszyny wirtualnej są spójne dla systemu operacyjnego oraz aplikacji uruchamianych na maszynie wirtualnej. Zależy to od typu wykonanych migawek.

Usługa Site Recovery tworzy migawki w następujący sposób:

  1. Usługa Site Recovery domyślnie tworzy migawki spójne na poziomie awarii danych i migawki spójne z aplikacjami, jeśli określisz dla nich częstotliwość.
  2. Punkty odzyskiwania są tworzone na podstawie migawek i przechowywane zgodnie z ustawieniami przechowywania w zasadach replikacji.

Spójność

W poniższej tabeli opisano różne typy spójności.

Spójne na poziomie awarii

Opis Szczegóły Zalecenie
Migawka spójna na poziomie awarii przechwytuje dane, które znajdowały się na dysku podczas wykonywania migawki. Nie zawiera żadnych elementów w pamięci.

Zawiera odpowiednik danych na dysku, które byłyby obecne, jeśli maszyna wirtualna uległa awarii lub przewód zasilania został ściągnięty z serwera w momencie utworzenia migawki.

Spójność na poziomie awarii nie gwarantuje spójności danych dla systemu operacyjnego ani aplikacji na maszynie wirtualnej.		 Usługa Site Recovery domyślnie tworzy punkty odzyskiwania spójne na poziomie awarii co pięć minut. Tego ustawienia nie można zmodyfikować.

 Obecnie większość aplikacji może odzyskać się dobrze po punktach spójnych na poziomie awarii.

Punkty odzyskiwania spójne na poziomie awarii są zwykle wystarczające dla replikacji systemów operacyjnych i aplikacji, takich jak serwery DHCP i serwery wydruku.

Spójne na poziomie aplikacji

Opis Szczegóły Zalecenie
Punkty odzyskiwania spójne na poziomie aplikacji są tworzone na podstawie migawek spójnych na poziomie aplikacji.

Migawka spójna na poziomie aplikacji zawiera wszystkie informacje w migawce spójnej na poziomie awarii oraz wszystkie dane w pamięci i w toku transakcji.		 Migawki spójne na poziomie aplikacji używają usługi kopiowania woluminów w tle (VSS):

1) Usługa Azure Site Recovery używa metody kopii zapasowej tylko do kopiowania (VSS_BT_COPY), która nie zmienia czasu tworzenia kopii zapasowej dziennika transakcji programu Microsoft SQL i numeru

sekwencji 2) Po zainicjowaniu migawki usługa VSS wykonuje operację kopiowania na zapis (COW) na woluminie.

3) Przed wykonaniem operacji COW usługa VSS informuje każdą aplikację na maszynie, że musi opróżnić dane rezydenta pamięci na dysk.

4) Usługa VSS umożliwia następnie aplikacji do tworzenia kopii zapasowej/odzyskiwania po awarii (w tym przypadku usługi Site Recovery) odczytywanie danych migawki i kontynuowanie.		 Migawki spójne na poziomie aplikacji są wykonywane zgodnie z ową częstotliwością. Ta częstotliwość powinna być zawsze mniejsza niż ustawiona na potrzeby przechowywania punktów odzyskiwania. Jeśli na przykład zachowasz punkty odzyskiwania przy użyciu domyślnego ustawienia 24 godzin, należy ustawić częstotliwość na mniej niż 24 godziny.

Są one bardziej złożone i trwa dłużej niż migawki spójne na poziomie awarii.

Mają one wpływ na wydajność aplikacji uruchomionych na maszynie wirtualnej włączonej do replikacji.

Proces pracy w trybie failover i podczas powrotu po awarii

Po skonfigurowaniu replikacji i uruchomieniu próbnego odzyskiwania po awarii (test pracy w trybie failover), aby sprawdzić, czy wszystko działa zgodnie z oczekiwaniami, możesz uruchomić tryb failover i powrót po awarii zgodnie z potrzebami.

  1. Uruchomienie operacji kończy się niepowodzeniem dla pojedynczej maszyny lub utworzenie planów odzyskiwania w celu przejścia w tryb failover wielu maszyn wirtualnych w tym samym czasie. Zaletą planu odzyskiwania zamiast trybu failover pojedynczej maszyny jest:

    • Zależności aplikacji można modelować, włączając wszystkie maszyny wirtualne w aplikacji w ramach jednego planu odzyskiwania.
    • Możesz dodawać skrypty, elementy Runbook platformy Azure i wstrzymywać akcje ręczne.

  2. Po wyzwoleniu początkowego trybu failover należy zatwierdzić go, aby rozpocząć uzyskiwanie dostępu do obciążenia z maszyny wirtualnej platformy Azure.

  3. Po ponownym udostępnieniu podstawowej lokacji lokalnej można przygotować się do powrotu po awarii. W celu powrotu po awarii należy skonfigurować infrastrukturę powrotu po awarii, w tym:

    • Tymczasowy serwer przetwarzania na platformie Azure: aby powrócić po awarii z platformy Azure, należy skonfigurować maszynę wirtualną platformy Azure do działania jako serwer przetwarzania do obsługi replikacji z platformy Azure. Po zakończeniu powrotu po awarii można usunąć tę maszynę wirtualną.
    • Połączenie sieci VPN: aby powrócić po awarii, potrzebujesz połączenia sieci VPN (lub usługi ExpressRoute) z sieci platformy Azure do lokacji lokalnej.
    • Oddzielny główny serwer docelowy: domyślnie główny serwer docelowy zainstalowany z serwerem konfiguracji na lokalnej maszynie wirtualnej VMware obsługuje powrót po awarii. Jeśli konieczne jest powrót po awarii dużych ilości ruchu, skonfiguruj w tym celu oddzielny lokalny główny serwer docelowy.
    • Zasady powrotu po awarii: aby móc przeprowadzić ponowną replikację do lokacji lokalnej, należy utworzyć zasady powrotu po awarii. Te zasady są tworzone automatycznie podczas tworzenia zasad replikacji ze środowiska lokalnego na platformę Azure.

  4. Po zakończeniu działania składników powrót po awarii odbywa się w trzech akcjach:

    • Etap 1. Ponowne włączanie ochrony maszyn wirtualnych platformy Azure w celu replikacji z platformy Azure z powrotem do lokalnych maszyn wirtualnych VMware.
    • Etap 2. Uruchamianie trybu failover w lokacji lokalnej.
    • Etap 3. Po powrocie obciążeń po awarii można ponownie włączyć replikację dla lokalnych maszyn wirtualnych.

Diagram przedstawiający powrót po awarii programu VMware z platformy Azure.

Następne kroki

Wykonaj czynności opisane w tym samouczku , aby włączyć replikację oprogramowania VMware na platformę Azure.