Udostępnij za pośrednictwem

Rozbudowana technicznie migracja z obsługą platformy od modelu klasycznego do modelu opartego na usłudze 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.

Przyjrzyjmy się szczegółowo migracji z klasycznego modelu wdrażania platformy Azure do modelu wdrażania usługi Azure Resource Manager. Przyjrzymy się zasobom na poziomie zasobów i funkcji, aby ułatwić zrozumienie, w jaki sposób platforma Azure migruje zasoby między dwoma modelami wdrażania. Aby uzyskać więcej informacji, przeczytaj artykuł z ogłoszeniem usługi: Migracja zasobów IaaS obsługiwanych przez platformę z wersji klasycznej do usługi Azure Resource Manager.

Migrowanie zasobów IaaS z klasycznego modelu wdrażania do usługi Azure Resource Manager

Najpierw należy zrozumieć różnicę między operacjami płaszczyzny danych i płaszczyzny zarządzania w zasobach infrastruktury jako usługi (IaaS).

  • Płaszczyzna zarządzania/sterowania opisuje wywołania wchodzące w płaszczyznę zarządzania/sterowania lub interfejs API do modyfikowania zasobów. Operacje, na przykład takie jak utworzenie maszyny wirtualnej, ponowne uruchomienie maszyny wirtualnej i zaktualizowanie maszyny wirtualnej przy użyciu nowej podsieci, powodują wykonanie działań zarządzania uruchomionymi zasobami. Nie mają bezpośredniego wpływu na nawiązywanie połączenia z maszynami wirtualnymi.
  • Płaszczyzna danych (aplikacja) opisuje środowisko uruchomieniowe samej aplikacji i obejmuje interakcję z wystąpieniami, które nie przechodzą przez interfejs API platformy Azure. Na przykład uzyskiwanie dostępu do witryny internetowej lub ściąganie danych z uruchomionego wystąpienia programu SQL Server lub serwera MongoDB są interakcjami płaszczyzny danych lub aplikacji. Inne przykłady obejmują kopiowanie obiektu blob z konta magazynu i uzyskiwanie dostępu do publicznego adresu IP w celu korzystania z protokołu RDP (Remote Desktop Protocol) lub Secure Shell (SSH) na maszynie wirtualnej. Te operacje utrzymują działanie aplikacji w ramach usług obliczeniowych, sieciowych i magazynowych.

Płaszczyzna danych jest taka sama między klasycznym modelem wdrażania a stosami usługi Resource Manager. Różnica polega na tym, że podczas procesu migracji firma Microsoft tłumaczy reprezentację zasobów z klasycznego modelu wdrażania na to w stosie usługi Resource Manager. W związku z tym należy używać nowych narzędzi, interfejsów API i zestawów SDK do zarządzania zasobami w stosie usługi Resource Manager.

Diagram przedstawiający różnicę między płaszczyzną zarządzania/płaszczyzną sterowania a płaszczyzną danych

Uwaga

W przypadku niektórych scenariuszy migracji platforma Azure zatrzymuje maszyny wirtualne, cofa ich przydział i uruchamia je ponownie. Powoduje to krótki przestój płaszczyzny danych.

Środowisko migracji

