Udostępnij za pośrednictwem

Planowanie migracji zasobów rozwiązania IaaS z wdrożenia klasycznego do usługi Azure Resource Manager

  • Artykuł

Dotyczy: ✔️ Maszyny wirtualne z systemem Linux maszyny wirtualne z ✔️ systemem Windows

Ważne

Obecnie około 90% maszyn wirtualnych IaaS korzysta z usługi Azure Resource Manager. Od 28 lutego 2020 r. klasyczne maszyny wirtualne zostały wycofane i zostaną w pełni wycofane 6 września 2023 r. Dowiedz się więcej o tym wycofaniu i sposobie jego wpływu na Ciebie.

Usługa Azure Resource Manager oferuje wiele niesamowitych funkcji, ale ważne jest, aby zaplanować podróż migracji, aby upewnić się, że wszystko działa bezproblemowo. Poświęcanie czasu na planowanie zapewni, że nie napotkasz problemów podczas wykonywania działań migracji.

Uwaga

Poniższe wskazówki zostały w dużym stopniu przyczyniły się do zespołu doradczego ds. klientów platformy Azure i architektów rozwiązań w chmurze pracujących z klientami w zakresie migrowania dużych środowisk. W związku z tym dokument będzie nadal aktualizowany w miarę pojawiania się nowych wzorców sukcesu, więc sprawdź od czasu do czasu, aby sprawdzić, czy istnieją jakieś nowe zalecenia.

Istnieją cztery ogólne fazy podróży migracji:

Fazy migracji

Planowanie

Zagadnienia techniczne i kompromisy

W zależności od rozmiaru wymagań technicznych, lokalizacji geograficznych i praktyk operacyjnych warto rozważyć następujące kwestie:

  1. Dlaczego usługa Azure Resource Manager jest wymagana dla twojej organizacji? Jakie są przyczyny biznesowe migracji?
  2. Jakie są przyczyny techniczne usługi Azure Resource Manager? Co (jeśli istnieją) inne usługi platformy Azure, których chcesz użyć?
  3. Która aplikacja (lub zestawy maszyn wirtualnych) jest uwzględniona w migracji?
  4. Które scenariusze są obsługiwane za pomocą interfejsu API migracji? Przejrzyj nieobsługiwane funkcje i konfiguracje.
  5. Czy twoje zespoły operacyjne będą teraz obsługiwać aplikacje/maszyny wirtualne zarówno w wersji klasycznej, jak i w usłudze Azure Resource Manager?
  6. Jak (jeśli w ogóle) usługa Azure Resource Manager zmienia procesy wdrażania maszyny wirtualnej, zarządzania, monitorowania i raportowania? Czy skrypty wdrażania muszą zostać zaktualizowane?
  7. Jaki jest plan komunikacji dotyczący powiadamiania uczestników projektu (użytkowników końcowych, właścicieli aplikacji i właścicieli infrastruktury)?
  8. W zależności od złożoności środowiska należy zastosować okres konserwacji, w którym aplikacja jest niedostępna dla użytkowników końcowych i właścicieli aplikacji? Jeśli tak, przez jak długi czas?
  9. Jaki jest plan szkoleniowy, aby zapewnić uczestnikom projektu wiedzę i biegłość w usłudze Azure Resource Manager?
  10. Jaki jest plan zarządzania programem lub zarządzania projektami na potrzeby migracji?
  11. Jakie są osie czasu migracji usługi Azure Resource Manager i innych powiązanych map rozwoju technologii? Czy są one optymalnie wyrównane?

Wzorce sukcesu

Pomyślni klienci mają szczegółowe plany, w których omawiane są poprzednie pytania, udokumentowane i zarządzane. Upewnij się, że plany migracji są szeroko przekazywane sponsorom i uczestnikom projektu. Uzysektuj sobie wiedzę na temat opcji migracji; Przeczytanie tego zestawu dokumentów migracji poniżej jest zdecydowanie zalecane.

