Przechodzenie z wersji klasycznej do zmodernizowanego odzyskiwania po awarii programu VMware
Ten artykuł zawiera informacje na temat architektury, niezbędnej infrastruktury i często zadawanych pytań dotyczących przenoszenia replikacji maszyn wirtualnych lub fizycznych z klasycznej do zmodernizowanej architektury ochrony. Dzięki tej możliwości migracji można pomyślnie przenieść replikowane elementy z serwera konfiguracji do urządzenia replikacji usługi Azure Site Recovery. Ta migracja jest kierowana przez mechanizm inteligentnej replikacji, który gwarantuje, że pełna replikacja początkowa nie jest wykonywana ponownie dla niekrytycznych replikowanych elementów i transferowane są tylko dane różnicowe.
Uwaga
Plany odzyskiwania nie zostaną zmigrowane i będą musiały zostać utworzone ponownie w zmodernizowanym magazynie usługi Recovery Services.
Architektura
Składniki związane z migracją replikowanych elementów maszyny wirtualnej lub fizycznej są podsumowane w poniższej tabeli:
| Składnik | Wymaganie |
|---|---|
| Replikowane elementy w klasycznej skrytce usług odzyskiwania | Co najmniej jeden zreplikowany element chroniony za pomocą klasycznej architektury i dobrze działającego serwera konfiguracji. Replikowany element powinien być w stanie niekrytycznym i musi być replikowany ze środowiska lokalnego do platformy Azure przy użyciu agenta mobilności działającego w wersji 9.50 lub nowszej. |
| Serwer konfiguracji używany przez replikowane elementy | Serwer konfiguracji używany przez zreplikowane elementy powinien znajdować się w stanie niekrytycznym, a jego składniki powinny zostać uaktualnione do najnowszej wersji (9.50 lub nowszej). |
| Magazyn usługi Recovery Services z zmodernizowanym środowiskiem | Magazyn usługi Recovery Services z zmodernizowanym środowiskiem. |
| Urządzenie replikacji usługi Azure Site Recovery w dobrej kondycji | Niekrytyczne urządzenie repliki usługi Azure Site Recovery, które umożliwia odnajdywanie maszyn lokalnych, ze wszystkimi składnikami zaktualizowanymi do wersji 9.50 lub nowszej. Dokładne wymagane wersje są następujące: Serwer przetwarzania: 9.50 Serwer proxy: 1.35.8419.34591 Agent usługi odzyskiwania: 2.0.9249.0 Usługa replikacji: 1.35.8433.24227 |
Wymagana infrastruktura
Upewnij się, że spełnione są następujące warunki, aby pomyślnie przenieść replikowany element:
- Skrytka usługi odzyskiwania danych, korzystająca z zmodernizowanego środowiska.
Uwaga
Każdy nowo utworzony magazyn Recovery Services będzie miał domyślnie włączone zmodernizowane środowisko. Nie można przełączyć się do klasycznego środowiska, ponieważ jego wycofanie zostało już ogłoszone.
- Urządzenie replikacji usługi Azure Site Recovery zostało pomyślnie zarejestrowane w magazynie, a wszystkie jego składniki są w stanie niekrytycznym.
- Wersja urządzenia musi być 9.50 lub nowsza. Aby uzyskać szczegółowy opis wersji, sprawdź tutaj.
- Szczegóły serwera vCenter lub hosta vSphere, w którym znajdują się istniejące zreplikowane maszyny, są dodawane do urządzenia w celu pomyślnego odnajdywania lokalnego.
Wymagania wstępne
Przygotowywanie infrastruktury
Przed przejściem z architektury klasycznej na zmodernizowaną, upewnij się, że wykonałeś następujące czynności:
- Utwórz skrytkę Recovery Services i upewnij się, że środowisko nie zostało przełączone na klasyczny
- Zdeplojuj narzędzie do replikacji usługi Azure Site Recovery.
- Dodaj szczegóły programu vCenter Server maszyny lokalnej do urządzenia, aby pomyślnie wykonać odnajdywanie.
Przygotowanie klasycznego skarbca usługi Recovery Services
Upewnij się, że repliki, które planujesz przenieść, spełniają następujące wymagania:
- Replikowany element to maszyna wirtualna VMware lub maszyna fizyczna replikująca się przy użyciu serwera konfiguracji.
- Replikacja nie jest przeprowadzana na niezarządzanym koncie magazynowym, lecz na zarządzanym dysku.
- Replikacja odbywa się ze środowiska lokalnego na platformę Azure, a replikowany element nie znajduje się w trybie failover ani w stanie powrotu po awarii.
- Replikowany element nie replikuje danych z platformy Azure do środowiska lokalnego.
- Replikacja początkowa nie jest w toku i została już ukończona.
- Zreplikowany element nie jest w stanie "ponownej synchronizacji".
- Wersja serwera konfiguracji to 9.50 lub nowsza, a jego kondycja jest w stanie niekrytycznym.
- Serwer konfiguracji ma puls w dobrej kondycji.
- Wersja agenta usługi mobilności, która jest zainstalowana na maszynie źródłowej, to 9.50 lub nowsza.
- Magazyny usługi Recovery Services z włączoną tożsamością usługi zarządzanej są obsługiwane.
- Magazyny usługi Recovery Services z włączonymi prywatnymi punktami końcowymi są obsługiwane.
- Kondycja replikowanego elementu jest niekrytyczna, a punkty odzyskiwania są tworzone pomyślnie.
Przygotowywanie zmodernizowanego magazynu usługi Recovery Services
W przypadku zmodernizowanej konfiguracji architektury upewnij się, że:
- Magazyn Recovery Services wykorzystywany do skonfigurowania zmodernizowanej architektury znajduje się w tej samej lokalizacji geograficznej co magazyn klasyczny.
- Urządzenie replikacji usługi Azure Site Recovery jest wdrażane lokalnie z wersją 9.50 lub nowszą.
- Urządzenie zostało pomyślnie zarejestrowane w skarbcu.
- Urządzenie i wszystkie jego składniki są w stanie niekrytycznym, a urządzenie ma zdrowy puls.
- Wersja programu vCenter Server jest obsługiwana przez zmodernizowaną architekturę.
- Szczegóły programu vCenter Server maszyny źródłowej są dodawane do urządzenia.
- Wersja dystrybucji systemu Linux jest obsługiwana przez zmodernizowaną architekturę. Dowiedz się więcej.
- Wersja systemu Windows Server jest obsługiwana przez zmodernizowaną architekturę. Dowiedz się więcej.
Oblicz całkowity czas przenoszenia
Łączny czas wymagany do przeniesienia dowolnego replikowanego elementu z magazynu klasycznego do zmodernizowanego magazynu zależy od stanu replikacji elementu i rozmiaru dysku.
| Państwo | Pora na migrację do zmodernizowanego skarbca |
|---|---|
| Stan ochrony replikowanego elementu jest w dobrej kondycji , a ostatni punkt odzyskiwania został utworzony mniej niż 50 minut temu | Migracja jest zakończona w ciągu 1–2 godzin |
| Stan ochrony replikowanego elementu nie jest w dobrej kondycji lub ostatni punkt odzyskiwania został utworzony ponad 50 minut temu | Czas migracji będzie się różnić i będzie zależeć od rozmiaru dysku |
Jeśli stan ochrony maszyn nie jest w dobrej kondycji, użyj poniższej formuły, aby obliczyć dokładny czas maszyn:
Czas migracji = 1 godzina + 45 sekund/GiB
| Konfiguracja maszyny | Czas migracji |
|---|---|
| Jedna maszyna z dwoma dyskami o rozmiarze 256 GiB | ~ 4 godziny 15 minut [Oba dyski są migrowane równolegle] |
| 10 maszyn z dwoma dyskami, oba o rozmiarze 256 GiB | ~ 4 godziny 15 minut [Wszystkie maszyny wirtualne i ich dyski są migrowane równolegle] |
| Jedna maszyna z czterema dyskami o rozmiarze 512 GiB | ~ 7 godzin 30 minut [Oba dyski są migrowane równolegle] |
| 10 maszyn z czterema dyskami, każdy rozmiar 512 GiB | ~ 7 godzin 30 minut [Wszystkie maszyny wirtualne i ich dyski są migrowane równolegle] |
Ta sama formuła służy do obliczania czasu migracji i jest wyświetlana w portalu.
Jak zdefiniować wymaganą infrastrukturę
Podczas migracji maszyn z klasycznej do zmodernizowanej architektury należy upewnić się, że wymagana infrastruktura została już zarejestrowana w zmodernizowanym magazynie usługi Recovery Services. Aby zdefiniować wymaganą infrastrukturę, zapoznaj się ze szczegółami dotyczącymi rozmiaru i pojemności aplikacji replikacyjnej.
Zgodnie z regułą należy skonfigurować taką samą liczbę urządzeń replikacji, co liczba serwerów przetwarzania w klasycznym magazynie usługi Recovery Services. W klasycznej skrytce, jeśli był jeden serwer konfiguracji i cztery serwery przetwarzania, należy skonfigurować cztery urządzenia replikacji w zmodernizowanej skrytce usługi Recovery Services.
Cennik
Opłata licencyjna za usługę Site Recovery będzie nadal naliczana w klasycznym zasobie do czasu wygaśnięcia okresu przechowywania wszystkich punktów przywracania. Po wyczyszczeniu wszystkich punktów odzyskiwania, naliczanie opłat zostanie zatrzymane w klasycznej skrytce. Po wygaśnięciu okresu przechowywania wszystkich punktów odzyskiwania, element replikowany zostanie automatycznie usunięty przez operację czyszczenia replikacji uruchamianą przez system.
Usługa Site Recovery rozpocznie naliczanie opłaty licencyjnej za replikowane elementy w zmodernizowanym magazynie dopiero po wygenerowaniu pierwszego punktu odzyskiwania i oczyszczeniu starszego magazynu. Jeśli w klasycznym sejfie oczekują jakiekolwiek dni użycia bezpłatnej wersji próbnej, te same informacje zostaną przekazane do zmodernizowanego sejfu. Ceny na zmodernizowany magazyn zaczną obowiązywać dopiero po upływie tego okresu próbnego.
Uwaga
W pewnym momencie ustalanie cen będzie odbywać się tylko przy użyciu jednego z magazynów — klasycznego lub zmodernizowanego.
Często zadawane pytania
Dlaczego należy migrować maszyny do zmodernizowanej architektury?
Należy pamiętać, że klasyczna architektura odzyskiwania po awarii będzie stopniowo wycofywana, dlatego użytkownicy powinni upewnić się, że przechodzą na najnowszą i zmodernizowaną wersję. Poniższa tabela zawiera porównanie dwóch architektur, które ułatwiają wybranie odpowiedniej opcji zabezpieczania maszyn w przypadku awarii.
| Architektura klasyczna | Modernizacja architektury [Nowe] |
|---|---|
| Wiele konfiguracji wymaganych do odnajdywania danych lokalnych. | Centralne odnajdywanie lokalnego centrum danych przy użyciu usługi odnajdywania. |
| Duża liczba kroków wymaganych do początkowego wprowadzenia. | Uproszczono proces dołączania poprzez automatyzację tworzenia artefaktów i wprowadzenie domyślnych wartości w celu zmniejszenia wymaganych danych wejściowych. |
| Korzysta z ręcznie pobranego pliku w celu uzyskania kontekstu chmury. | Wprowadzono klucz replikacji do uzyskiwania kontekstu chmury podczas konfigurowania urządzenia. |
| Wiele kroków jest wymaganych do prostego procesu umożliwienia replikacji. | Uproszczone doświadczenie związane z włączaniem replikacji przez zmniejszenie liczby wymaganych danych wejściowych i ponowne zdefiniowanie każdego panelu. |
| Serwer konfiguracji nadal jest infrastrukturą lokalną z rozbudowaną konfiguracją dla różnych składników. | Ulepszone urządzenie przez przekonwertowanie wszystkich składników na mikrousługi hostowane na platformie Azure. Upraszcza to skalowanie, monitorowanie i rozwiązywanie problemów z urządzeniami. |
| Potrzeba serwera procesowego rozszerzającego skalę i głównego serwera docelowego na platformie Azure dla maszyn z systemem Linux stanowi utrudnienie. | Usunięto konieczność obsługi oddzielnego serwera przetwarzania i głównego serwera docelowego. |
| Użyto statycznego hasła do uwierzytelniania, które zakłócało wymagania biznesowe klienta dotyczące okresowej rotacji haseł. | Wprowadzono uwierzytelnianie oparte na certyfikatach, które jest bezpieczniejsze i rozwiązuje problemy z zabezpieczeniami klienta. |
| Uaktualnienie do zaktualizowanej wersji powinno odbywać się ręcznie i jest to uciążliwy proces. | Wprowadzono automatyczne uaktualnienia zarówno dla składników urządzenia, jak i usług mobilności. |
| Serwer konfiguracji nie ma wysokiej dostępności i może być narażony na awarię. | Zaimplementowano wysoką dostępność urządzenia w celu zapewnienia odporności. |
| Poświadczenia roota powinny być regularnie aktualizowane, aby zapewnić bezbłędny proces aktualizacji. | Wyeliminowano wymaganie utrzymania poświadczeń root maszyny na potrzeby przeprowadzania automatycznych aktualizacji. |
| Statyczny adres IP należy przypisać do serwera konfiguracji w celu zachowania łączności. | Wprowadzono łączność opartą na FQDN między urządzeniem a maszynami lokalnymi na miejscu. |
| Należy użyć tylko tej sieci wirtualnej, która ma włączoną sieć VPN typu lokacja-lokacja lub usługę Express Route. | Usunięto konieczność obsługi sieci VPN typu lokacja-lokacja lub usługi Express Route na potrzeby replikacji odwrotnej. |
| Należy również skonfigurować narzędzie innych firm, MySQL. | Usunięto zależność od jakichkolwiek narzędzi innych firm. |
Jakie maszyny należy migrować do zmodernizowanej architektury?
Wszystkie maszyny fizyczne lub VMware replikowane przy użyciu serwera konfiguracji powinny zostać zmigrowane do zmodernizowanej architektury.
Gdzie należy utworzyć zmodernizowany magazyn usługi Recovery Services?
Zmodernizowany magazyn usługi Recovery Services powinien znajdować się w tym samym regionie i dzierżawie co magazyn klasyczny. Może to być część dowolnej subskrypcji lub grupy zasobów.
Czy replikacja będzie kontynuowana podczas migracji?
Nie, replikacja zostanie przerwana przez pewien czas, gdy migracja jest w toku. W tym czasie ostatni utworzony punkt odzyskiwania w klasycznym magazynie usługi Recovery Services będzie dostępny do przejścia w tryb failover. Po zakończeniu migracji nowy punkt odzyskiwania jest generowany w zmodernizowanym magazynie Recovery Services.
Kiedy moja operacja migracji zostanie oznaczona jako ukończona?
Operacja migracji zostanie oznaczona jako ukończona dopiero po pomyślnym utworzeniu pierwszego punktu przywracania w zmodernizowanym magazynie usługi Recovery Services.
Jakie operacje można wykonać ze skrytki klasycznej usługi Recovery Services po zakończeniu migracji?
Możesz przełączyć się na tryb awaryjny z klasycznego magazynu po migracji. Operacja trybu failover będzie nadal dostępna w klasycznym magazynie do momentu wygaśnięcia punktów odzyskiwania.
Jeśli na przykład okres przechowywania replikowanego elementu wynosi 72 godziny (trzy dni), najnowszy punkt odzyskiwania w klasycznym magazynie będzie nadal dostępny przez 72 godziny (trzy dni), po pomyślnej migracji. Po upływie określonego czasu Azure Site Recovery automatycznie wyzwoli operację usunięcia replikacji na zreplikowanym elemencie i posprząta wszystkie powiązane elementy magazynu oraz elementy generujące rozliczenia.
Co zrobić, jeśli awaria wystąpi na mojej maszynie, gdy operacja migracji jest w toku?
Każdy zreplikowany element, który jest poddawany migracji, nadal może obsługiwać operację failover za pośrednictwem klasycznego magazynu usługi Recovery Services do momentu zakończenia okresu przechowywania końcowego punktu odzyskiwania. Jeśli spróbujesz wykonać operację przełączenia awaryjnego, będzie miała ona pierwszeństwo przed operacją migracji, a zadanie migracji zostanie przerwane. Aby upewnić się, że zreplikowany element jest migrowany, należy ponownie uruchomić operację migracji w późniejszym terminie.
Uwaga
Właściwości obliczeniowe i sieciowe replikowanych elementów można zaktualizować, gdy migracja jest w toku. Jednak zmiany mogą nie zostać zreplikowane w zmodernizowanej skrytce usługi odzyskiwania danych.
Ile maszyn można migrować w jednym miejscu z modelu klasycznego do zmodernizowanego magazynu?
W jednym miejscu można migrować maksymalnie 10 maszyn za pośrednictwem portalu.
Czy należy ponownie utworzyć sieci wirtualne, konta magazynu i zasady replikacji do użycia w nowym skarbcu?
Nie, te same zasoby, które były używane wcześniej, będą również domyślnie używane w zmodernizowanym magazynie. Zawsze można je zmienić z panelu Obliczenia i panelu Sieci replikowanego elementu. Należy się upewnić, że zasoby nadal mają wymagany dostęp.
W jaki sposób zasady replikacji zostaną przeniesione do zmodernizowanego magazynu?
W ramach wymagań wstępnych usługa Site Recovery utworzy zasady replikacji w zmodernizowanym magazynie z taką samą konfiguracją jak w klasycznym magazynie. Dlatego przed przeniesieniem zreplikowanego elementu skojarzone zasady są tworzone w zmodernizowanym magazynie. Zalecamy unikanie wprowadzania zmian w konfiguracji zasad replikacji w klasycznym magazynie po wyzwoleniu migracji, ponieważ te zmiany nie zostaną odzwierciedlone w zmodernizowanym magazynie. Najlepiej jest wprowadzić te zmiany przed rozpoczęciem procesu migracji.
Nazwa zasad replikacji utworzonych w zmodernizowanym magazynie zostanie zmieniona. Została poprzedzona nazwą grupy zasobów i nazwą zmodernizowanego magazynu Recovery Services. Dlatego jeśli nazwa zasad to "domyślne zasady replikacji" w klasycznym magazynie, to w zmodernizowanym magazynie nazwa tej zasady to default replication policy contoso-modern-vault_contoso-rg, biorąc pod uwagę nazwę magazynu contoso-modern-vault, a grupa zasobów magazynu to contoso-rg.
Czy mogę edytować zasady replikacji podczas migracji lub po migracji w klasycznej pamięci masowej?
Jeśli replika zasad replikacji została już utworzona w zmodernizowanym magazynie, wszelkie zmiany zasad w klasycznym magazynie nie będą propagowane do zmodernizowanego magazynu.
Dlatego jeśli istnieje 10 replikowanych elementów, które są replikowane przy użyciu zasad i decydujesz się przenieść 5 z nich do zmodernizowanego środowiska, kopia zasad zostanie utworzona przed rozpoczęciem migracji. Przed przeprowadzeniem migracji pozostałych pięciu elementów, jeśli jakiekolwiek zmiany zostaną wprowadzone w zasadach w magazynie klasycznym, zasady w zmodernizowanym magazynie nie zostaną zaktualizowane. Należy również wprowadzić te zmiany konfiguracji w zmodernizowanym sejfie.
Jak mogę zmigrować zreplikowane elementy, które znajdują się w grupie replikacji, znanej również jako grupy spójności z wieloma maszynami wirtualnymi?
Wszystkie replikowane elementy, które są częścią grupy replikacji, są migrowane razem. Możesz wybrać wszystkie z nich, wybierając grupę replikacji lub pomiń je wszystkie. Jeśli proces migracji zakończy się niepowodzeniem dla niektórych maszyn w grupie replikacji, ale uda się dla innych, środowisko klasyczne jest przywracane dla replikowanych elementów, które zakończyły się niepowodzeniem, a proces migracji może zostać ponownie uruchomiony dla tych elementów.
Czy mogę przeprowadzić migrację klasycznej konfiguracji z publicznym punktem końcowym w celu modernizacji konfiguracji z prywatnym punktem końcowym?
Nie, można przenieść klasyczną konfigurację odzyskiwania po awarii z publicznym punktem końcowym do zmodernizowanej konfiguracji z publicznym punktem końcowym. Pamiętaj, że migracja nieprywatnego punktu końcowego do prywatnego punktu końcowego nie jest obsługiwana, ale migracja prywatnego punktu końcowego do prywatnego punktu końcowego jest obsługiwana.
Następne kroki
- Dowiedz się , jak przejść z klasycznego do zmodernizowanego odzyskiwania po awarii programu VMware.