Przed rozpoczęciem migracji:

  • Upewnij się, że zasoby do zmigrowania nie używają żadnych nieobsługiwanych funkcji ani konfiguracji. Zazwyczaj platforma wykrywa te problemy i zgłasza błąd.
  • Jeśli masz maszyny wirtualne, które nie znajdują się w sieci wirtualnej, zostaną zatrzymane i cofnięto przydział w ramach operacji przygotowywania. Jeśli nie chcesz utracić publicznego adresu IP, rozważ zarezerwowanie adresu IP przed wyzwoleniem operacji przygotowywania. Jeśli maszyny wirtualne znajdują się w sieci wirtualnej, nie są one zatrzymywane i cofane przydziału.
  • Zaplanuj przeprowadzenie migracji poza godzinami pracy, aby uwzględnić możliwość wystąpienia nieoczekiwanych awarii podczas migracji.
  • Pobierz bieżącą konfigurację maszyn wirtualnych przy użyciu programu PowerShell, poleceń interfejsu wiersza polecenia (CLI) lub interfejsów API REST, aby ułatwić walidację po zakończeniu kroku przygotowania.
  • Przed rozpoczęciem migracji zaktualizuj skrypty automatyzacji i operacjonalizacji w celu obsługi modelu wdrażania usługi Resource Manager. Opcjonalnie możesz wykonać operacje GET, gdy zasoby są w stanie przygotowania.
  • Oceń zasady kontroli dostępu opartej na rolach (RBAC) platformy Azure, które są skonfigurowane na zasobach IaaS w klasycznym modelu wdrażania, i zaplanuj je po zakończeniu migracji.

Przepływ pracy migracji wygląda następująco:

Diagram przedstawiający przepływ pracy migracji

Uwaga

Wszystkie operacje opisane w poniższych sekcjach są idempotentne. Jeśli masz problem inny niż nieobsługiwana funkcja lub błąd konfiguracji, spróbuj ponownie wykonać operację przygotowywania, przerwania lub zatwierdzenia. Platforma Azure ponownie podejmie próbę wykonania akcji.

Sprawdź poprawność

Operacja walidacji to pierwszy krok w procesie migracji. Celem tego kroku jest przeanalizowanie stanu zasobów, które mają zostać zmigrowane w klasycznym modelu wdrażania. Operacja ocenia, czy zasoby są w stanie przeprowadzić migrację (powodzenie lub niepowodzenie).

Należy wybrać sieć wirtualną lub usługę w chmurze (jeśli nie znajduje się ona w sieci wirtualnej), którą chcesz zweryfikować pod kątem migracji. Jeśli zasób nie jest w stanie migracji, platforma Azure zawiera listę przyczyn.

Sprawdzanie nie zostało wykonane w operacji weryfikacji

Operacja sprawdzania poprawności analizuje tylko stan zasobów w klasycznym modelu wdrażania. Może sprawdzić wszystkie błędy i nieobsługiwane scenariusze z powodu różnych konfiguracji w klasycznym modelu wdrażania. Nie można sprawdzić wszystkich problemów, które stos usługi Azure Resource Manager może nakładać na zasoby podczas migracji. Te problemy są sprawdzane tylko wtedy, gdy zasoby przechodzą transformację w następnym kroku migracji (operacja przygotowywania). W poniższej tabeli wymieniono wszystkie problemy, które nie zostały zaewidencjonowane w operacji weryfikacji:

Sprawdzanie sieci nie jest wykonywane w operacji sprawdzania poprawności
Sieć wirtualna z bramami ER i VPN.
Połączenie bramy sieci wirtualnej w stanie rozłączenia.
Wszystkie obwody ER są wstępnie migrowane do stosu usługi Azure Resource Manager.
Sprawdzanie limitu przydziału usługi Azure Resource Manager pod kątem zasobów sieciowych. Na przykład: statyczny publiczny adres IP, dynamiczne publiczne adresy IP, moduł równoważenia obciążenia, sieciowe grupy zabezpieczeń, tabele tras i interfejsy sieciowe.
Wszystkie reguły modułu równoważenia obciążenia są prawidłowe we wdrożeniu i w sieci wirtualnej.
Konflikt prywatnych adresów IP między maszynami wirtualnymi, które mają cofnięty przydział zatrzymany w tej samej sieci wirtualnej.

Przygotowywanie

Operacja przygotowania to drugi krok w procesie migracji. Celem tego kroku jest symulowanie transformacji zasobów IaaS z klasycznego modelu wdrażania do zasobów usługi Resource Manager. Ponadto operacja przygotowywania przedstawia tę operację obok siebie w celu wizualizacji.