Pułapki, aby uniknąć

  • Nie można zaplanować. Etapy technologiczne tej migracji są udowodnione, a wynik jest przewidywalny.
  • Założenie, że obsługiwany interfejs API migracji platformy będzie uwzględniać wszystkie scenariusze. Przeczytaj nieobsługiwane funkcje i konfiguracje, aby dowiedzieć się, jakie scenariusze są obsługiwane.
  • Nie planujesz potencjalnej awarii aplikacji dla użytkowników końcowych. Zaplanuj wystarczająco dużo buforu, aby odpowiednio ostrzegać użytkowników końcowych o potencjalnie niedostępnym czasie aplikacji.

Test laboratorium

Replikowanie środowiska i wykonywanie migracji testowej

Uwaga

Dokładna replikacja istniejącego środowiska jest wykonywana przy użyciu narzędzia współtworzonych przez społeczność, które nie jest oficjalnie obsługiwane przez pomoc techniczna firmy Microsoft. W związku z tym jest to opcjonalny krok, ale jest to najlepszy sposób na znalezienie problemów bez dotykania środowisk produkcyjnych. Jeśli korzystanie z narzędzia współtworzona przez społeczność nie jest opcją, zapoznaj się z zaleceniem Weryfikuj/Przygotuj/Przerwij przebieg suchy poniżej.

Przeprowadzenie testu laboratoryjnego dokładnego scenariusza (obliczeń, sieci i magazynu) jest najlepszym sposobem zapewnienia bezproblemowej migracji. Pomoże to zapewnić:

  • Całkowicie oddzielne laboratorium lub istniejące środowisko nieprodukcyjne do testowania. Zalecamy całkowicie oddzielne laboratorium, które można migrować wielokrotnie i można je modyfikować destruktywnie. Poniżej wymieniono skrypty do zbierania/nawilżania metadanych z rzeczywistych subskrypcji.

  • Dobrym pomysłem jest utworzenie laboratorium w oddzielnej subskrypcji. Powodem jest to, że laboratorium zostanie wielokrotnie rozdarte, a posiadanie oddzielnej, izolowanej subskrypcji zmniejszy prawdopodobieństwo przypadkowego usunięcia czegoś rzeczywistego.

    Można to zrobić za pomocą narzędzia AsmMetadataParser. Przeczytaj więcej na temat tego narzędzia tutaj

Wzorce sukcesu

