Przygotowanie do włączania ponownej ochrony i powrotu po awarii maszyn wirtualnych VMware

  • Artykuł

Po przejściu w tryb failover lokalnych maszyn wirtualnych VMware lub serwerów fizycznych na platformę Azure należy ponownie włączyć ochronę maszyn wirtualnych platformy Azure utworzonych po przejściu w tryb failover, aby replikować je z powrotem do lokacji lokalnej. Replikacja z platformy Azure do środowiska lokalnego umożliwia powrót po awarii, uruchamiając tryb failover z platformy Azure do środowiska lokalnego, gdy wszystko będzie gotowe.

Ponowne włączanie ochrony lub powrót po awarii składników

Przed ponownym włączaniem ochrony i powrotu po awarii z platformy Azure potrzebujesz wielu składników i ustawień.

Składnik Szczegóły
Lokalny serwer konfiguracji Serwer konfiguracji lokalnej musi być uruchomiony i połączony z platformą Azure.

Maszyna wirtualna, która kończy się niepowodzeniem, musi istnieć w bazie danych serwera konfiguracji. Jeśli awaria wpłynie na serwer konfiguracji, przywróć go przy użyciu tego samego adresu IP, aby upewnić się, że powrót po awarii działa.

Jeśli adresy IP replikowanych maszyn zostały zachowane w trybie failover, należy ustanowić łączność lokacja-lokacja (lub łączność usługi ExpressRoute) między maszynami wirtualnymi platformy Azure a kartą sieciową powrotu po awarii serwera konfiguracji. W przypadku zachowanych adresów IP serwer konfiguracji potrzebuje dwóch kart sieciowych — jednej dla łączności maszyny źródłowej i jednej dla łączności powrotu po awarii platformy Azure. Pozwala to uniknąć nakładania się zakresów adresów podsieci dla źródłowej i przełączonej w tryb failover maszyn wirtualnych.
Serwer przetwarzania na platformie Azure Serwer przetwarzania na platformie Azure jest potrzebny przed powrotem po awarii do lokacji lokalnej.

Serwer przetwarzania odbiera dane z chronionej maszyny wirtualnej platformy Azure i wysyła je do lokacji lokalnej.

Potrzebujesz sieci o małych opóźnieniach między serwerem przetwarzania a chronioną maszyną wirtualną, dlatego zalecamy wdrożenie serwera przetwarzania na platformie Azure w celu uzyskania wyższej wydajności replikacji.

Na potrzeby weryfikacji koncepcji można użyć lokalnego serwera przetwarzania i usługi ExpressRoute z prywatną komunikacją równorzędną.

Serwer przetwarzania powinien znajdować się w sieci platformy Azure, w której znajduje się maszyna wirtualna w trybie failover. Serwer przetwarzania musi również mieć możliwość komunikowania się z lokalnym serwerem konfiguracji i głównym serwerem docelowym.
Oddzielny główny serwer docelowy Główny serwer docelowy odbiera dane powrotu po awarii, a domyślnie główny serwer docelowy systemu Windows działa na lokalnym serwerze konfiguracji.

Główny serwer docelowy może mieć do niego maksymalnie 60 dysków. Jeśli maszyny wirtualne, które są przywracane po awarii, mają więcej niż łącznie 60 dysków lub jeśli po awarii wrócisz do dużych ilości ruchu, utwórz oddzielny główny serwer docelowy na potrzeby powrotu po awarii.

Jeśli maszyny są zbierane w grupie replikacji w celu zapewnienia spójności wielu maszyn wirtualnych, maszyny wirtualne muszą być wszystkie z systemem Windows lub muszą być w systemie Linux. Dlaczego? Ponieważ wszystkie maszyny wirtualne w grupie replikacji muszą używać tego samego głównego serwera docelowego, a główny serwer docelowy musi mieć ten sam system operacyjny (z tą samą lub wyższą wersją) niż te z replikowanych maszyn.

Główny serwer docelowy nie powinien mieć żadnych migawek na swoich dyskach, w przeciwnym razie ponowne włączanie ochrony i powrót po awarii nie będzie działać.