Uwaga

Zasoby w klasycznym modelu wdrażania nie są modyfikowane w tym kroku. Jest to bezpieczny krok do uruchomienia, jeśli próbujesz przeprowadzić migrację.

Wybierz sieć wirtualną lub usługę w chmurze (jeśli nie jest to sieć wirtualna), którą chcesz przygotować do migracji.

  • Jeśli zasób nie jest w stanie przeprowadzić migracji, platforma Azure zatrzymuje proces migracji i wyświetla przyczynę niepowodzenia operacji przygotowywania.
  • Jeśli zasób jest w stanie migracji, platforma Azure blokuje operacje płaszczyzny zarządzania dla zasobów w ramach migracji. Na przykład nie będzie można dodać dysku danych do migrowanej maszyny wirtualnej.

Następnie platforma Azure uruchamia migrację metadanych z klasycznego modelu wdrażania do usługi Resource Manager na potrzeby migrowania zasobów.

Po zakończeniu operacji przygotowywania można wizualizować zasoby zarówno w klasycznym modelu wdrażania, jak i w usłudze Resource Manager. Dla każdej usługi w chmurze w klasycznym modelu wdrażania platforma Azure tworzy nazwę grupy zasobów zgodnie ze wzorcem cloud-service-name>-Migrated.

Uwaga

Nie można wybrać nazwy grupy zasobów utworzonej dla zmigrowanych zasobów (czyli "-Migrated"). Po zakończeniu migracji można jednak użyć funkcji przenoszenia usługi Azure Resource Manager, aby przenieść zasoby do dowolnej grupy zasobów. Aby uzyskać więcej informacji, zobacz Move resources to new resource group or subscription (Przenoszenie zasobów do nowej grupy lub subskrypcji).

Na poniższych dwóch zrzutach ekranu przedstawiono wynik po pomyślnej operacji przygotowania. Pierwszy z nich przedstawia grupę zasobów zawierającą oryginalną usługę w chmurze. Drugi zawiera nową grupę zasobów "-Migrated", która zawiera równoważne zasoby usługi Azure Resource Manager.

Zrzut ekranu przedstawiający oryginalną usługę w chmurze

Zrzut ekranu przedstawiający zasoby usługi Azure Resource Manager w operacji przygotowywania

Oto zakulisowe spojrzenie na zasoby po zakończeniu fazy przygotowywania. Należy pamiętać, że zasób na płaszczyźnie danych jest taki sam. Jest on reprezentowany zarówno na płaszczyźnie zarządzania (klasycznym modelu wdrażania), jak i w płaszczyźnie sterowania (Resource Manager).

Diagram fazy przygotowywania

Uwaga

Maszyny wirtualne, które nie znajdują się w sieci wirtualnej w klasycznym modelu wdrażania, są zatrzymywane i cofane przydziału w tej fazie migracji.

Sprawdzenie (ręczne lub za pomocą skryptu)

W kroku sprawdzania masz możliwość użycia pobranej wcześniej konfiguracji w celu sprawdzenia, czy migracja wygląda poprawnie. Alternatywnie możesz zalogować się do portalu i sprawdzić właściwości i zasoby, aby sprawdzić, czy migracja metadanych wygląda dobrze.

Jeśli migrujesz sieć wirtualną, większość konfiguracji maszyn wirtualnych nie zostanie uruchomiona ponownie. W przypadku aplikacji na tych maszynach wirtualnych możesz sprawdzić, czy aplikacja jest nadal uruchomiona.

Możesz przetestować skrypty monitorowania i operacyjne, aby sprawdzić, czy maszyny wirtualne działają zgodnie z oczekiwaniami, a zaktualizowane skrypty działają prawidłowo. Tylko operacje GET są obsługiwane, jeśli zasoby są w stanie przygotowania.