W wielu większych migracjach wykryto następujące problemy. Nie jest to wyczerpująca lista. Aby uzyskać więcej szczegółów, zapoznaj się z nieobsługiwaną funkcją i konfiguracjami . Te problemy techniczne mogą wystąpić lub mogą nie występować, ale jeśli rozwiążesz je przed podjęciem próby migracji, zapewni sprawniejsze środowisko pracy.

  • Wykonaj weryfikację/przygotowanie/przerwanie przebiegu suchego — jest to być może najważniejszy krok, aby zapewnić powodzenie migracji klasycznej do usługi Azure Resource Manager. Interfejs API migracji ma trzy główne kroki: Weryfikowanie, przygotowywanie i zatwierdzanie. Weryfikacja odczytuje stan środowiska klasycznego i zwraca wynik wszystkich problemów. Jednak ponieważ niektóre problemy mogą istnieć w stosie usługi Azure Resource Manager, funkcja Validate nie przechwyci wszystkiego. W następnym kroku procesu migracji przygotowanie pomoże ujawnić te problemy. Przygotowanie spowoduje przeniesienie metadanych z klasycznego do usługi Azure Resource Manager, ale nie zatwierdzi przeniesienia i nie spowoduje usunięcia ani zmiany niczego po stronie klasycznej. Przebieg suchy obejmuje przygotowanie migracji, a następnie przerwanie (nie zatwierdzanie) przygotowania migracji. Celem weryfikacji/przygotowania/przerwania przebiegu suchego jest sprawdzenie wszystkich metadanych w stosie usługi Azure Resource Manager, sprawdzenie go (programowo lub w portalu) oraz sprawdzenie, czy wszystkie elementy są migrowane prawidłowo i działają przez problemy techniczne. Zapewni to również poczucie czasu trwania migracji, dzięki czemu można odpowiednio zaplanować przestój. Weryfikacja/przygotowanie/przerwanie nie powoduje przestoju użytkownika; w związku z tym użycie aplikacji nie jest niezwiązane z użyciem aplikacji.

    • Poniższe elementy należy rozwiązać przed suchym przebiegiem, ale test suchego przebiegu również bezpiecznie wypłukiwać te kroki przygotowywania, jeśli zostaną pominięte. Podczas migracji przedsiębiorstwa okazało się, że przebieg suchy jest bezpiecznym i nieocenionym sposobem zapewnienia gotowości do migracji.
    • Gdy przygotowanie jest uruchomione, płaszczyzna sterowania (operacje zarządzania platformą Azure) zostanie zablokowana dla całej sieci wirtualnej, więc podczas walidacji/przygotowania/przerwania nie można wprowadzać żadnych zmian w metadanych maszyny wirtualnej. Jednak w przeciwnym razie każda funkcja aplikacji (rd, użycie maszyny wirtualnej itp.) nie będzie miała wpływu. Użytkownicy maszyn wirtualnych nie będą wiedzieć, że jest wykonywany przebieg suchy.

  • Obwody usługi Express Route i sieć VPN. Obecnie nie można migrować bram usługi Express Route z linkami autoryzacji bez przestoju. Aby obejść ten problem, zobacz Migrowanie obwodów usługi ExpressRoute i skojarzonych sieci wirtualnych z modelu klasycznego do modelu wdrażania usługi Resource Manager.

  • Rozszerzenia maszyn wirtualnych — rozszerzenia maszyny wirtualnej są potencjalnie jednym z największych przeszkód w migracji uruchomionych maszyn wirtualnych. Korygowanie rozszerzeń maszyn wirtualnych może potrwać od 1 do 2 dni, więc odpowiednio zaplanuj. Do raportowania stanu rozszerzenia maszyny wirtualnej uruchomionych maszyn wirtualnych potrzebny jest działający agent platformy Azure. Jeśli stan jest nieprawidłowy dla uruchomionej maszyny wirtualnej, spowoduje to zatrzymanie migracji. Sam agent nie musi działać w celu włączenia migracji, ale jeśli rozszerzenia istnieją na maszynie wirtualnej, zarówno działający agent, jak i wychodząca łączność internetowa (z systemem DNS) będą potrzebne do migracji do przodu.

    • Jeśli łączność z serwerem DNS zostanie utracona podczas migracji, wszystkie rozszerzenia maszyn wirtualnych z wyjątkiem BGInfo w wersji 1.* należy najpierw usunąć z każdej maszyny wirtualnej przed przygotowaniem migracji, a następnie ponownie dodać je z powrotem do maszyny wirtualnej po migracji usługi Azure Resource Manager. Dotyczy to tylko maszyn wirtualnych, które są uruchomione. Jeśli przydział maszyn wirtualnych zostanie zatrzymany, rozszerzenia maszyn wirtualnych nie muszą być usuwane. Uwaga: wiele rozszerzeń, takich jak diagnostyka platformy Azure i monitorowanie Defender dla Chmury, zostanie ponownie zainstalowanych po migracji, więc usunięcie ich nie jest problemem.

    • Ponadto upewnij się, że sieciowe grupy zabezpieczeń nie ograniczają wychodzącego dostępu do Internetu. Może się to zdarzyć w przypadku niektórych konfiguracji sieciowych grup zabezpieczeń. Do migracji rozszerzeń maszyn wirtualnych do usługi Azure Resource Manager wymagany jest wychodzący dostęp do Internetu (i system DNS).

    • Istnieją dwie wersje rozszerzenia BGInfo: v1 i v2. Jeśli maszyna wirtualna została utworzona przy użyciu witryny Azure Portal lub programu PowerShell, maszyna wirtualna prawdopodobnie będzie mieć na nim rozszerzenie w wersji 1. To rozszerzenie nie musi zostać usunięte i zostanie pominięte (nie zmigrowane) przez interfejs API migracji. Jeśli jednak klasyczna maszyna wirtualna została utworzona za pomocą nowej witryny Azure Portal, prawdopodobnie będzie miała wersję JSON w wersji 2 BGInfo, którą można zmigrować do usługi Azure Resource Manager, pod warunkiem, że agent działa i ma wychodzący dostęp do Internetu (i DNS).

    • Opcja korygowania 1. Jeśli wiesz, że maszyny wirtualne nie będą miały wychodzącego dostępu do Internetu, działającej usługi DNS i działających agentów platformy Azure na maszynach wirtualnych, odinstaluj wszystkie rozszerzenia maszyn wirtualnych w ramach migracji przed przygotowaniem, a następnie ponownie zainstaluj rozszerzenia maszyn wirtualnych po migracji.

    • Opcja korygowania 2. Jeśli rozszerzenia maszyn wirtualnych są zbyt duże, inną opcją jest zamknięcie/cofnięcie przydziału wszystkich maszyn wirtualnych przed migracją. Przeprowadź migrację cofniętych maszyn wirtualnych, a następnie uruchom je ponownie po stronie usługi Azure Resource Manager. Korzyścią jest to, że rozszerzenia maszyn wirtualnych zostaną zmigrowane. Wadą jest to, że wszystkie publiczne adresy IP wirtualne zostaną utracone (może to być nieruchome) i oczywiście maszyny wirtualne zostaną zamknięte, co spowoduje znacznie większy wpływ na działające aplikacje.

      Uwaga

      Jeśli zasady Microsoft Defender dla Chmury są skonfigurowane pod kątem migrowanych uruchomionych maszyn wirtualnych, zasady zabezpieczeń należy zatrzymać przed usunięciem rozszerzeń. W przeciwnym razie rozszerzenie monitorowania zabezpieczeń zostanie automatycznie ponownie zainstalowane na maszynie wirtualnej po jego usunięciu.

  • Zestawy dostępności — aby sieć wirtualna (sieć wirtualna) została zmigrowana do usługi Azure Resource Manager, wdrożenie klasyczne (tj. usługa w chmurze) zawierało maszyny wirtualne muszą znajdować się w jednym zestawie dostępności lub maszyny wirtualne nie mogą znajdować się w żadnym zestawie dostępności. Posiadanie więcej niż jednego zestawu dostępności w usłudze w chmurze nie jest zgodne z usługą Azure Resource Manager i zatrzyma migrację. Ponadto niektóre maszyny wirtualne nie mogą znajdować się w zestawie dostępności, a niektóre maszyny wirtualne nie znajdują się w zestawie dostępności. Aby rozwiązać ten problem, należy skorygować lub przetasować usługę w chmurze. Zaplanuj odpowiednio, ponieważ może to być czasochłonne.

  • Wdrożenia ról sieci Web/procesu roboczego — usługi w chmurze zawierające role sieci Web i procesu roboczego nie mogą migrować do usługi Azure Resource Manager. Przed rozpoczęciem migracji należy najpierw usunąć role sieci web/procesu roboczego z sieci wirtualnej. Typowym rozwiązaniem jest przeniesienie wystąpień roli sieci Web/procesu roboczego do oddzielnej klasycznej sieci wirtualnej połączonej również z obwodem usługi ExpressRoute lub migracji kodu do nowszych usług PaaS App Services (ta dyskusja wykracza poza zakres tego dokumentu). W poprzednim przypadku ponownego wdrażania utwórz nową klasyczną sieć wirtualną, przenieś/ponownie wdróż role sieci Web/procesu roboczego w tej nowej sieci wirtualnej, a następnie usuń wdrożenia z sieci wirtualnej, która jest przenoszona. Nie są wymagane żadne zmiany kodu. Nowa funkcja komunikacji równorzędnej sieci wirtualnych może służyć do komunikacji równorzędnej klasycznej sieci wirtualnej zawierającej role sieci web/procesu roboczego i innych sieci wirtualnych w tym samym regionie świadczenia usługi Azure, takich jak migrowana sieć wirtualna (po zakończeniu migracji sieci wirtualnej jako równorzędne sieci wirtualne nie mogą być migrowane), dlatego zapewniają te same możliwości bez utraty wydajności i żadnych kar za opóźnienie/przepustowość. Biorąc pod uwagę dodanie komunikacji równorzędnej sieci wirtualnych, wdrożenia ról sieci Web/procesu roboczego można teraz łatwo ograniczyć i nie blokować migracji do usługi Azure Resource Manager.

  • Przydziały usługi Azure Resource Manager — regiony platformy Azure mają oddzielne limity przydziału/limity zarówno dla wersji klasycznej, jak i usługi Azure Resource Manager. Mimo że w scenariuszu migracji nowy sprzęt nie jest używany (zamieniamy istniejące maszyny wirtualne z wersji klasycznej na usługę Azure Resource Manager), przydziały usługi Azure Resource Manager nadal muszą być spełnione z wystarczającą pojemnością przed rozpoczęciem migracji. Poniżej wymieniono główne limity, które widzieliśmy, powodują problemy. Otwórz bilet pomocy technicznej limitu przydziału, aby zwiększyć limity.

    Uwaga

    Te limity należy podnieść w tym samym regionie, w którym ma zostać zmigrowane bieżące środowisko.

    • Interfejsy sieciowe

    • Usługi równoważenia obciążenia

    • Publiczne adresy IP

    • Statyczne publiczne adresy IP

    • Rdzenie

    • Grupy zabezpieczeń sieci

    • Tabele tras

      Bieżące limity przydziału usługi Azure Resource Manager można sprawdzić przy użyciu następujących poleceń z najnowszą wersją interfejsu wiersza polecenia platformy Azure.

      Obliczenia (rdzenie, zestawy dostępności)

      az vm list-usage -l <azure-region> -o jsonc

      Sieć (sieci wirtualne, statyczne publiczne adresy IP, publiczne adresy IP, sieciowe grupy zabezpieczeń, interfejsy sieciowe, moduły równoważenia obciążenia, tabele tras)

      az network list-usages -l <azure-region> -o jsonc

      Magazyn (konto magazynu)

      az storage account show-usage

  • Limity ograniczania przepływności interfejsu API usługi Azure Resource Manager — jeśli masz wystarczająco duże środowisko (np. > 400 maszyn wirtualnych w sieci wirtualnej), możesz osiągnąć domyślne limity ograniczania przepustowości interfejsu API dla zapisów (obecnie 1200 zapisów/godzinę) w usłudze Azure Resource Manager. Przed rozpoczęciem migracji należy zgłosić bilet pomocy technicznej, aby zwiększyć ten limit dla subskrypcji.

  • Stan maszyny wirtualnej przekroczenia limitu czasu aprowizacji — jeśli którakolwiek maszyna wirtualna ma przekroczony limit czasu aprowizacji, należy rozwiązać ten problem przed migracją. Jedynym sposobem, aby to zrobić, jest przestój przez anulowanie aprowizacji/ponowne aprowizowanie maszyny wirtualnej (usuń ją, zachowaj dysk i utwórz ponownie maszynę wirtualną).

  • Stan maszyny wirtualnej RoleStateUnknown — jeśli migracja zostanie zatrzymana z powodu nieznanego komunikatu o błędzie stanu roli, sprawdź maszynę wirtualną przy użyciu portalu i upewnij się, że jest uruchomiona. Ten błąd zwykle zniknie samodzielnie (nie jest wymagane korygowanie) po kilku minutach i często występuje przejściowy typ często występujący podczas uruchamiania, zatrzymywania i ponownego uruchamiania maszyny wirtualnej. Zalecane rozwiązanie: spróbuj ponownie przeprowadzić migrację po kilku minutach.

  • Klaster sieci szkieletowej nie istnieje — w niektórych przypadkach niektóre maszyny wirtualne nie mogą być migrowane z różnych powodów dziwnych. Jednym z tych znanych przypadków jest to, że maszyna wirtualna została niedawno utworzona (w ciągu ostatniego tygodnia lub tak) i miała miejsce lądowanie klastra platformy Azure, który nie jest jeszcze wyposażony w obciążenia usługi Azure Resource Manager. Zostanie wyświetlony błąd informujący, że klaster sieci szkieletowej nie istnieje i nie można zmigrować maszyny wirtualnej. Oczekiwanie na kilka dni zwykle rozwiąże ten konkretny problem, ponieważ klaster wkrótce uzyska włączoną usługę Azure Resource Manager. Jednak jednym bezpośrednim obejściem jest przejście do stop-deallocate maszyny wirtualnej, a następnie kontynuowanie migracji i uruchamianie kopii zapasowej maszyny wirtualnej w usłudze Azure Resource Manager po przeprowadzeniu migracji.

