Share via

Planning voor de migratie van IaaS-resources van het klassieke implementatiemodel 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.

Hoewel Azure Resource Manager talloze geweldige functies biedt, is het essentieel om uw migratietraject te plannen om ervoor te zorgen dat alles soepel verloopt. Als u tijd besteedt aan de planning, zorgt u ervoor dat u geen problemen ondervindt tijdens het uitvoeren van migratieactiviteiten.

Notitie

De volgende richtlijnen zijn sterk bijgedragen door het Azure Customer Advisory-team en cloudoplossingsarchitecten die samenwerken met klanten voor het migreren van grote omgevingen. Daarom blijft dit document bijgewerkt naarmate er nieuwe succespatronen ontstaan, dus kijk van tijd tot tijd terug om te zien of er nieuwe aanbevelingen zijn.

Er zijn vier algemene fasen van het migratietraject:

Migratiefasen

Plannen

Technische overwegingen en compromissen

Afhankelijk van de grootte van uw technische vereisten, geografische gebieden en operationele procedures, kunt u het volgende overwegen:

  1. Waarom is Azure Resource Manager gewenst voor uw organisatie? Wat zijn de zakelijke redenen voor een migratie?
  2. Wat zijn de technische redenen voor Azure Resource Manager? Welke (indien van toepassing) andere Azure-services wilt u gebruiken?
  3. Welke toepassing (of sets virtuele machines) is opgenomen in de migratie?
  4. Welke scenario's worden ondersteund met de migratie-API? Controleer de niet-ondersteunde functies en configuraties.
  5. Ondersteunen uw operationele teams nu toepassingen/VM's in zowel de klassieke versie als Azure Resource Manager?
  6. Hoe (indien helemaal) wijzigt Azure Resource Manager uw VM-implementatie-, beheer-, bewakings- en rapportageprocessen? Moeten uw implementatiescripts worden bijgewerkt?
  7. Wat is het communicatieplan om belanghebbenden (eindgebruikers, toepassingseigenaren en infrastructuureigenaren) te waarschuwen?
  8. Afhankelijk van de complexiteit van de omgeving, moet er een onderhoudsperiode zijn waarbij de toepassing niet beschikbaar is voor eindgebruikers en voor toepassingseigenaren? Zo ja, hoe lang?
  9. Wat is het trainingsplan om ervoor te zorgen dat belanghebbenden deskundig en bekwaam zijn in Azure Resource Manager?
  10. Wat is het programmabeheer- of projectmanagementplan voor de migratie?
  11. Wat zijn de tijdlijnen voor de migratie van Azure Resource Manager en andere gerelateerde technologieroadmaps? Zijn ze optimaal uitgelijnd?

Patronen van succes

Succesvolle klanten hebben gedetailleerde plannen waarin de voorgaande vragen worden besproken, gedocumenteerd en beheerd. Zorg ervoor dat de migratieplannen breed worden gecommuniceerd met sponsors en belanghebbenden. Uzelf voorzien van kennis over uw migratieopties; het lezen van deze onderstaande migratiedocumentset wordt ten zeerste aanbevolen.

Valkuilen om te vermijden

  • Kan niet plannen. De technologiestappen van deze migratie zijn bewezen en het resultaat is voorspelbaar.
  • Veronderstelling dat de door het platform ondersteunde migratie-API rekening houdt met alle scenario's. Lees de niet-ondersteunde functies en configuraties om te begrijpen welke scenario's worden ondersteund.
  • Het plannen van potentiële toepassingsstoring voor eindgebruikers is niet mogelijk. Plan voldoende buffer om eindgebruikers voldoende te waarschuwen voor mogelijk niet-beschikbare toepassingstijd.

Testlab

Uw omgeving repliceren en een testmigratie uitvoeren

Notitie

De exacte replicatie van uw bestaande omgeving wordt uitgevoerd met behulp van een door de community bijgedragen hulpprogramma dat niet officieel wordt ondersteund door Microsoft Ondersteuning. Daarom is het een optionele stap, maar het is de beste manier om problemen te achterhalen zonder uw productieomgevingen aan te raken. Als het gebruik van een door de community bijgedragen hulpprogramma geen optie is, lees dan hieronder over de aanbeveling Voor valideren/voorbereiden/afbreken van dry run.