Nie ma ustawionego przedziału czasu, przed którym należy zatwierdzić migrację. Ten stan może trwać tak długo, jak chcesz. Jednak płaszczyzna zarządzania jest zablokowana dla tych zasobów do momentu przerwania lub zatwierdzenia.

Jeśli napotkasz jakiekolwiek problemy, zawsze możesz przerwać migrację i wrócić do klasycznego modelu wdrażania. Po powrocie platforma Azure otwiera operacje płaszczyzny zarządzania na zasobach, dzięki czemu można wznowić normalne operacje na tych maszynach wirtualnych w klasycznym modelu wdrażania.

Przerwij

Jest to opcjonalny krok, jeśli chcesz przywrócić zmiany klasycznego modelu wdrażania i zatrzymać migrację. Ta operacja usuwa metadane usługi Resource Manager (utworzone w kroku przygotowywania) dla zasobów.

Diagram kroku przerwania

Uwaga

Nie można wykonać tej operacji po wyzwoleniu operacji zatwierdzania.

Zatwierdzenie

Po zakończeniu walidacji możesz zatwierdzić migrację. Zasoby nie są już wyświetlane w klasycznym modelu wdrażania i są dostępne tylko w modelu wdrażania usługi Resource Manager. Zmigrowanymi zasobami można zarządzać tylko w nowym portalu.

Uwaga

Jest to operacja idempotentna. Jeśli operacja zakończy się niepowodzeniem, spróbuj ponownie wykonać operację. Jeśli nadal nie powiedzie się, utwórz bilet pomocy technicznej lub utwórz forum w witrynie Microsoft Q&A

Diagram kroku zatwierdzania

Schemat blokowy migracji

Oto schemat blokowy pokazujący, jak kontynuować migrację:

Zrzut ekranu przedstawiający kroki migracji

Tłumaczenie klasycznego modelu wdrażania na zasoby usługi Resource Manager

W poniższej tabeli można znaleźć klasyczny model wdrażania i reprezentacje usługi Resource Manager zasobów. Inne funkcje i zasoby nie są obecnie obsługiwane.

Reprezentacja klasyczna Reprezentacja usługi Resource Manager Uwagi
Nazwa usługi w chmurze (nazwa usługi hostowanej) Nazwa DNS Podczas migracji jest tworzona nowa grupa zasobów dla każdej usługi w chmurze przy użyciu wzorca nazewnictwa <cloudservicename>-migrated. Ta grupa zasobów zawiera wszystkie zasoby. Nazwa usługi w chmurze stanie się nazwą DNS skojarzoną z publicznym adresem IP.
Maszyna wirtualna Maszyna wirtualna Właściwości specyficzne dla maszyny wirtualnej są migrowane bez zmian. Niektóre informacje osProfile, takie jak nazwa komputera, nie są przechowywane w klasycznym modelu wdrażania i pozostają puste po migracji.
Zasoby dysków dołączonych do maszyny wirtualnej Niejawne dyski dołączone do maszyny wirtualnej Dyski nie są modelowane jako zasoby najwyższego poziomu w modelu wdrażania usługi Resource Manager. Są one migrowane jako dyski niejawne w ramach maszyny wirtualnej. Tylko dyski dołączone do maszyny wirtualnej są obecnie obsługiwane. Maszyny wirtualne usługi Resource Manager mogą teraz używać kont magazynu w klasycznym modelu wdrażania, co umożliwia łatwe migrowanie dysków bez żadnych aktualizacji.
Rozszerzenia maszyn wirtualnych Rozszerzenia maszyn wirtualnych Wszystkie rozszerzenia zasobów, z wyjątkiem rozszerzeń XML, są migrowane z klasycznego modelu wdrażania.
Certyfikaty maszyny wirtualnej Certyfikaty w usłudze Azure Key Vault Jeśli usługa w chmurze zawiera certyfikaty usług, migracja tworzy nowy magazyn kluczy platformy Azure na usługę w chmurze i przenosi certyfikaty do magazynu kluczy. Maszyny wirtualne są aktualizowane, tak aby przywoływały certyfikaty z magazynu kluczy.