Pułapki, aby uniknąć

  • Nie należy stosować skrótów i pomijać migracje weryfikacji/przygotowywania/przerywania migracji próbnych.
  • Większość, jeśli nie wszystkie, potencjalnych problemów pojawi się podczas kroków weryfikacji/przygotowania/przerwania.

Migracja

Zagadnienia techniczne i kompromisy

Teraz możesz przystąpić do pracy ze znanymi problemami ze środowiskiem.

W przypadku rzeczywistych migracji warto rozważyć następujące kwestie:

  1. Zaplanuj i zaplanuj sieć wirtualną (najmniejszą jednostkę migracji) z rosnącym priorytetem. Najpierw wykonaj proste sieci wirtualne i postępuj z bardziej skomplikowanymi sieciami wirtualnymi.
  2. Większość klientów będzie mieć środowiska nieprodukcyjne i produkcyjne. Zaplanuj ostatnio produkcję.
  3. (OPCJONALNIE) Zaplanuj przestój konserwacji z dużą ilością buforu w przypadku wystąpienia nieoczekiwanych problemów.
  4. Komunikowanie się z zespołami pomocy technicznej i ich dopasowanie w przypadku wystąpienia problemów.

Wzorce sukcesu

Wskazówki techniczne z powyższej sekcji Laboratorium Test powinny być brane pod uwagę i ograniczane przed rzeczywistą migracją. W przypadku odpowiedniego testowania migracja jest w rzeczywistości niezdarnym zdarzeniem. W przypadku środowisk produkcyjnych warto mieć dodatkową pomoc techniczną, taką jak zaufany partner firmy Microsoft lub usługi Microsoft Premier.

