Przygotowanie do włączania ponownej ochrony i powrotu po awarii maszyn wirtualnych VMware
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 zreplikować 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 | Lokalny serwer konfiguracji musi być uruchomiony i połączony z platformą Azure. Maszyna wirtualna, której powrót 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ść typu 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 z maszyną źródłową 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 | Przed powrotem do lokacji lokalnej potrzebny jest serwer przetwarzania na platformie Azure. Serwer przetwarzania odbiera dane z chronionej maszyny wirtualnej platformy Azure i wysyła je do lokacji lokalnej. Potrzebna jest sieć o małych opóźnieniach między serwerem przetwarzania a chronioną maszyną wirtualną, dlatego zalecamy wdrożenie serwera przetwarzania na platformie Azure w celu zwiększenia wydajności replikacji. W celu 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 powrót po awarii maszyn wirtualnych ma więcej niż łącznie 60 dysków lub w przypadku powrotu po awarii 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 z wieloma maszynami wirtualnymi, maszyny wirtualne muszą mieć system Windows lub wszystkie muszą mieć system 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 dyskach, w przeciwnym razie ponowne włączenie 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 zreplikować 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 ustawiona wartość progu celu punktu odzyskiwania wynoszącego 15 minut, przechowywania punktu odzyskiwania wynoszącego 24 godziny, a częstotliwość migawek spójnych na poziomie aplikacji wynosi 60 minut. Nie można edytować zasad. |
| Prywatna komunikacja równorzędna 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 na potrzeby ponownego włączania ochrony/powrotu po awarii
Aby można było 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.
Wdrażanie serwera przetwarzania na platformie Azure
- Skonfiguruj serwer przetwarzania na platformie Azure na potrzeby powrotu po awarii.
- Upewnij się, że maszyny wirtualne platformy Azure mogą uzyskać dostęp do serwera przetwarzania.
- Upewnij się, że połączenie sieci VPN typu lokacja-lokacja lub sieć prywatnej komunikacji równorzędnej usługi ExpressRoute ma wystarczającą przepustowość do wysyłania danych z serwera przetwarzania do lokacji lokalnej.
Wdrażanie oddzielnego głównego serwera docelowego
Zwróć uwagę na wymagania i ograniczenia dotyczące głównego serwera docelowego.
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 przywrócić po awarii.
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ą dostępne.
- Aby temu zapobiec, wyklucz główny serwer docelowy z listy programu 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 powró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ą.
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 woluminu przechowywania. Gdy serwer przetwarzania i główny element docelowy są zainstalowane 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ślny wolumin przechowywania dla systemu Linux to /mnt/retention.
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 jest wyświetlany po 15 minutach, możesz odświeżyć serwer konfiguracji.
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 głównego obiektu docelowego.
Ustaw dysk. EnableUID=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 dla zestawu VMDK, aby można było go poprawnie zainstalować.
Sprawdź wymagania dotyczące dostępu do programu vCenter Server:
- Jeśli maszyna wirtualna, do której następuje powrót po awarii, 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ć zreplikowane dane na dyskach maszyny wirtualnej. Upewnij się, że lokalny magazyn danych maszyny wirtualnej 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, usługa Site Recovery tworzy nową maszynę wirtualną podczas ponownego włączania ochrony. Ta maszyna wirtualna jest tworzona na hoście ESXi, na którym tworzysz główną maszynę wirtualną 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 następnie 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.
W przypadku maszyn fizycznych zakończonych niepowodzeniem z powrotem do maszyn wirtualnych 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.
Sprawdź, czy host ESXi, na którym jest dołączona główna docelowa maszyna wirtualna, ma co najmniej jeden magazyn danych systemu plików maszyny wirtualnej (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 włączyć ochronę maszyny wirtualnej.