Migrowanie obciążeń do Rozwiązanie Azure VMware

Ten artykuł zawiera wskazówki ułatwiające osobom podejmującym decyzje definiowanie strategii migracji dla Rozwiązanie Azure VMware, w tym fazy planowania, wykonywania i likwidowania.

Diagram przedstawiający proces Cloud Adoption Framework firmy Microsoft na potrzeby wdrażania Rozwiązanie Azure VMware.

Rozwiązanie Azure VMware zapewnia strukturę migracji obciążeń opartych na oprogramowaniu VMware do Azure przy minimalnych zmianach aplikacji. Powodzenie zależy od więcej niż przenoszenia maszyn wirtualnych. Organizacje potrzebują jasnych zasad migracji, kryteriów oceny obciążenia, standardów walidacji i kontroli wykonywania, które zmniejszają ryzyko, utrzymują ciągłość działania i obsługują długoterminowe cele platformy.

Zalecenie: Zdefiniuj strategię migracji, podejście do oceny obciążenia, sekwencję migracji i wymagania dotyczące walidacji przed migracją obciążeń do Rozwiązanie Azure VMware.

1. Planowanie migracji

Zanim zaczniesz cokolwiek projektować, stwórz jasny obraz tego, co migrujesz, w jakiej kolejności i dlaczego. Skorzystaj z metodologii planu Cloud Adoption Framework, aby ocenić majątek. Rozwiązanie Azure VMware najlepiej sprawdza się w podejściu typu rehost, gdy potrzebne są minimalne zakłócenia i nie planuje się modernizacji w najbliższym czasie. Nie jest to właściwe miejsce dla każdej aplikacji, a o tym decydujesz na etapie planowania.

1.1 Odnajdywanie i spis

Azure Migrate skanuje lokalne środowisko vSphere i tworzy spis maszyn wirtualnych, ich użycia zasobów i ich zależności. Te dane informują o określaniu rozmiaru (liczby hostów i typie hosta) oraz planowaniu fal (które obciążenia są przenoszone razem). Azure Migrate nie wykonuje przenoszenia do Rozwiązanie Azure VMware. Zawiera on dowody rozmiaru i sekwencji projektu.

1.2 Strategia migracji

Rozwiązanie Azure VMware obsługuje przede wszystkim podejście rehost. Aplikacje, które wymagają refaktoryzacji lub zmiany architektury, mogą lepiej korzystać z natywnych usług obliczeniowych platformy Azure. Zarejestruj te decyzje, aby plan odzwierciedlał celowe wybory, a nie wartości domyślne. Zobacz Wybieranie strategii migracji do chmury.

1.3 Ocena obciążenia

Nie każde obciążenie jest równie odpowiednim kandydatem do Rozwiązanie Azure VMware. Przed przypisaniem obciążeń do fal migracji należy ocenić ich wymagania techniczne, zależności operacyjne i dopasowanie platformy. Ocena ustrukturyzowana ułatwia wczesne identyfikowanie zagrożeń, weryfikowanie przydatności i zapewnienie, że plany migracji odzwierciedlają priorytety biznesowe, a nie założenia.

1.3.1 Wymagania

Przed przypisaniem obciążenia do fali migracji należy ocenić wymagania techniczne, operacyjne i biznesowe wpływające na jego sukces w Rozwiązanie Azure VMware. Ta ocena ułatwia określenie przydatności platformy, zidentyfikowanie potencjalnych wyzwań związanych z migracją oraz dostarczenie informacji potrzebnych do podejmowania decyzji dotyczących ustalania rozmiaru, sekwencjonowania i gotowości. Podczas oceniania poszczególnych obciążeń skoncentruj się na:

  • Wymagania dotyczące wydajności: Zrozum zapotrzebowanie na moc procesora, pamięć, IOPS pamięci masowej i przepustowość sieci. Przypisz te wymagania do jednostek SKU hostów usługi Rozwiązanie Azure VMware oraz zasad przechowywania vSAN, w tym konfiguracji RAID i ustawień tolerancji awarii (FTT).

  • Zależności aplikacji: Określ, z którymi systemami komunikuje się każde obciążenie. Zależności określają planowanie fali migracji i czy systemy zależne muszą się łączyć.

  • Wymagania dotyczące zgodności: Upewnij się, że systemy operacyjne gościa i oprogramowanie innych firm są obsługiwane w Rozwiązanie Azure VMware. Większość obciążeń roboczych uruchamianych lokalnie w środowisku vSphere działa w usłudze Rozwiązanie Azure VMware bez modyfikacji, ale należy to zweryfikować, zamiast zakładać, oraz upewnić się, że testujesz procedurę wycofania na wypadek problematycznych migracji.

  • Wymagania dotyczące sieci: Udokumentowanie segmentów sieci, adresów IP, konfiguracji DNS i reguł zapory, których wymaga każde obciążenie. Zidentyfikuj obciążenia wrażliwe na opóźnienia i upewnij się, że architektura sieci jest zoptymalizowana pod kątem obsługi ich wymagań.