Pułapki, aby uniknąć

Nie w pełni testowanie może powodować problemy i opóźniać migrację.

Poza migracją

Zagadnienia techniczne i kompromisy

Teraz, gdy jesteś w usłudze Azure Resource Manager, zmaksymalizuj platformę. Zapoznaj się z omówieniem usługi Azure Resource Manager , aby dowiedzieć się więcej o dodatkowych korzyściach.

Kwestie do rozważenia:

  • Łączenie migracji z innymi działaniami. Większość klientów decyduje się na okno obsługi aplikacji. Jeśli tak, możesz użyć tego przestoju, aby włączyć inne funkcje usługi Azure Resource Manager, takie jak szyfrowanie i migracja do Dyski zarządzane.
  • Ponownie zobacz przyczyny techniczne i biznesowe dla usługi Azure Resource Manager; włącz dodatkowe usługi dostępne tylko w usłudze Azure Resource Manager, która ma zastosowanie do danego środowiska.
  • Modernizuj środowisko za pomocą usług PaaS.

Wzorce sukcesu

Celowe określenie usług, które chcesz teraz włączyć w usłudze Azure Resource Manager. Wielu klientów znajduje poniższe atrakcyjne dla swoich środowisk platformy Azure:

Pułapki, aby uniknąć

Pamiętaj, dlaczego rozpoczęto tę klasyczną podróż po migracji do usługi Azure Resource Manager. Jakie były pierwotne powody biznesowe? Czy udało Ci się osiągnąć przyczynę biznesową?

Następne kroki