Nie usuwaj magazynu kluczy. Może to spowodować przejście maszyny wirtualnej do stanu niepowodzenia.
Konfiguracja usługi WinRM Konfiguracja usługi WinRM w ramach elementu osProfile Konfiguracja usługi Windows Remote Management jest przenoszona bez zmian w ramach migracji.
Właściwość Availability-set Zasób Availability-set Specyfikacja zestawu dostępności to właściwość maszyny wirtualnej w klasycznym modelu wdrażania. Zestawy dostępności stają się zasobami najwyższego poziomu w ramach migracji. Następujące konfiguracje nie są obsługiwane: wiele zestawów dostępności dla usługi w chmurze, co najmniej jeden zestaw dostępności razem z maszyną wirtualną poza zestawem dostępności w ramach usługi w chmurze.
Konfiguracja sieci na maszynie wirtualnej Podstawowy interfejs sieciowy Konfiguracja sieci na maszynie wirtualnej jest reprezentowana jako zasób podstawowego interfejsu sieciowego po migracji. W przypadku maszyn wirtualnych poza siecią wirtualną wewnętrzny adres IP zmieni się podczas migracji.
Wiele interfejsów sieciowych na maszynie wirtualnej Interfejsy sieciowe Jeśli maszyna wirtualna ma wiele skojarzonych interfejsów sieciowych, każdy interfejs sieciowy staje się zasobem najwyższego poziomu w ramach migracji wraz ze wszystkimi właściwościami.
Zestaw punktów końcowych z równoważeniem obciążenia Moduł równoważenia obciążenia W klasycznym modelu wdrażania do platformy jest przypisany niejawny moduł równoważenia obciążenia dla każdej usługi w chmurze. Podczas migracji jest tworzony nowy zasób modułu równoważenia obciążenia, a zestaw punktów końcowych równoważenia obciążenia staje się regułami modułu równoważenia obciążenia.
Reguły NAT dla ruchu przychodzącego Reguły NAT dla ruchu przychodzącego Wejściowe punkty końcowe zdefiniowane na maszynie wirtualnej są konwertowane na reguły translacji dla adresu sieciowego ruchu przychodzącego w module równoważenia obciążenia podczas migracji.
Adres VIP Publiczny adres IP z nazwą DNS Wirtualny adres IP staje się publicznym adresem IP i jest skojarzony z modułem równoważenia obciążenia. Wirtualny adres IP można zmigrować tylko pod warunkiem, że ma przypisany wejściowy punkt końcowy. Aby zachować adres IP, możesz przekonwertować go na zastrzeżony adres IP przed migracją. W trakcie tej zmiany nastąpi przestój w ciągu około 60 sekund.
Sieć wirtualna Sieć wirtualna Sieć wirtualna jest migrowana razem ze wszystkimi właściwościami do modelu wdrażania usługi Resource Manager. Nowa grupa zasobów jest tworzona za pomocą sufiksu -migrated.
Zastrzeżone adresy IP Publiczny adres IP z przydziałem statycznym Zastrzeżone adresy IP skojarzone z modułem równoważenia obciążenia są migrowane w ramach migrowania usługi w chmurze lub maszyny wirtualnej. Niezwiązane zastrzeżone adresy IP można migrować przy użyciu polecenia Move-AzureReservedIP.
Publiczny adres IP dla maszyny wirtualnej Publiczny adres IP z przydziałem dynamicznym Publiczny adres IP skojarzony z maszyną wirtualną jest konwertowany jako zasób publicznego adresu IP z metodą alokacji ustawioną na dynamiczną.
Sieciowe grupy zabezpieczeń. Sieciowe grupy zabezpieczeń. Sieciowe grupy zabezpieczeń skojarzone z maszyną wirtualną lub podsiecią są klonowane w ramach migracji do modelu wdrażania usługi Resource Manager. Sieciowa grupa zabezpieczeń w klasycznym modelu wdrażania nie jest usuwana podczas migracji. Jednak operacje płaszczyzny zarządzania dla sieciowej grupy zabezpieczeń są zablokowane, gdy trwa migracja. Niezwiązane sieciowe grupy zabezpieczeń można migrować przy użyciu polecenia Move-AzureNetworkSecurityGroup.
Serwery DNS Serwery DNS Serwery DNS skojarzone z siecią wirtualną lub maszyną wirtualną są migrowane w ramach migracji odpowiadających zasobów razem ze wszystkimi właściwościami.
Trasy zdefiniowane przez użytkownika Trasy zdefiniowane przez użytkownika Trasy zdefiniowane przez użytkownika skojarzone z podsiecią są klonowane w ramach migracji do modelu wdrażania usługi Resource Manager. Trasy zdefiniowane przez użytkownika w klasycznym modelu wdrażania nie są usuwane podczas migracji. Operacje płaszczyzny zarządzania dla tras zdefiniowanych przez użytkownika są zablokowane, gdy trwa migracja. Niezwiązane trasy zdefiniowane przez użytkownika można migrować przy użyciu polecenia Move-AzureRouteTable.
Właściwość przekazywania adresu IP w konfiguracji sieci maszyny wirtualnej Właściwość przekazywania adresu IP dla karty sieciowej Właściwość przekazywania adresu IP na maszynie wirtualnej jest konwertowana na właściwość interfejsu sieciowego podczas migracji.
Moduł równoważenia obciążenia z wieloma adresami IP Moduł równoważenia obciążenia z wieloma zasobami publicznego adresu IP Każdy publiczny adres IP skojarzony z modułem równoważenia obciążenia jest konwertowany na zasób publicznego adresu IP i skojarzony z modułem równoważenia obciążenia po migracji.
Wewnętrzne nazwy DNS na maszynie wirtualnej Wewnętrzne nazwy DNS na karcie sieciowej Podczas migracji wewnętrzne sufiksy DNS dla maszyn wirtualnych są migrowane do właściwości tylko do odczytu o nazwie „InternalDomainNameSuffix” na karcie sieciowej. Sufiks pozostaje niezmieniony po migracji, a rozpoznawanie maszyn wirtualnych powinno nadal działać tak jak poprzednio.
Brama sieci wirtualnej Brama sieci wirtualnej Właściwości bramy sieci wirtualnej są migrowane bez zmian. Adres VIP skojarzony z bramą także nie jest zmieniany.
Lokacja sieci lokalnej Brama sieci lokalnej Właściwości lokacji sieci lokalnej są migrowane bez zmian do nowego zasobu nazywanego bramą sieci lokalnej. Reprezentuje to lokalne prefiksy adresów i adres IP bramy zdalnej.
Odwołania połączeń Connection Odwołania do łączności między bramą a lokacją sieci lokalnej w konfiguracji sieci są reprezentowane przez nowy zasób o nazwie Połączenie. Wszystkie właściwości odwołania do łączności w plikach konfiguracji sieci są kopiowane bez zmian do zasobu Połączenie. Łączność między sieciami wirtualnymi w klasycznym modelu wdrażania jest osiągana przez utworzenie dwóch tuneli IPsec w lokacjach sieci lokalnych reprezentujących sieci wirtualne. Jest to przekształcane w typ połączenia sieć wirtualna-sieć wirtualna w modelu usługi Resource Manager bez konieczności używania bram sieci lokalnej.

Zmiany automatyzacji i narzędzi po migracji

W ramach migracji zasobów z klasycznego modelu wdrażania do modelu wdrażania przy użyciu usługi Resource Manager należy zaktualizować istniejącą automatyzację lub narzędzia, aby upewnić się, że będzie ona nadal działać po migracji.

Następne kroki