1.3.2 Leczenie obciążenia

Ocena obciążenia określa, czego potrzebuje obciążenie. Leczenie obciążenia określa, jakie działania należy podjąć. Osoby podejmujące decyzje powinny ocenić, czy każda aplikacja należy do Rozwiązanie Azure VMware, czy powinna pozostać lokalna, czy też części aplikacji są lepiej obsługiwane przez usługi Azure natywne. Dla każdego obciążenia określ:

  • Czy obciążenie robocze należy tam. Obciążenia robocze, które już dobrze działają w środowisku vSphere, to naturalni kandydaci, zwłaszcza te, dla których nie planuje się modernizacji w najbliższym czasie. W przypadku obciążenia zmierzającego do wycofania lub zastąpienia przez rozwiązanie SaaS należy rozważyć, czy jego przeniesienie przyniesie wartość, czy też powinno ono pozostać tam, gdzie jest, do końca cyklu życia.

  • Czy każda warstwa należy do niej. Obciążenie często ma więcej niż jedną warstwę, taką jak fronton internetowy i baza danych. Maszyny wirtualne aplikacji można uruchamiać w usłudze Rozwiązanie Azure VMware i łączyć je z natywnymi usługami danych platformy Azure, takimi jak Azure SQL Database. Ta konfiguracja zapewnia korzyści związane z zarządzaną bazą danych wraz z obciążeniami programu VMware oraz zmniejsza koszty hostów i licencji VMware.

1.4 Gotowość do migracji

Zdefiniuj minimalne wymagania operacyjne, wydajności, zabezpieczeń i ładu, które muszą spełniać każde obciążenie przed zatwierdzeniem go do użytku produkcyjnego.

Zastosuj spójną strukturę weryfikacji dla każdej fali migracji. Ramy powinny określać wymagane kontrole, kryteria zatwierdzenia oraz dowody, które zespoły muszą przedstawić przed zatwierdzeniem przełączenia. Zweryfikuj co najmniej:

  • Stan replikacji HCX

  • Osiągalność segmentu NSX

  • Kondycja hosta ESXi

  • Osiągalność usług tożsamości i uwierzytelniania z segmentu docelowego

  • Kondycja usług pomocniczych, takich jak tworzenie kopii zapasowych i monitorowanie

Zdecyduj, czy zespoły muszą przechwytywać metryki wydajności punktu odniesienia ze środowiska źródłowego przed migracją. Te pomiary stanowią punkt odniesienia do weryfikowania wydajności po migracji i identyfikowania regresji.

Przed przełączeniem należy wymagać od zespołów określenia, czy zewnętrzne rekordy DNS, konfiguracje modułu równoważenia obciążenia, punkty końcowe aplikacji lub inne zależności związane z łącznością wymagają aktualizacji. Uwzględnij wszystkie wymagane zmiany w planie przełączenia dla danej fali, aby zmniejszyć ryzyko zakłóceń w świadczeniu usług.

1.5 Rozwiązanie Azure VMware sekwencja migracji