Obiekt docelowy główny nie może mieć kontrolera SCSI parawirtualnego. Kontroler może być tylko kontrolerem logiki LSI. Bez kontrolera logiki LSI ponowne włączanie ochrony kończy się niepowodzeniem.
Zasady replikacji powrotu po awarii Aby replikować z powrotem do lokacji lokalnej, potrzebne są zasady powrotu po awarii. Te zasady są tworzone automatycznie podczas tworzenia zasad replikacji na platformie Azure.

Zasady zostaną automatycznie skojarzone z serwerem konfiguracji. Jest ona ustawiona na próg celu punktu odzyskiwania wynoszącego 15 minut, przechowywanie punktu odzyskiwania wynoszącego 24 godziny, a częstotliwość migawek spójnych na poziomie aplikacji wynosi 60 minut. Nie można edytować zasad.
Sieć VPN typu lokacja-lokacja/prywatna komunikacja równorzędna usługi ExpressRoute Ponowne włączanie ochrony i powrót po awarii wymaga połączenia sieci VPN typu lokacja-lokacja lub prywatnej komunikacji równorzędnej usługi ExpressRoute w celu replikowania danych.

Porty ponownego włączania ochrony/powrotu po awarii

Aby ponownie chronić/powrót po awarii, należy otworzyć wiele portów. Na poniższej ilustracji przedstawiono porty i przepływ ponownego włączania ochrony/powrotu po awarii.

Porty trybu failover i powrotu po awarii

Wdrażanie serwera przetwarzania na platformie Azure

  1. Skonfiguruj serwer przetwarzania na platformie Azure pod kątem powrotu po awarii.
  2. Upewnij się, że maszyny wirtualne platformy Azure mogą nawiązać połączenie z serwerem przetwarzania.
  3. Upewnij się, że połączenie sieci VPN typu lokacja-lokacja lub sieć prywatnej komunikacji równorzędnej usługi ExpressRoute ma wystarczającą przepustowość, aby wysyłać dane z serwera przetwarzania do lokacji lokalnej.

