Technische details over door platforms ondersteunde migratie van klassiek naar Azure Resource Manager

  • Artikel

Van toepassing op: ✔️ Virtuele Linux-machines ✔️ van Windows

Belangrijk

Tegenwoordig gebruiken ongeveer 90% van de IaaS-VM's Azure Resource Manager. Vanaf 28 februari 2020 zijn klassieke VM's afgeschaft en worden deze volledig buiten gebruik gesteld op 6 september 2023. Meer informatie over deze afschaffing en hoe dit van invloed is op u.

Laten we dieper ingaan op het migreren van het klassieke Azure-implementatiemodel naar het Azure Resource Manager-implementatiemodel. We bekijken resources op resource- en functieniveau om inzicht te krijgen in hoe het Azure-platform resources migreert tussen de twee implementatiemodellen. Lees het artikel over de aankondiging van de service voor meer informatie: Platform-ondersteunde migratie van IaaS-resources van klassiek naar Azure Resource Manager.

IaaS-resources migreren van het klassieke implementatiemodel naar Azure Resource Manager

Ten eerste is het belangrijk om inzicht te krijgen in het verschil tussen gegevensvlak- en beheervlakbewerkingen op de IaaS-resources (Infrastructure as a Service).

  • Het beheer-/besturingsvlak beschrijft de aanroepen die binnenkomen in het beheer-/besturingsvlak of de API voor het wijzigen van resources. Bewerkingen zoals het maken van een VM, opnieuw starten van een VM en het bijwerken van een virtueel netwerk met een nieuw subnet beheren de actieve resources. Ze zijn niet rechtstreeks van invloed op het maken van verbinding met de VM's.
  • Het gegevensvlak (de toepassing) beschrijft de runtime van de toepassing zelf en omvat interactie met exemplaren die niet via de Azure API gaan. Als u bijvoorbeeld toegang wilt krijgen tot uw website of gegevens ophaalt uit een actief SQL Server-exemplaar of een MongoDB-server, zijn gegevensvlak- of toepassingsinteracties. Andere voorbeelden zijn het kopiëren van een blob vanuit een opslagaccount en het openen van een openbaar IP-adres voor het gebruik van Remote Desktop Protocol (RDP) of Secure Shell (SSH) naar de virtuele machine. Deze bewerkingen zorgen ervoor dat de toepassing uitgevoerd blijft worden bij het berekenen, het netwerken en de opslag.

Het gegevensvlak is hetzelfde tussen het klassieke implementatiemodel en Resource Manager-stacks. Het verschil is dat Microsoft tijdens het migratieproces de weergave van de resources vertaalt van het klassieke implementatiemodel naar dat in de Resource Manager-stack. Als gevolg hiervan moet u nieuwe hulpprogramma's, API's en SDK's gebruiken om uw resources in de Resource Manager-stack te beheren.

Diagram that shows the difference between management/control plane and data plane

Notitie

In sommige scenario's voor migratie stopt het Azure-platform, maakt de toewijzingen ongedaan en start uw virtuele machines opnieuw op. Dit veroorzaakt een korte downtime van het gegevensvlak.

De migratie-ervaring

Voordat u de migratie start:

  • Zorg ervoor dat de resources die u wilt migreren geen niet-ondersteunde functies of configuraties gebruiken. Meestal detecteert het platform deze problemen en genereert een fout.
  • Als u vm's hebt die zich niet in een virtueel netwerk bevinden, worden ze gestopt en de toewijzing ervan ongedaan gemaakt als onderdeel van de voorbereidingsbewerking. Als u het openbare IP-adres niet wilt verliezen, kunt u het IP-adres reserveren voordat u de voorbereidingsbewerking activeert. Als de VIRTUELE machines zich in een virtueel netwerk bevinden, worden ze niet gestopt en de toewijzing ervan ongedaan gemaakt.
  • Plan de migratie buiten kantooruren zodat u de tijd hebt om onverwachte fouten die kunnen ontstaan tijdens de migratie op te lossen.
  • Download de huidige configuratie van uw virtuele machines met behulp van PowerShell, CLI-opdrachten (opdrachtregelinterface) of REST API's om de validatie eenvoudiger te maken nadat de voorbereidingsstap is voltooid.
  • Werk uw automatiserings- en operationalisatiescripts bij om het Resource Manager-implementatiemodel te verwerken voordat u de migratie start. Desgewenst kunt u GET-bewerkingen uitvoeren wanneer de resources de status Voorbereid hebben.
  • Evalueer het azure RBAC-beleid (op rollen gebaseerd toegangsbeheer) dat is geconfigureerd op de IaaS-resources in het klassieke implementatiemodel en plan voor nadat de migratie is voltooid.

