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 przestarzałe i zostaną w pełni wycofane 6 września 2023 r. Dowiedz się więcej o tym wycofaniu i o tym, jak wpływa na Ciebie.

Chociaż usługa Azure Resource Manager oferuje wiele niesamowitych funkcji, niezwykle ważne jest zaplanowanie podróży migracji, aby upewnić się, że wszystko działa bezproblemowo. Poświęcanie czasu na planowanie gwarantuje, że podczas wykonywania działań migracji nie występują problemy.

Uwaga

Poniższe wskazówki zostały w dużym stopniu przyczyniły się do współpracy z zespołem doradczym klienta platformy Azure i architektami rozwiązań w chmurze pracującymi z klientami w zakresie migrowania dużych środowisk. W związku z tym ten 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 migracji?
  2. Jakie są przyczyny techniczne usługi Azure Resource Manager? Co (jeśli istnieje) 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 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) platforma Azure Resource Manager zmienić wdrożenie maszyny wirtualnej, zarządzanie, monitorowanie i procesy 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, czy powinien istnieć okres konserwacji, w którym aplikacja jest niedostępna dla użytkowników końcowych i właścicieli aplikacji? Jeśli tak, na jak długo?
  9. Jaki jest plan szkolenia, 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 Resource Manager platformy Azure i innych powiązanych map technologicznych? Czy są one optymalnie wyrównane?

Wzorce sukcesu

Pomyślni klienci mają szczegółowe plany, w których omawiane są powyższe pytania, udokumentowane i zarządzane. Upewnij się, że plany migracji są szeroko przekazywane sponsorom i uczestnikom projektu. Zaobraj się w wiedzę na temat opcji migracji; zapoznanie się z poniższym zestawem dokumentów migracji jest zdecydowanie zalecane.

Pułapki, aby uniknąć

  • Nie można zaplanować. Kroki technologiczne tej migracji są sprawdzone, 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ącą ilość buforu, aby odpowiednio ostrzegać użytkowników końcowych o potencjalnie niedostępnym czasie aplikacji.

Test laboratoryjny

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 poniższym zaleceniem Weryfikowanie/przygotowywanie/przerywanie przebiegu suchego.

Przeprowadzenie testu laboratoryjnego dokładnego scenariusza (obliczenia, sieć i magazyn) jest najlepszym sposobem zapewnienia bezproblemowej migracji. Pomoże to zapewnić:

  • Całkowicie oddzielne laboratorium lub istniejące środowisko nieprodukcyjne do testowania. Zalecamy zupełnie oddzielne laboratorium, które można wielokrotnie migrować i można je destrukcyjnie modyfikować. Poniżej wymieniono skrypty zbierania/nawodnienia 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 osiągnąć za pomocą narzędzia AsmMetadataParser. Dowiedz się więcej o tym narzędziu tutaj

Wzorce sukcesu