Wdrażanie oddzielnego głównego serwera docelowego

  1. Zwróć uwagę na wymagania i ograniczenia głównego serwera docelowego.

  2. Utwórz główny serwer docelowy systemu Windows lub Linux , aby był zgodny z systemem operacyjnym maszyn wirtualnych, które chcesz ponownie włączyć i wrócić po awarii.

  3. Upewnij się, że nie używasz narzędzia Storage vMotion dla głównego serwera docelowego lub powrót po awarii może zakończyć się niepowodzeniem. Nie można uruchomić maszyny wirtualnej, ponieważ dyski nie są do niego dostępne.

    • Aby temu zapobiec, wyklucz główny serwer docelowy z listy vMotion.
    • Jeśli obiekt docelowy główny przechodzi zadanie Storage vMotion po ponownym włączeniu ochrony, chronione dyski maszyny wirtualnej dołączone do głównego serwera docelowego są migrowane do miejsca docelowego zadania vMotion. Jeśli spróbujesz wrócić po awarii po tym, odłączenie dysku zakończy się niepowodzeniem, ponieważ nie znaleziono dysków. Następnie trudno jest znaleźć dyski na kontach magazynu. W takim przypadku znajdź je ręcznie i dołącz je do maszyny wirtualnej. Następnie można uruchomić lokalną maszynę wirtualną.

  4. Dodaj dysk przechowywania do istniejącego głównego serwera docelowego systemu Windows. Dodaj nowy dysk i sformatuj dysk. Dysk przechowywania jest używany do zatrzymywania punktów w czasie, gdy maszyna wirtualna replikuje z powrotem do lokacji lokalnej. Zanotuj te kryteria. Jeśli nie zostaną spełnione, dysk nie znajduje się na liście dla głównego serwera docelowego:

    • Wolumin nie jest używany do żadnego innego celu, takiego jak cel replikacji, i nie jest w trybie blokady.
    • Wolumin nie jest woluminem pamięci podręcznej. Wolumin instalacji niestandardowej dla serwera przetwarzania i obiektu docelowego głównego nie kwalifikuje się do przechowywania woluminu. Gdy serwer przetwarzania i główny obiekt docelowy są instalowane na woluminie, wolumin jest woluminem pamięci podręcznej głównego obiektu docelowego.
    • Typ systemu plików woluminu nie jest FAT ani FAT32.
    • Pojemność woluminu jest niezerowa.
    • Domyślnym woluminem przechowywania dla systemu Windows jest wolumin R.
    • Domyślnym woluminem przechowywania dla systemu Linux jest /mnt/retention.

  5. Dodaj dysk, jeśli używasz istniejącego serwera przetwarzania. Nowy dysk musi spełniać wymagania w ostatnim kroku. Jeśli dysk przechowywania nie jest obecny, nie jest wyświetlany na liście rozwijanej wyboru w portalu. Po dodaniu dysku do lokalnego obiektu docelowego głównego może ujmować do 15 minut, aż dysk pojawi się w zaznaczeniu w portalu. Jeśli dysk nie pojawi się po 15 minutach, możesz odświeżyć serwer konfiguracji.

  6. Zainstaluj narzędzia VMware lub narzędzia open-vm-tools na głównym serwerze docelowym. Bez narzędzi nie można wykryć magazynów danych na hoście ESXi obiektu głównego.

  7. Ustaw dysk. EnableUUID=true ustawienie w parametrach konfiguracji głównej docelowej maszyny wirtualnej w programie VMware. Jeśli ten wiersz nie istnieje, dodaj go. To ustawienie jest wymagane do zapewnienia spójnego identyfikatora UUID zestawu VMDK, aby można było je poprawnie zainstalować.

  8. Sprawdź wymagania dotyczące dostępu do programu vCenter Server:

    • Jeśli maszyna wirtualna, na której kończy się niepowodzenie, znajduje się na hoście ESXi zarządzanym przez program VMware vCenter Server, główny serwer docelowy musi mieć dostęp do pliku lokalnej maszyny wirtualnej Virtual Machine Disk (VMDK), aby zapisać replikowane dane na dyskach maszyny wirtualnej. Upewnij się, że lokalny magazyn danych maszyn wirtualnych jest zainstalowany na głównym hoście docelowym z dostępem do odczytu/zapisu.
    • Jeśli maszyna wirtualna nie znajduje się na hoście ESXi zarządzanym przez program VMware vCenter Server, Site Recovery tworzy nową maszynę wirtualną podczas ponownego włączania ochrony. Ta maszyna wirtualna jest tworzona na hoście ESXi, na którym jest tworzona główna maszyna wirtualna serwera docelowego. Starannie wybierz hosta ESXi, aby utworzyć maszynę wirtualną na żądanym hoście. Dysk twardy maszyny wirtualnej musi znajdować się w magazynie danych dostępnym dla hosta, na którym uruchomiony jest główny serwer docelowy.
    • Inną opcją, jeśli lokalna maszyna wirtualna już istnieje na potrzeby powrotu po awarii, jest usunięcie jej przed powrotem po awarii. Powrót po awarii tworzy nową maszynę wirtualną na tym samym hoście co główny host ESXi. Po powrocie po awarii do lokalizacji alternatywnej dane są odzyskiwane do tego samego magazynu danych i tego samego hosta ESXi, który jest używany przez lokalny główny serwer docelowy.

  9. W przypadku maszyn fizycznych, które kończą się niepowodzeniem z maszynami wirtualnymi VMware, należy ukończyć odnajdywanie hosta, na którym jest uruchomiony główny serwer docelowy, zanim będzie można ponownie włączyć ochronę maszyny.

  10. Sprawdź, czy host ESXi, na którym główna docelowa maszyna wirtualna ma dołączony co najmniej jeden magazyn danych systemu plików maszyn wirtualnych (VMFS). Jeśli nie są dołączone żadne magazyny danych VMFS, dane wejściowe magazynu danych w ustawieniach ponownej ochrony są puste i nie można kontynuować.

Następne kroki

Dowiedz się, jak ponownie chronić maszynę wirtualną.