De migratiewerkstroom is als volgt:

Diagram that shows the migration workflow

Notitie

De bewerkingen die in de volgende secties worden beschreven, zijn allemaal idempotent. Als u een ander probleem hebt dan een niet-ondersteunde functie of een configuratiefout, probeert u de bewerking voorbereiden, afbreken of doorvoeren opnieuw uit te voeren. Azure probeert de actie opnieuw uit te voeren.

Valideren

De bewerking Valideren is de eerste stap in het migratieproces. Het doel van deze stap is het analyseren van de status van de resources die u wilt migreren in het klassieke implementatiemodel. De bewerking evalueert of de resources geschikt zijn voor migratie (geslaagd of mislukt).

U selecteert het virtuele netwerk of een cloudservice (als het zich niet in een virtueel netwerk bevindt) die u wilt valideren voor migratie. Als de resource niet geschikt is voor migratie, geeft Azure de redenen waarom.

Controles worden niet uitgevoerd in de validatiebewerking

De validatiebewerking analyseert alleen de status van de resources in het klassieke implementatiemodel. Het kan controleren op alle fouten en niet-ondersteunde scenario's vanwege verschillende configuraties in het klassieke implementatiemodel. Het is niet mogelijk om te controleren op alle problemen die de Azure Resource Manager-stack tijdens de migratie kan opleggen aan de resources. Deze problemen worden alleen gecontroleerd wanneer de resources transformatie ondergaan in de volgende stap van de migratie (de voorbereidingsbewerking). De volgende tabel bevat alle problemen die niet zijn gecontroleerd in de validatiebewerking:

Netwerkcontroles niet in de validatiebewerking
Een virtueel netwerk met zowel ER- als VPN-gateways.
Een virtuele netwerkgatewayverbinding met een niet-verbonden status.
Alle ER-circuits worden vooraf gemigreerd naar Azure Resource Manager-stack.
Azure Resource Manager-quotumcontroles voor netwerkresources. Bijvoorbeeld: statisch openbaar IP-adres, dynamische openbare IP-adressen, load balancer, netwerkbeveiligingsgroepen, routetabellen en netwerkinterfaces.
Alle load balancer-regels zijn geldig voor implementatie en het virtuele netwerk.
Conflicterende privé-IP-adressen tussen niet-toegewezen VM's stoppen in hetzelfde virtuele netwerk.

Voorbereiden

De bewerking Voorbereiden is de tweede stap in het migratieproces. Het doel van deze stap is het simuleren van de transformatie van de IaaS-resources van het klassieke implementatiemodel naar Resource Manager-resources. Verder presenteert de voorbereidingsbewerking deze side-by-side voor u om te visualiseren.

Notitie

Uw resources in het klassieke implementatiemodel worden tijdens deze stap niet gewijzigd. Het is een veilige stap om uit te voeren als u de migratie probeert uit te voeren.

U selecteert het virtuele netwerk of de cloudservice (als dit geen virtueel netwerk is) dat u wilt voorbereiden op migratie.

  • Als de resource niet geschikt is voor migratie, stopt Azure het migratieproces en wordt de reden vermeld waarom de voorbereidingsbewerking is mislukt.
  • Als de resource geschikt is voor migratie, vergrendelt Azure de beheervlakbewerkingen voor de resources onder migratie. U kunt bijvoorbeeld geen gegevensschijf toevoegen aan een virtuele machine die wordt gemigreerd.

Azure start vervolgens de migratie van metagegevens van het klassieke implementatiemodel naar Resource Manager voor de migratie van resources.

Nadat de voorbereidingsbewerking is voltooid, hebt u de mogelijkheid om de resources te visualiseren in zowel het klassieke implementatiemodel als Resource Manager. Voor elke cloudservice in het klassieke implementatiemodel maakt het Azure-platform een resourcegroepnaam met de indeling cloud-service-name>-Migrated.

Notitie