Sekwencjonowanie migracji określa, które obciążenia przechodzą do Rozwiązanie Azure VMware pierwsze, drugie itd. Dobre planowanie fali zmniejsza ryzyko i pozwala uniknąć niepotrzebnych zakłóceń.

  • Grupuj według zależności: Użyj danych zależności z odnajdywania, aby znaleźć zestawy maszyn wirtualnych, które współpracują ze sobą, takie jak serwer aplikacji i jego baza danych. Przenieś je w ramach tej samej fali, aby ruch nie musiał przechodzić przez sieć przy każdym żądaniu, gdy jedna część nadal pozostaje w środowisku lokalnym.

  • Przeanalizuj istniejące reguły: Udokumentuj wszelkie reguły kolokacji i antykolokacji w środowisku lokalnym oraz zaplanuj sposób ich odtworzenia. Rozwiązanie Azure VMware zasady rozmieszczania wymuszają powiązanie maszyn wirtualnych z hostami, co ma znaczenie w przypadku ograniczeń licencyjnych, takich jak SQL Server, oraz ścisłych wymagań dotyczących wydajności.

  • Sekwencja według ryzyka: Zacznij od obciążeń o niższym ryzyku, takich jak systemy nieprodukcyjne lub aplikacje z kilkoma zależnościami. Twój zespół zwiększa zaufanie do procesu, zanim zajmie się aplikacjami krytycznymi dla działania firmy. Przechodź do bardziej złożonych obciążeń wraz ze wzrostem doświadczenia.

  • Dopasuj do planów rozszerzeń sieciowych: Sekwencja jest oparta na układzie sieci lokalnej. Gdy kilka aplikacji współużytkuje segment sieci, zmigruj je na tej samej fali lub w kolejnych falach. Następnie można szybko przełączyć segment na natywną sieć rozwiązania Rozwiązanie Azure VMware i usunąć tymczasowe rozszerzenie.

1.6 Narzędzia migracji

Użyj rozwiązania VMware HCX, aby przenieść obciążenia do Rozwiązanie Azure VMware z minimalnymi zakłóceniami. Rozwiązanie HCX Enterprise jest domyślnie uwzględniane bez dodatkowych kosztów i instalowane, co umożliwia odblokowywanie opcji, takich jak replikacja asystowana vMotion i sieć zoptymalizowana pod kątem mobilności. Nie musisz używać rozwiązania HCX i możesz również wprowadzać obciążenia fizyczne przy użyciu rozwiązania do migracji partnera.

1.6.1 Podejście do migracji

Funkcja vMotion przenosi działające obciążenie robocze bez przerywania pracy, a w systemie Generation 2 zazwyczaj działa szybciej niż metody masowe. Migracja wspomagana replikacją i migracja zbiorcza mogą obecnie działać wolniej w Generacji 2, dlatego zaplanuj dłuższe okna i odpowiednio rozłóż fale migracji. Zobacz zagadnienia dotyczące projektowania chmury prywatnej generacji 2 Rozwiązanie Azure VMware.

1.6.2 Zarządzanie rozszerzeniami sieci

Niektóre zespoły traktują rozszerzenie sieci jako trwały projekt. To nie jest. Zachowaj otwarte rozszerzenia tylko dla okna migracji. Rozszerzenie sieci HCX rozciąga sieć lokalną na Rozwiązanie Azure VMware w warstwie 2, dzięki czemu obciążenia zachowują istniejące adresy podczas przenoszenia. Ten projekt pozwala uniknąć ponownego konfigurowania aplikacji z góry i wiąże się z kompromisami, którymi musi zarządzać twórca decyzji.

  • Zależność lokalna. Sieć rozszerzona zwykle utrzymuje swoją bramę lokalnie, więc obciążenie nadal zależy od lokacji źródłowej po jej przesunieniu.

  • Nieefektywne trasowanie. Ruch może wracać do środowiska lokalnego i z powrotem — jest to zjawisko zwane tromboningiem, które zwiększa opóźnienia i liczbę punktów awarii.

Ustawianie zasad firmowych. Rozszerzanie sieci tylko wtedy, gdy obciążenie nie może zmienić adresu i usunąć każde rozszerzenie po przeniesieniu obciążeń. Najpierw oceń sieć lokalną, aby wiedzieć, które segmenty wymagają rozszerzenia i jak długo. Ta ocena stanowi podstawę zarówno planu wdrożenia falowego, jak i harmonogramu rozszerzenia. Optymalizacja sieci pod kątem mobilności może w określonych przypadkach ograniczyć zjawisko tromboningu, dlatego przed jej włączeniem sprawdź obsługiwane konfiguracje. Zobacz Konfigurowanie rozszerzenia sieciowego HCX.

2. Przygotowanie migracji

