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 klasycznym magazynie usługi Recovery Services | Co najmniej jeden zreplikowany element chroniony przy użyciu architektury klasycznej i serwera konfiguracji w dobrej kondycji. 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 replikacji usługi Azure Site Recovery, które umożliwia odnajdywanie maszyn lokalnych, ze wszystkimi składnikami uaktualnionymi do najnowszej wersji (9.50 lub nowsza). Dokładne wymagane wersje są następujące: Serwer przetwarzania: 9.50 Serwer proxy: 1.35.8419.34591 Agent usługi Recovery Services: 2.0.9249.0 Usługa replikacji: 1.35.8433.24227 |
Wymagana infrastruktura
Upewnij się, że poniżej przedstawiono pomyślne przenoszenie replikowanego elementu:
- Magazyn usługi Recovery Services korzystający z zmodernizowanego środowiska.
Uwaga
Każdy nowy utworzony magazyn usługi Recovery Services będzie domyślnie włączony 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, które zostało pomyślnie zarejestrowane w magazynie, a wszystkie jego składniki są w stanie niekrytycznym.
- Wersja urządzenia musi być w wersji 9.50 lub nowszej. 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 do zmodernizowanej architektury upewnij się, że przed przejściem z architektury klasycznej wykonaj następujące czynności:
- Utwórz magazyn usługi Recovery Services i upewnij się, że środowisko nie zostało przełączone na klasyczny
- Wdrażanie urządzenia replikacji usługi Azure Site Recovery.
- Dodaj szczegóły programu vCenter Server maszyny lokalnej do urządzenia, aby pomyślnie wykonać odnajdywanie.
Przygotowywanie klasycznego magazynu usługi Recovery Services
Upewnij się, że w przypadku replikowanych elementów planujesz przenieść następujące elementy:
- Replikowany element jest maszyną wirtualną VMware lub fizyczną repliką za pośrednictwem serwera konfiguracji.
- Replikacja nie występuje na koncie magazynu niezarządzanego, ale w przypadku dysku zarządzanego.
- 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 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 w stanie niekrytycznym lub punkty odzyskiwania są tworzone pomyślnie.
Przygotowywanie zmodernizowanego magazynu usługi Recovery Services
W przypadku zmodernizowanej konfiguracji architektury upewnij się, że:
- Magazyn usługi Recovery Services używany do modernizacji 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 magazynie.
- 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.
Obliczanie całkowitego czasu przenoszenia
Łączny czas wymagany do przeniesienia dowolnego replikowanego elementu z magazynu klasycznego do zmodernizowanego magazynu zależy od stanu replikacji elementu i rozmiaru dysku.
| Stan | Czas migracji do zmodernizowanego magazynu |
|---|---|
| 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 rozmiaru i pojemności urządzenia replikacji.
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 klasycznym magazynie, jeśli był jeden serwer konfiguracji i cztery serwery przetwarzania, należy skonfigurować cztery urządzenia replikacji w zmodernizowanym magazynie usługi Recovery Services.
Cennik
Opłata licencyjna za usługę Site Recovery będzie nadal naliczana w klasycznym magazynie do czasu wygaśnięcia okresu przechowywania wszystkich punktów odzyskiwania. Po wyczyszczeniu wszystkich punktów odzyskiwania ceny również zostaną zatrzymane w klasycznym magazynie. Po wygaśnięciu okresu przechowywania wszystkich punktów odzyskiwania replikowany element zostanie automatycznie usunięty za pośrednictwem operacji replikacji wyzwalanej 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 magazynie klasycznym oczekują jakiekolwiek dni użycia bezpłatnej wersji próbnej, te same informacje zostaną przekazane do zmodernizowanego magazynu. Ceny zaczną się od zmodernizowanego magazynu dopiero po upływie tego okresu próbnego.
Uwaga
W pewnym momencie ceny będą miały miejsce tylko przy użyciu jednego magazynu — klasycznego lub zmodernizowanego magazynu.
Często zadawane pytania
Dlaczego należy migrować maszyny do zmodernizowanej architektury?
Należy pamiętać, że klasyczna architektura odzyskiwania po awarii zostanie wycofana, aby użytkownicy musieli przejść do najnowszej i zmodernizowanej wersji. 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. |
| Obszerna liczba kroków wymaganych do początkowego dołączania. | Uproszczone środowisko dołączania przez automatyzację tworzenia artefaktów i wprowadzenie domyślnych wartości domyślnych 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. |
| Obszerna liczba kroków wymaganych do prostego procesu replikacji. | Uproszczone środowisko włączania replikacji przez zmniejszenie liczby wymaganych danych wejściowych i ponowne zdefiniowanie każdego bloku. |
| 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 przetwarzania skalowalnego w poziomie i głównego serwera docelowego na platformie Azure dla maszyn z systemem Linux jest utrudniona. | 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ługa mobilności. |
| Serwer konfiguracji nie ma wysokiej dostępności i może być narażony na zwijanie. | Zaimplementowano wysoką dostępność urządzenia w celu zapewnienia odporności. |
| Poświadczenia główne powinny być regularnie aktualizowane w celu zapewnienia wolnego od błędu środowiska uaktualniania. | Wyeliminowano wymaganie obsługi poświadczeń głównych maszyny na potrzeby przeprowadzania automatycznych uaktualnień. |
| Statyczny adres IP należy przypisać do serwera konfiguracji w celu zachowania łączności. | Wprowadzono łączność opartą na nazwie FQDN między urządzeniem a maszynami lokalnymi. |
| 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 usługi Recovery Services.
Kiedy moja operacja migracji zostanie oznaczona jako ukończona?
Operacja migracji zostanie oznaczona tylko po pomyślnym utworzeniu pierwszego punktu odzyskiwania w zmodernizowanym magazynie usługi Recovery Services.
Jakie operacje można wykonać z klasycznego magazynu usługi Recovery Services po zakończeniu migracji?
Przejście w tryb failover z klasycznego magazynu można wykonać 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 usługa Azure Site Recovery automatycznie wyzwoli operację replikacji przeczyszczania na zreplikowanym elemencie i przeprowadzi oczyszczanie wszystkich skojarzonych elementów magazynu i elementów powodujących 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ę trybu 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ę trybu failover, będzie ona mieć pierwszeństwo przed operacją migracji, a zadanie migracji zostanie przerwane. Aby upewnić się, że zreplikowany element jest migrowany, należy ponownie wyzwolić operację migracji w późniejszym czasie.
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 zmodernizowanym magazynie usługi Recovery Services.
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, które mają być używane w nowym magazynie?
Nie, te same zasoby, które były wcześniej używane, również będą domyślnie używane w zmodernizowanym magazynie. Zawsze można je zmienić z bloku Obliczenia i sieć 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.
Zasady replikacji utworzone w zmodernizowanym magazynie zostaną zmienione w zmodernizowanym magazynie. Jest ona poprzedzona nazwą grupy zasobów i nazwą magazynu zmodernizowanego magazynu usługi 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 klasycznym magazynie?
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. Teraz przed przeprowadzeniem migracji pozostałych pięciu elementów, jeśli jakiekolwiek zmiany zostaną wprowadzone w zasadach w magazynie klasycznym, zasady z zmodernizowanego magazynu nie zostaną zaktualizowane. Należy również wprowadzić te zmiany konfiguracji w zmodernizowanym magazynie.
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 zakończy się powodzeniem dla innych, wycofywanie środowiska klasycznego jest wykonywane dla nieudanych replikowanych elementów, a proces migracji może zostać ponownie wyzwolony 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 tylko z publicznym punktem końcowym, aby zmodernizować konfigurację publicznego punktu końcowego. Pamiętaj, że migracja prywatnego 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.