Het is niet mogelijk om de naam te selecteren van een resourcegroep die is gemaakt voor gemigreerde resources (-Gemigreerd). Nadat de migratie is voltooid, kunt u echter de verplaatsingsfunctie van Azure Resource Manager gebruiken om resources naar elke gewenste resourcegroep te verplaatsen. Zie voor meer informatie Resources verplaatsen naar een nieuwe resourcegroep of een nieuw abonnement.

In de volgende twee schermopnamen ziet u het resultaat na een geslaagde voorbereidingsbewerking. De eerste toont een resourcegroep die de oorspronkelijke cloudservice bevat. De tweede bevat de nieuwe '-Migrated'-resourcegroep die de equivalente Azure Resource Manager-resources bevat.

Screenshot that shows original cloud service

Screenshot that shows Azure Resource Manager resources in the prepare operation

Hier volgt een kijkje achter de schermen bij uw resources na de voltooiing van de voorbereidingsfase. Houd er rekening mee dat de resource in het gegevensvlak hetzelfde is. Deze wordt weergegeven in zowel het beheervlak (klassiek implementatiemodel) als het besturingsvlak (Resource Manager).

Diagram of the prepare phase

Notitie

VM's die zich niet in een virtueel netwerk in het klassieke implementatiemodel bevinden, worden gestopt en de toewijzing ervan ongedaan gemaakt in deze fase van de migratie.

Controleren (handmatig of gepland)

In de controlestap hebt u de mogelijkheid om de configuratie te gebruiken die u eerder hebt gedownload om te controleren of de migratie er juist uitziet. U kunt zich ook aanmelden bij de portal en de eigenschappen en resources controleren om te controleren of de migratie van metagegevens er goed uitziet.

Als u een virtueel netwerk migreert, wordt de configuratie van virtuele machines meestal niet opnieuw opgestart. Voor toepassingen op deze VM's kunt u controleren of de toepassing nog steeds wordt uitgevoerd.

U kunt uw bewakings- en operationele scripts testen om te zien of de VM's werken zoals verwacht en of uw bijgewerkte scripts correct werken. Alleen GET-bewerkingen worden ondersteund wanneer de resources de status Voorbereid hebben.

Er is geen tijdvenster ingesteld waarvoor u de migratie moet doorvoeren. U kunt zoveel tijd nemen als u wilt in deze fase. Het beheervlak is echter wel vergrendeld voor deze resources totdat u de migratie afbreekt of doorvoert.

Als er problemen zijn, kunt u altijd de migratie altijd afbreken en terugkeren naar het klassieke implementatiemodel. Nadat u terug bent, opent Azure de beheervlakbewerkingen op de resources, zodat u de normale bewerkingen op deze VM's in het klassieke implementatiemodel kunt hervatten.

Afbreken

Dit is een optionele stap als u uw wijzigingen wilt terugzetten naar het klassieke implementatiemodel en de migratie wilt stoppen. Met deze bewerking worden de Resource Manager-metagegevens (gemaakt in de voorbereidingsstap) voor uw resources verwijderd.

Diagram of abort step

Notitie

Deze bewerking kan niet worden uitgevoerd nadat u de doorvoerbewerking hebt geactiveerd.

Doorvoeren

Nadat de validatie is voltooid, kunt u de migratie doorvoeren. Resources worden niet meer weergegeven in het klassieke implementatiemodel en zijn alleen beschikbaar in het Resource Manager-implementatiemodel. De gemigreerde resources kunnen alleen in de nieuwe portal worden beheerd.

Notitie

Dit is een idempotente bewerking. Als dit mislukt, voert u de bewerking opnieuw uit. Als deze blijft mislukken, maakt u een ondersteuningsticket of maakt u een forum op Microsoft Q&A

Diagram of commit step

Migratiestroomdiagram

Hier volgt een stroomdiagram waarin wordt getoond hoe u kunt doorgaan met de migratie:

Screenshot that shows the migration steps

Vertaling van het klassieke implementatiemodel naar Resource Manager-resources

U vindt het klassieke implementatiemodel en Resource Manager-weergaven van de resources in de volgende tabel. Andere functies en resources worden momenteel niet ondersteund.