Het uitvoeren van een labtest van uw exacte scenario (compute, netwerken en opslag) is de beste manier om een soepele migratie te garanderen. Dit zorgt ervoor dat:

  • Een volledig afzonderlijk lab of een bestaande niet-productieomgeving die moet worden getest. We raden een volledig afzonderlijk lab aan dat herhaaldelijk kan worden gemigreerd en kan destructief worden gewijzigd. Scripts voor het verzamelen/hydrateren van metagegevens van de echte abonnementen worden hieronder vermeld.

  • Het is een goed idee om het lab in een afzonderlijk abonnement te maken. De reden hiervoor is dat het lab herhaaldelijk wordt afgebroken en een afzonderlijk, geïsoleerd abonnement heeft, vermindert de kans dat iets echt per ongeluk wordt verwijderd.

    Dit kan worden bereikt met behulp van het hulpprogramma AsmMetadataParser. Meer informatie over dit hulpprogramma vindt u hier

Patronen van succes

De volgende problemen zijn ontdekt in veel van de grotere migraties. Dit is geen volledige lijst en raadpleeg de niet-ondersteunde functies en configuraties voor meer informatie. U kunt deze technische problemen wel of niet tegenkomen, maar als u deze wel oplost voordat u de migratie uitvoert, zorgt dit voor een soepelere ervaring.

  • Voer een dry run valideren/voorbereiden/afbreken. Dit is misschien wel de belangrijkste stap om ervoor te zorgen dat klassiek naar Azure Resource Manager-migratie is geslaagd. De migratie-API heeft drie hoofdstappen: Valideren, Voorbereiden en Doorvoeren. Valideren leest de status van uw klassieke omgeving en retourneert een resultaat van alle problemen. Omdat er echter mogelijk problemen zijn in de Azure Resource Manager-stack, zal Validate niet alles onderscheppen. De volgende stap in het migratieproces helpt Voorbereiden bij het blootstellen van deze problemen. De metagegevens worden verplaatst van klassiek naar Azure Resource Manager, maar worden de verplaatsing niet doorgevoerd en worden niets aan de klassieke kant verwijderd of gewijzigd. De drooguitvoering omvat het voorbereiden van de migratie en het afbreken (niet doorvoeren) van de migraties. Het doel van het valideren/voorbereiden/afbreken van een droge uitvoering is om alle metagegevens in de Azure Resource Manager-stack te bekijken, te onderzoeken (programmatisch of in de portal) en te controleren of alles correct wordt gemigreerd en technische problemen doorloopt. Het geeft u ook een idee van de migratieduur, zodat u de downtime dienovereenkomstig kunt plannen. Een validatie/voorbereiding/afbreken veroorzaakt geen downtime van gebruikers; Daarom is het niet-afbreekbaar voor het gebruik van toepassingen.

    • De onderstaande items moeten worden opgelost voordat de droogloop wordt uitgevoerd, maar een dry run test zal deze voorbereidingsstappen ook veilig leegmaken als ze worden gemist. Tijdens de bedrijfsmigratie hebben we vastgesteld dat de dry run een veilige en waardevolle manier is om de gereedheid van de migratie te garanderen.
    • Wanneer de voorbereiding wordt uitgevoerd, wordt het besturingsvlak (Azure-beheerbewerkingen) vergrendeld voor het hele virtuele netwerk, zodat er tijdens het valideren/voorbereiden/afbreken geen wijzigingen kunnen worden aangebracht in vm-metagegevens. Maar anders wordt een toepassingsfunctie (RD, VM-gebruik, enzovoort) niet beïnvloed. Gebruikers van de VM's weten niet dat de dry run wordt uitgevoerd.

  • ExpressRoute-circuits en VPN. Momenteel kunnen Express Route-gateways met autorisatiekoppelingen niet zonder downtime worden gemigreerd. Zie ExpressRoute-circuits en gekoppelde virtuele netwerken migreren van het klassieke naar het Resource Manager-implementatiemodel voor de tijdelijke oplossing.

  • VM-extensies : extensies van virtuele machines zijn mogelijk een van de grootste obstakels voor het migreren van actieve VM's. Herstel van VM-extensies kan 1-2 dagen duren, dus plan dienovereenkomstig. Er is een werkende Azure-agent nodig om de vm-extensiestatus van actieve VM's te rapporteren. Als de status weer zo slecht is voor een actieve VM, wordt de migratie gestopt. De agent zelf hoeft niet te werken om migratie mogelijk te maken, maar als er extensies op de VIRTUELE machine bestaan, is zowel een werkende agent als uitgaande internetverbinding (met DNS) nodig voor migratie om verder te gaan.

    • Als de connectiviteit met een DNS-server verloren gaat tijdens de migratie, moeten alle VM-extensies behalve BGInfo v1.* eerst van elke VM worden verwijderd voordat de migratie wordt voorbereid en vervolgens opnieuw worden toegevoegd aan de VM na de migratie van Azure Resource Manager. Dit geldt alleen voor VM's die worden uitgevoerd. Als de toewijzing van de VM's is gestopt, hoeven VM-extensies niet te worden verwijderd. Opmerking: Veel extensies zoals Diagnostische gegevens van Azure en Defender voor Cloud bewaking worden na de migratie opnieuw geïnstalleerd, dus het verwijderen hiervan is geen probleem.

    • Zorg er bovendien voor dat netwerkbeveiligingsgroepen geen uitgaande internettoegang beperken. Dit kan gebeuren met sommige configuraties van netwerkbeveiligingsgroepen. Uitgaande internettoegang (en DNS) is nodig om VM-extensies te migreren naar Azure Resource Manager.

    • Er zijn twee versies van de BGInfo-extensie: v1 en v2. Als de virtuele machine is gemaakt met behulp van Azure Portal of PowerShell, heeft de VIRTUELE machine waarschijnlijk de v1-extensie. Deze extensie hoeft niet te worden verwijderd en wordt overgeslagen (niet gemigreerd) door de migratie-API. Als de klassieke VM echter is gemaakt met de nieuwe Azure-portal, heeft deze waarschijnlijk de V2-versie op basis van JSON van BGInfo, die kan worden gemigreerd naar Azure Resource Manager, mits de agent werkt en uitgaande internettoegang (en DNS) heeft.

    • Hersteloptie 1. Als u weet dat uw VM's geen uitgaande internettoegang, een werkende DNS-service en werkende Azure-agents op de VM's hebben, verwijdert u alle VM-extensies als onderdeel van de migratie voordat u zich voorbereidt, installeert u de VM-extensies na de migratie opnieuw.

    • Hersteloptie 2. Als VM-extensies te groot zijn, is er een andere optie om alle VM's vóór de migratie af te sluiten/de toewijzing ervan ongedaan te maken. Migreer de toegewezen VM's en start ze vervolgens opnieuw op aan de zijde van Azure Resource Manager. Het voordeel hiervan is dat VM-extensies worden gemigreerd. Het nadeel is dat alle openbare virtuele IP-adressen verloren gaan (dit kan een niet-starter zijn), en uiteraard zullen de VM's worden afgesloten, wat een veel grotere impact op werktoepassingen veroorzaakt.

      Notitie

      Als een Microsoft Defender voor Cloud-beleid is geconfigureerd voor de actieve VM's die worden gemigreerd, moet het beveiligingsbeleid worden gestopt voordat u extensies verwijdert, anders wordt de extensie voor beveiligingscontrole automatisch opnieuw geïnstalleerd op de VIRTUELE machine nadat u het hebt verwijderd.

  • Beschikbaarheidssets : voor een virtueel netwerk (vNet) dat moet worden gemigreerd naar Azure Resource Manager, moet de klassieke implementatie (bijvoorbeeld cloudservice) allemaal in één beschikbaarheidsset staan of moeten de VM's allemaal niet in een beschikbaarheidsset staan. Het hebben van meer dan één beschikbaarheidsset in de cloudservice is niet compatibel met Azure Resource Manager en stopt de migratie. Daarnaast kunnen er geen vm's in een beschikbaarheidsset zijn en sommige VM's die zich niet in een beschikbaarheidsset bevinden. Om dit op te lossen, moet u uw cloudservice herstellen of opnieuw toewijzen. Plan dienovereenkomstig, omdat dit mogelijk tijdrovend is.

  • Implementaties van web-/werkrollen: cloudservices met web- en werkrollen kunnen niet worden gemigreerd naar Azure Resource Manager. De web-/werkrollen moeten eerst worden verwijderd uit het virtuele netwerk voordat de migratie kan worden gestart. Een typische oplossing is het verplaatsen van web-/werkrolinstanties naar een afzonderlijk klassiek virtueel netwerk dat ook is gekoppeld aan een ExpressRoute-circuit of om de code te migreren naar nieuwere PaaS App Services (deze discussie valt buiten het bereik van dit document). Maak in het vorige geval een nieuw klassiek virtueel netwerk, verplaats/implementeer de web-/werkrollen naar dat nieuwe virtuele netwerk en verwijder vervolgens de implementaties uit het virtuele netwerk die worden verplaatst. Er zijn geen codewijzigingen vereist. De nieuwe peeringfunctie voor virtuele netwerken kan worden gebruikt om het klassieke virtuele netwerk met de web-/werkrollen en andere virtuele netwerken in dezelfde Azure-regio te koppelen, zoals het virtuele netwerk dat wordt gemigreerd (nadat de migratie van het virtuele netwerk is voltooid als gekoppelde virtuele netwerken niet kunnen worden gemigreerd), waardoor dezelfde mogelijkheden zonder prestatieverlies en geen bandbreedtebeperkingen worden geboden. Gezien de toevoeging van Peering voor virtuele netwerken kunnen web-/werkrolimplementaties nu eenvoudig worden beperkt en wordt de migratie naar Azure Resource Manager niet geblokkeerd.

  • Azure Resource Manager-quota : Azure-regio's hebben afzonderlijke quota/limieten voor zowel klassieke als Azure Resource Manager. Hoewel er in een migratiescenario geen nieuwe hardware wordt gebruikt (we wisselen bestaande VM's van klassiek naar Azure Resource Manager) moeten Azure Resource Manager-quota nog steeds met voldoende capaciteit zijn ingesteld voordat de migratie kan worden gestart. Hieronder vindt u de belangrijkste limieten die we hebben gezien, veroorzaken problemen. Open een quotumondersteuningsticket om de limieten te verhogen.

    Notitie

    Deze limieten moeten worden verhoogd in dezelfde regio als uw huidige omgeving die moet worden gemigreerd.

    • Netwerkinterfaces

    • Taakverdelers

    • Openbare IP's

    • Statische openbare IP-adressen

    • Kernen

    • Netwerkbeveiligingsgroepen

    • Routetabellen

      U kunt uw huidige Azure Resource Manager-quota controleren met behulp van de volgende opdrachten met de nieuwste versie van Azure CLI.

      Compute (kernen, beschikbaarheidssets)

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

      Netwerk (virtuele netwerken, statische openbare IP's, openbare IP's, netwerkbeveiligingsgroepen, netwerkinterfaces, load balancers, routetabellen)

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

      Opslag (opslagaccount)

      az storage account show-usage

  • Beperkingslimieten voor De Azure Resource Manager-API: als u een grote omgeving hebt (bijvoorbeeld > 400 VM's in een VNET), bereikt u mogelijk de standaardlimieten voor API-beperking voor schrijfbewerkingen (momenteel 1200 schrijfbewerkingen/uur) in Azure Resource Manager. Voordat u de migratie start, moet u een ondersteuningsticket indienen om deze limiet voor uw abonnement te verhogen.

  • Time-out van inrichting van VM-status: als er een time-out optreedt voor een virtuele machine met de status van de inrichting, moet dit vóór de migratie worden opgelost. De enige manier om dit te doen, is met downtime door de inrichting van de VIRTUELE machine ongedaan te maken of opnieuw in te stellen (verwijder deze, behoud de schijf en maak de VIRTUELE machine opnieuw).

  • RoleStateUnknown VM-status: als de migratie wordt gestopt vanwege een onbekend foutbericht over een rolstatus, controleert u de VM met behulp van de portal en controleert u of deze actief is. Deze fout gaat meestal zelfstandig weg (geen herstel vereist) na een paar minuten en is vaak een tijdelijk type dat vaak wordt gezien tijdens het starten van een virtuele machine, stoppen, opnieuw opstarten. Aanbevolen procedure: probeer de migratie na een paar minuten opnieuw uit te voeren.

  • Fabric-cluster bestaat niet. In sommige gevallen kunnen bepaalde VM's om verschillende oneven redenen niet worden gemigreerd. Een van deze bekende gevallen is als de virtuele machine onlangs is gemaakt (in de afgelopen week of zo) en een Azure-cluster landt dat nog niet is uitgerust voor Azure Resource Manager-workloads. Er wordt een foutbericht weergegeven met de mededeling dat het infrastructuurcluster niet bestaat en dat de VIRTUELE machine niet kan worden gemigreerd. Als u een paar dagen wacht, wordt dit specifieke probleem meestal opgelost, omdat Azure Resource Manager binnenkort wordt ingeschakeld voor het cluster. Een directe tijdelijke oplossing is echter voor stop-deallocate de virtuele machine, gaat door met de migratie en start de VIRTUELE machine opnieuw in Azure Resource Manager nadat deze is gemigreerd.

Valkuilen om te vermijden

  • Gebruik geen snelkoppelingen en laat de migraties voor het valideren/voorbereiden/afbreken van de dry run niet weg.
  • De meeste, zo niet alle, van uw potentiële problemen zullen zich voordoen tijdens de stappen valideren/voorbereiden/afbreken.

Migratie

Technische overwegingen en compromissen

U bent nu klaar omdat u de bekende problemen met uw omgeving hebt doorlopen.

Voor de echte migraties kunt u het volgende overwegen:

  1. Plan en plan het virtuele netwerk (kleinste migratie-eenheid) met een toenemende prioriteit. Doe eerst de eenvoudige virtuele netwerken en voortgang met de gecompliceerdere virtuele netwerken.
  2. De meeste klanten hebben niet-productie- en productieomgevingen. De productieplanning is voor het laatst gepland.
  3. (OPTIONEEL) Plan een onderhoudstijd met voldoende buffer voor het geval er onverwachte problemen optreden.
  4. Communiceer met en stem af met uw ondersteuningsteams voor het geval er problemen optreden.

Patronen van succes

De technische richtlijnen uit de sectie Labtest hierboven moeten worden overwogen en beperkt voordat een echte migratie wordt uitgevoerd. Met adequate tests is de migratie eigenlijk een niet-gebeurtenis. Voor productieomgevingen kan het handig zijn om aanvullende ondersteuning te bieden, zoals een vertrouwde Microsoft-partner of Microsoft Premier-services.

Valkuilen om te vermijden

Niet volledig testen kan problemen en vertraging in de migratie veroorzaken.

Voorbij migratie

Technische overwegingen en compromissen

Nu u zich in Azure Resource Manager bevindt, maximaliseert u het platform. Lees het overzicht van Azure Resource Manager voor meer informatie over extra voordelen.

Aandachtspunten:

  • De migratie bundelen met andere activiteiten. De meeste klanten kiezen voor een onderhoudsvenster voor toepassingen. Zo ja, dan kunt u deze downtime gebruiken om andere Mogelijkheden van Azure Resource Manager in te schakelen, zoals versleuteling en migratie naar Beheerde schijven.
  • Ga opnieuw naar de technische en zakelijke redenen voor Azure Resource Manager; schakel de extra services in die alleen beschikbaar zijn in Azure Resource Manager die van toepassing zijn op uw omgeving.
  • Uw omgeving moderniseren met PaaS-services.

Patronen van succes

Wees doelgericht op welke services u nu wilt inschakelen in Azure Resource Manager. Veel klanten vinden het onderstaande interessant voor hun Azure-omgevingen:

Valkuilen om te vermijden

Vergeet niet waarom u dit klassieke migratietraject naar Azure Resource Manager hebt gestart. Wat waren de oorspronkelijke zakelijke redenen? Heb je de zakelijke reden bereikt?

Volgende stappen