Poniższa sekwencja wdrażania odzwierciedla zależności między etapami. Każdy krok zakłada, że poprzedni krok został ukończony i zweryfikowany.

  1. Strefa docelowa platformy: Upewnij się, że wszystkie wymagane scentralizowane usługi sieciowe, tożsamości, zabezpieczeń i monitorowania są gotowe do integracji z obciążeniami Azure VMware. Zastosuj linie bazowe nadzoru i zabezpieczeń przy użyciu Azure Policy w hierarchii grup zarządzania, aby ułatwić spełnienie wymagań dotyczących zgodności. Generacja 2 jest wdrażana do Twojej sieci wirtualnej, więc bazowy zestaw zasad, który wymusza rygorystyczne reguły dotyczące grup zabezpieczeń sieciowych lub tabel tras, może zablokować wdrożenie. Usuń te określone zasady z sieci wirtualnej chmury prywatnej przed wdrożeniem, a następnie zastosuj je ponownie. Zaplanuj ten wyjątek w planie bazowym, aby ład nie zatrzymał wdrożenia.

  2. Strefy docelowe obciążeń: Umieść strefy docelowe obciążeń (subskrypcje) w odpowiedniej grupie zarządzania, internetowej lub wewnętrznej („Corp”).

  3. Zakresy adresów IP: Zarezerwuj co najmniej /22 blok adresów dla chmury prywatnej. W generacji 2 należy również zarezerwować dwa dodatkowe bloki /24 na potrzeby zarządzania HCX i łącza uplink. Upewnij się, że żaden z tych zakresów nie nakłada się na lokalną, Azure lub inną przestrzeń adresową chmury. Nie można łatwo poprawić tego warunku po wdrożeniu. Zobacz Zagadnienia dotyczące projektowania generacji 2.

  4. Żądanie limitu przydziału: Wcześniej zażądaj limitu przydziału, ponieważ alokacja może potrwać do pięciu dni roboczych. Zaplanuj wystarczające zasoby na potrzeby rozwoju i odtwarzania po awarii, takie jak nadmiarowość N+1, czyli o jeden host więcej, niż wymaga obciążenie. Upewnij się, że wymagana jest licencja programu Portable VMware Cloud Foundation na nowe wdrożenia. Zobacz Żądanie limitu przydziału hosta.

  5. Wdrażanie chmury prywatnej Rozwiązanie Azure VMware: Wdróż chmurę prywatną 2. generacji w jego sieci wirtualnej platformy Azure. Zobacz Tworzenie chmury prywatnej generacji 2.

  6. Konfiguracja sieci i tożsamości: Skonfiguruj komunikację równorzędną między siecią chmury prywatnej a koncentratorem i skonfiguruj łączność lokalną. Połącz program vCenter Server ze źródłem tożsamości zewnętrznej, aby administratorzy logowali się przy użyciu kont zarządzanych zamiast udostępnionych wbudowanych poświadczeń.

  7. Monitorowanie i zarządzanie: Przekazywanie dzienników do rozwiązania do zarządzania dziennikami i konfigurowanie alertów usługi Service Health. Wdróż wirtualne maszyny gościa za pośrednictwem Azure Arc, aby zarządzać nimi za pomocą tych samych narzędzi platformy Azure, których używasz w innych środowiskach.

  8. Instalacja ROZWIĄZANIA HCX: Przed rozpoczęciem pierwszej fali zainstaluj rozwiązanie HCX i przetestuj łączność typu lokacja-lokacja.

3. Wykonanie migracji

Zdefiniuj, co "gotowe" oznacza przed każdą falą. Etap jest zakończony, gdy obciążenie zostało zweryfikowane, rozszerzenie sieci zostało usunięte, a aplikacja działa prawidłowo w swoim stanie docelowym.

Zdefiniuj kryteria wycofywania przed każdą falą i przetestuj ścieżkę wycofywania przed migracją systemów produkcyjnych. Rozwiązanie HCX obsługuje migrację odwrotną, a dokładne podejście zależy od użytego typu migracji. Kryteria powodzenia fali obejmują:

  1. Każda maszyna wirtualna w tej fali działa w usłudze Rozwiązanie Azure VMware i nie wymaga już rozszerzenia sieci na potrzeby ruchu produkcyjnego.

  2. Każda aplikacja jest osiągalna przez użytkowników i systemy zależne.

  3. Każda maszyna wirtualna jest wyświetlana w narzędziach do monitorowania bez ostrzeżeń ani błędów.

  4. Wycofanie zmian nie jest już potrzebne i można formalnie zamknąć ten proces.

  5. Wydajność aplikacji dorównuje wartości bazowej lub ją przewyższa.

  6. Obciążenia spełniają wymagania dotyczące zabezpieczeń i zgodności.

  7. Obciążenie zostało pomyślnie dołączone do rozwiązań do tworzenia kopii zapasowych i odzyskiwania po awarii.