Klassieke weergave Weergave van de Resource Manager Opmerkingen
Naam van cloudservice (gehoste servicenaam) DNS-naam Tijdens de migratie wordt een nieuwe resourcegroep gemaakt voor elke cloudservice met het naamgevingspatroon <cloudservicename>-migrated. Deze resourcegroep bevat al uw resources. De naam van de cloudservice wordt een DNS-naam die is gekoppeld aan het openbare IP-adres.
Virtuele machine Virtuele machine VM-specifieke eigenschappen worden ongewijzigd gemigreerd. Bepaalde osProfile-gegevens, zoals computernaam, worden niet opgeslagen in het klassieke implementatiemodel en blijven leeg na de migratie.
Schijfresources die zijn gekoppeld aan de VM Impliciete schijven die zijn gekoppeld aan de VM Schijven worden niet gemodelleerd als resources op het hoogste niveau in het Resource Manager-implementatiemodel. Ze worden gemigreerd als impliciete schijven onder de virtuele machine. Alleen de schijven die zijn gekoppeld aan een virtuele machine worden momenteel ondersteund. Resource Manager-VM's kunnen nu opslagaccounts gebruiken in het klassieke implementatiemodel, waardoor de schijven eenvoudig kunnen worden gemigreerd zonder updates.
VM-extensies VM-extensies Alle de resource-extensies, met uitzondering van XML-extensies, worden gemigreerd vanuit het klassieke implementatiemodel.
Certificaten van virtuele machine Certificaten in Azure Key Vault Als een cloudservice servicecertificaten bevat, maakt de migratie een nieuwe Azure-sleutelkluis per cloudservice en verplaatst u de certificaten naar de sleutelkluis. De virtuele machines worden bijgewerkt zodat ze verwijzen naar de certificaten van de sleutelkluis.