Poniżej przedstawiono problemy wykryte w wielu większych migracjach. Nie jest to wyczerpująca lista i należy zapoznać się z nieobsługiwaną funkcją i konfiguracjami , aby uzyskać więcej szczegółów. Te problemy techniczne mogą wystąpić lub nie mogą wystąpić, ale jeśli rozwiążesz te problemy przed podjęciem próby migracji, zapewni to bezproblemowe środowisko.

  • Wykonaj weryfikację/przygotowanie/przerwanie przebiegu suchego — jest to prawdopodobnie 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. Następnym krokiem procesu migracji przygotowanie pomoże ujawnić te problemy. Przygotowanie spowoduje przeniesienie metadanych z klasycznej 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) i sprawdzenie, czy wszystko migruje poprawnie i działa 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 niedysponacyjne.

    • Poniższe elementy będą musiały zostać rozwiązane przed uruchomieniem suchym, ale test przebiegu suchego również bezpiecznie opróżni te kroki przygotowania, jeśli zostaną pominięte. Podczas migracji przedsiębiorstwa odkryliśmy, że suchy przebieg jest bezpieczny i bezcenny w celu 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 weryfikacji/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 bramy usługi Express Route z linkami autoryzacji nie można migrować bez przestojów. Aby obejść ten problem, zobacz Migrowanie obwodów usługi ExpressRoute i skojarzonych sieci wirtualnych z modelu klasycznego do modelu wdrażania Resource Manager.

  • Rozszerzenia maszyn wirtualnych — rozszerzenia maszyny wirtualnej są potencjalnie jednym z największych przeszkód w migracji działających 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 jest wymagany działający agent platformy Azure. Jeśli stan zostanie przywrócony jako 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 agent roboczy, 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ć ponownie do maszyny wirtualnej po migracji usługi Azure Resource Manager. Dotyczy to tylko uruchomionych maszyn wirtualnych. Jeśli przydział maszyn wirtualnych zostanie zatrzymany, rozszerzenia maszyn wirtualnych nie muszą zostać usunięte. Uwaga: Wiele rozszerzeń, takich jak diagnostyka platformy Azure i monitorowanie usługi Defender for Cloud, zainstaluje się ponownie 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 platformy Azure Resource Manager jest wymagany wychodzący dostęp do Internetu (i DNS).

    • Istnieją dwie wersje rozszerzenia BGInfo: v1 i v2. Jeśli maszyna wirtualna została utworzona przy użyciu Azure Portal lub programu PowerShell, maszyna wirtualna prawdopodobnie będzie mieć na nim rozszerzenie v1. 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 przy użyciu nowego Azure Portal, prawdopodobnie będzie miała wersję BGInfo opartą na formacie JSON w wersji 2, która może zostać zmigrowana do platformy 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 pracujących agentów platformy Azure na maszynach wirtualnych, odinstaluj wszystkie rozszerzenia maszyn wirtualnych w ramach migracji przed przygotowaniem, a następnie zainstaluj ponownie 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 wirtualne adresy IP 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 zainstalowane na maszynie wirtualnej po jego usunięciu.

  • Zestawy dostępności — aby zmigrować sieć wirtualną do usługi Azure Resource Manager, wdrożenie klasyczne (tj. usługa w chmurze) musi 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 w zestawie dostępności nie może być niektórych maszyn wirtualnych, 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 — Cloud Services 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 pierwszym przypadku ponownego wdrożenia 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 Virtual Network 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, takim 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 bez opóźnień/kar za przepustowość. Biorąc pod uwagę dodanie komunikacji równorzędnej Virtual Network, wdrożenia ról internetowych/procesów roboczych można teraz łatwo ograniczyć i nie blokować migracji do usługi Azure Resource Manager.

  • Limity przydziału usługi Azure Resource Manager — regiony platformy Azure mają oddzielne limity przydziału/limity zarówno dla wersji klasycznej, jak i platformy Azure Resource Manager. Mimo że w scenariuszu migracji nowy sprzęt nie jest używany (zamieniamy istniejące maszyny wirtualne z klasycznej na platformę Azure Resource Manager), przydziały platformy 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 przydziału, aby podnieść limity.

    Uwaga

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

    • Interfejsy sieciowe

    • Moduły 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

      Network(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

      Storage(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ślny limit ograniczania przepływnoś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 upłynął limit czasu aprowizacji maszyny wirtualnej — jeśli jakakolwiek maszyna wirtualna ma upłynął limit czasu aprowizacji, należy rozwiązać ten problem przed migracją. Jedynym sposobem, aby to zrobić, jest przerwanie aprowizacji/ponowne aprowizowanie maszyny wirtualnej (usunięcie go, zatrzymanie dysku i ponowne utworzenie maszyny wirtualnej).

  • 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 zazwyczaj zniknie samodzielnie (nie jest wymagane korygowanie) po kilku minutach i jest często przejściowym typem często występującym podczas uruchamiania, zatrzymywania, 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. Jednym z tych znanych przypadków jest to, że maszyna wirtualna została niedawno utworzona (w ciągu ostatniego tygodnia lub tak) i została umieszczona w klastrze 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 przeprowadzić migracji maszyny wirtualnej. Oczekiwanie na kilka dni zwykle rozwiąże ten konkretny problem, ponieważ klaster wkrótce otrzyma włączoną usługę Azure Resource Manager. Jednak jednym z natychmiastowych obejść jest stop-deallocate maszyna wirtualna, a następnie kontynuuj migrację i uruchom kopię zapasową maszyny wirtualnej w usłudze Azure Resource Manager po migracji.

Pułapki, aby uniknąć

  • Nie należy robić skrótów i pomijać migracje weryfikacji/przygotowywania/przerywania migracji przebiegu suchego.
  • Większość, jeśli nie wszystkie, potencjalne problemy pojawią się podczas kroków weryfikacji/przygotowania/przerwania.

Migracja

Zagadnienia techniczne i kompromisy

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

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 produkcję ostatnio.
  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 dostosowywanie ich w przypadku wystąpienia problemów.

Wzorce sukcesu

Wskazówki techniczne z powyższej sekcji Test laboratoryjny 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 spowodować problemy i opóźnienie migracji.

Poza migracją

Zagadnienia techniczne i kompromisy

Teraz, gdy korzystasz z usługi 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.
  • Zobacz ponownie 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óre mają zastosowanie do danego środowiska.
  • Modernizuj środowisko za pomocą usług PaaS.

Wzorce sukcesu

Celowe korzystanie z 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ą migrację do usługi Azure Resource Manager. Jakie były oryginalne powody biznesowe? Czy udało Ci się osiągnąć przyczynę biznesową?

Następne kroki