4. Ocena migracji i likwidacja

Migracja nie kończy się, gdy obciążenia są włączone w Rozwiązanie Azure VMware. Sprawdź, czy obciążenia robocze działają prawidłowo w nowym środowisku, upewnij się, że tymczasowe rozwiązania wdrożone na potrzeby migracji zostały usunięte, i formalnie wycofaj z eksploatacji infrastrukturę źródłową. Pozostawienie infrastruktury lokalnej może spowodować nieodkryte i nieudokumentowane zależności. Zdyscyplinowany proces oceny i likwidowania zapewnia, że organizacja realizuje oczekiwane korzyści z migracji bez przenoszenia niepotrzebnych kosztów operacyjnych lub ryzyka.

4.1 Gotowość produkcyjna po przełączeniu

Należy określić kryteria po przełączeniu, które potwierdzą, że obciążenie robocze działa zgodnie z oczekiwaniami. Sprawdź dostępność sieci i rozpoznawanie nazw. Sprawdź funkcję aplikacji i komunikację z systemami zależnymi. Po przeniesieniu każdej maszyny wirtualnej potwierdź, że uruchamia się ona poprawnie, że jej zasoby są zgodne z planem oraz że ma zastosowanie właściwa polityka pamięci masowej. Porównaj wydajność z punktem odniesienia przed migracją.

Zdecyduj o zasadach dotyczących parzystości. Kluczową decyzją jest to, czy zmigrowane obciążenie robocze musi osiągnąć pełną zgodność ze stanem środowiska lokalnego, zanim zostanie uznane za gotowe do użycia produkcyjnego, czy też dopuszczasz tymczasowe odstępstwa. Wiele organizacji wymaga natychmiastowej parzystości wydajności dla systemów przeznaczonych dla klientów, ale przyznaje aplikacjom wewnętrznym krótki okres stabilizacji z ustalonym terminem korygowania.

4.2 Sprawdzanie poprawności łączności

Zweryfikuj kompleksową łączność między Rozwiązanie Azure VMware, Azure, lokalną, Internetem i rozpoznawaniem nazw. Uruchom testy dymne aplikacji, aby potwierdzić, że obciążenie robocze spełnia swoje zadanie. Sprawdź, czy należy zaktualizować zewnętrzne rekordy nazw lub ustawienia modułu równoważenia obciążenia w ramach przełączenia.

Jeśli utworzono pomocnicze wystąpienie Rozwiązanie Azure VMware na potrzeby odzyskiwania po awarii, upewnij się, że jest ono osiągalne zarówno z poziomu wystąpienia podstawowego, jak i ze strony wszystkich klientów lub usług pomocniczych, które muszą się z nim połączyć w razie jego aktywacji.

4.3 Likwidacja rozszerzenia sieci

Gdy wszystkie obciążenia robocze w rozszerzonym segmencie zostaną przeniesione, usuń rozszerzenie HCX Layer 2 i upewnij się, że brama natywna usługi Rozwiązanie Azure VMware prawidłowo kieruje ruchem. Nie pozostawiaj rozszerzenia na dłużej, niż wymaga tego migracja.

4.4 Likwiduj środowisko źródłowe

Wycofanie oznacza formalne zwolnienie zasobów źródłowych, licencji i obsługi operacyjnej. Traktuj to raczej jako kontrolowane przekazanie niż jako zadanie porządkowe. Jeśli nie przeprowadzasz wycofania z eksploatacji, płacisz za nieużywaną infrastrukturę i utrzymujesz ryzyko związane z bezpieczeństwem. Użyj likwidowania obciążeń źródłowych po migracji do chmury , aby ustawić kolejność operacji, okres przechowywania kopii zapasowych źródłowych, zatwierdzenia wymagane do wyłączenia systemów źródłowych oraz kryteria odzyskiwania licencji i sprzętu.

Następne kroki

Projekt obciążenia:

  • Last updated on