Verwijder de sleutelkluis niet. Dit kan ertoe leiden dat de VM de status Mislukt instellen.
WinRM-configuratie WinRM-configuratie in osProfile De Windows Remote Management-configuratie wordt ongewijzigd verplaatst als onderdeel van de migratie.
Eigenschap van beschikbaarheidsset Resource van beschikbaarheidsset Specificatie van beschikbaarheidssets is een eigenschap op de virtuele machine in het klassieke implementatiemodel. Beschikbaarheidssets worden een resource op het hoogste niveau als onderdeel van de migratie. De volgende configuraties worden niet ondersteund: meerdere beschikbaarheidssets per cloudservice of één of meer beschikbaarheidssets samen met de virtuele machines die zich niet in een beschikbaarheidsset in een cloudservice bevinden.
Netwerkconfiguratie op een virtuele machine Primaire netwerkinterface De netwerkconfiguratie op een virtuele machine wordt weergegeven als de resource primaire netwerkinterface na de migratie. Het interne IP-adres van virtuele machines die zich niet in een virtueel netwerk bevinden, wordt gewijzigd tijdens de migratie.
Meerdere netwerkinterfaces in een VM Netwerkinterfaces Als aan een virtuele machine meerdere netwerkinterfaces zijn gekoppeld, wordt elke netwerkinterface een resource op het hoogste niveau als onderdeel van de migratie, samen met alle eigenschappen.
Eindpuntset met gelijke taakverdeling Load balancer In het klassieke implementatiemodel wees het platform een impliciete load balancer toe aan elke cloudservice. Tijdens de migratie wordt een nieuwe load-balancerresource gemaakt. De eindpuntset met gelijke taakverdeling wordt omgezet in load-balancerregels.
Inkomende NAT-regels Inkomende NAT-regels Invoereindpunten die zijn gedefinieerd op de virtuele machine worden tijdens de migratie geconverteerd naar binnenkomende vertaalregels voor netwerkadressen onder de load balancer.
VIP-adres Openbaar IP-adres met DNS-naam Het virtuele IP-adres wordt een openbaar IP-adres en is gekoppeld aan de load balancer. Een virtueel IP-adres kan alleen worden gemigreerd als er een invoereindpunt aan is toegewezen. Als u het IP-adres wilt behouden, kunt u het vóór de migratie converteren naar gereserveerd IP-adres . Tijdens deze wijziging is er downtime van ongeveer 60 seconden.
Virtueel netwerk Virtueel netwerk Het virtuele netwerk wordt met alle eigenschappen gemigreerd naar het Resource Manager-implementatiemodel. Er wordt een nieuwe resourcegroep gemaakt met de naam -migrated.
Gereserveerde IP-adressen Openbaar IP-adres met een statische toewijzingsmethode Gereserveerd IP-adressen die zijn gekoppeld aan de load balancer worden gemigreerd, samen met de migratie van de cloudservice of de virtuele machine. Niet-gekoppelde gereserveerde IP-adressen kunnen worden gemigreerd met Move-AzureReservedIP.
Openbaar IP-adres per VM Openbaar IP-adres met een dynamische toewijzingsmethode Het openbare IP-adres dat aan de VIRTUELE machine is gekoppeld, wordt geconverteerd als een openbare IP-adresresource, waarbij de toewijzingsmethode is ingesteld op dynamisch.
NSG's NSG's Netwerkbeveiligingsgroepen die zijn gekoppeld aan een virtuele machine of subnet, worden gekloond als onderdeel van de migratie naar het Resource Manager-implementatiemodel. De NSG in het klassieke implementatiemodel wordt niet verwijderd tijdens de migratie. De bewerkingen op het beheervlak voor de NSG worden echter geblokkeerd wanneer de migratie wordt uitgevoerd. Niet-gekoppelde NSG's kunnen worden gemigreerd met behulp van Move-AzureNetworkSecurityGroup.
DNS-servers DNS-servers DNS-servers die zijn gekoppeld aan een virtueel netwerk of de virtuele machine worden gemigreerd als onderdeel van de bijbehorende resourcemigratie, samen met alle eigenschappen.
UDR's UDR's Door de gebruiker gedefinieerde routes die zijn gekoppeld aan een subnet worden gekloond als onderdeel van de migratie naar het Resource Manager-implementatiemodel. De UDR in het klassieke implementatiemodel wordt niet verwijderd tijdens de migratie. De bewerkingen op het beheervlak voor de UDR worden geblokkeerd wanneer de migratie wordt uitgevoerd. Niet-gekoppelde UDR's kunnen worden gemigreerd met behulp van Move-AzureRouteTable.
De eigenschap Doorsturen via IP op de netwerkconfiguratie van een virtuele machine De eigenschap Doorsturen via IP op de NIC De eigenschap Doorsturen via IP op een virtuele machine wordt tijdens de migratie geconverteerd naar een eigenschap op de netwerkinterface.
Load balancer met meerdere IP-adressen Load balancer met meerdere openbare IP-resources Elk openbaar IP-adres dat aan de load balancer is gekoppeld, wordt na de migratie geconverteerd naar een openbare IP-resource en gekoppeld aan de load balancer.
Interne DNS-namen op de virtuele machine Interne DNS-namen op de NIC Tijdens de migratie worden de interne DNS-achtervoegsels voor de virtuele machines gemigreerd naar een alleen-lezeneigenschap met de naam 'InternalDomainNameSuffix' op de NIC. Het achtervoegsel blijft ongewijzigd na de migratie en de VM-resolutie blijft werken zoals eerder.
Gateway voor een virtueel netwerk Gateway voor een virtueel netwerk Eigenschappen van virtuele netwerkgateway worden ongewijzigd gemigreerd. Het VIP dat is gekoppeld aan de gateway wordt ook niet gewijzigd.
Lokale netwerksite Lokale netwerkgateway Eigenschappen van lokale netwerksite worden ongewijzigd gemigreerd naar een nieuwe resource, een lokale netwerkgateway genoemd. Dit vertegenwoordigt on-premises adresvoorvoegsels en het IP-adres van de externe gateway.
Verwijzingen naar verbindingen Connection Verbinding maken iviteitsverwijzingen tussen de gateway en de lokale netwerksite in de netwerkconfiguratie worden vertegenwoordigd door een nieuwe resource met de naam Verbinding maken ion. Alle eigenschappen van connectiviteitsreferenties in netwerkconfiguratiebestanden worden ongewijzigd gekopieerd naar de Verbinding maken ionresource. Verbinding maken iviteit tussen virtuele netwerken in het klassieke implementatiemodel wordt bereikt door twee IPsec-tunnels te maken naar lokale netwerksites die de virtuele netwerken vertegenwoordigen. Dit wordt getransformeerd naar het verbindingstype virtueel-netwerk-naar-virtueel-netwerk in het Resource Manager-model, zonder dat hiervoor lokale netwerkgateways nodig zijn.

Wijzigingen aanbrengen in uw automatisering en hulpprogramma’s na de migratie

Als onderdeel van het migreren van uw resources van het klassieke implementatiemodel naar het Resource Manager-implementatiemodel, moet u uw bestaande automatisering of hulpprogramma's bijwerken om ervoor te zorgen dat deze blijft werken na de migratie.

Volgende stappen