Planning voor de migratie van IaaS-resources van het klassieke implementatiemodel naar Azure Resource Manager

  • Artikel

Van toepassing op: ✔️ Linux-VM's ✔️ Windows-VM's

Belangrijk

Momenteel maakt ongeveer 90% van de IaaS-VM's gebruik van Azure Resource Manager. Vanaf 28 februari 2020 zijn klassieke VM's afgeschaft en worden ze op 6 september 2023 volledig buiten gebruik gesteld. 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. Door tijd te besteden aan planning, zorgt u ervoor dat u geen problemen ondervindt bij het uitvoeren van migratieactiviteiten.

Notitie

Aan de volgende richtlijnen is veel bijgedragen door het Azure Customer Advisory-team en cloudoplossingsarchitecten die samen met klanten werken aan het migreren van grote omgevingen. Daarom wordt dit document steeds bijgewerkt naarmate er nieuwe succespatronen ontstaan. Controleer daarom af en toe 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 aanwezig) andere Azure-services wilt u gebruiken?
  3. Welke toepassing (of sets virtuele machines) zijn 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 klassieke als Azure Resource Manager?
  6. Hoe wijzigt Azure Resource Manager uw VM-implementatie, beheer, bewaking en rapportageprocessen (indien al)? 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 waarin de toepassing niet beschikbaar is voor eindgebruikers en toepassingseigenaren? Zo ja, hoe lang?
  9. Wat is het trainingsplan om ervoor te zorgen dat belanghebbenden goed geïnformeerd en bekwaam zijn in Azure Resource Manager?
  10. Wat is het programmabeheer- of projectbeheerplan 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 naar 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.
  • Ga ervan uit 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.
  • Potentiële toepassingsstoring voor eindgebruikers wordt niet gepland. Plan voldoende buffer om eindgebruikers adequaat te waarschuwen voor mogelijk niet-beschikbare toepassingstijd.

Labtest

Uw omgeving repliceren en een testmigratie uitvoeren

Notitie

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 op te sporen zonder uw productieomgevingen te raken. Als het gebruik van een door de community bijgedragen hulpprogramma geen optie is, leest u hieronder meer over de aanbeveling Dry Run valideren/voorbereiden/afbreken.

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 voor het volgende:

  • Een volledig afzonderlijk lab of een bestaande niet-productieomgeving om te testen. We raden een volledig afzonderlijk lab aan dat herhaaldelijk kan worden gemigreerd en destructief kan 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 dat een afzonderlijk, geïsoleerd abonnement de kans verkleint dat iets echts per ongeluk wordt verwijderd.

    Dit kan worden bereikt met behulp van het hulpprogramma AsmMetadataParser. Lees hier meer over dit hulpprogramma

Patronen van succes

De volgende problemen zijn gedetecteerd in veel van de grotere migraties. Dit is geen volledige lijst en raadpleeg de niet-ondersteunde functies en configuraties voor meer informatie. Deze technische problemen kunnen al dan niet optreden, maar als u deze wel oplost voordat u de migratie uitvoert, zorgt dit voor een soepelere ervaring.

  • Een dry run valideren/voorbereiden/afbreken uitvoeren: dit is misschien wel de belangrijkste stap om ervoor te zorgen dat de migratie van klassiek naar Azure Resource Manager is geslaagd. De migratie-API bestaat uit 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, ondervangt Validate niet alles. De volgende stap in het migratieproces, Voorbereiden, helpt deze problemen bloot te leggen. Met Voorbereiden worden de metagegevens verplaatst van klassiek naar Azure Resource Manager, maar de verplaatsing wordt niet doorgevoerd en er wordt niets aan de klassieke zijde verwijderd of gewijzigd. De drooguitvoering omvat het voorbereiden van de migratie en vervolgens het afbreken (niet doorvoeren) van de migraties die worden voorbereid. Het doel van het valideren/voorbereiden/afbreken van de uitvoering is om alle metagegevens in de Azure Resource Manager-stack te bekijken, deze te controleren (programmatisch of in de portal), te controleren of alles correct wordt gemigreerd en technische problemen te doorlopen. Het geeft u ook een idee van de duur van de migratie, zodat u de downtime dienovereenkomstig kunt plannen. Valideren/voorbereiden/afbreken veroorzaakt geen downtime van gebruikers; daarom is het niet-verstorend voor toepassingsgebruik.

    • De onderstaande items moeten vóór de droogloop worden opgelost, maar een drooglooptest 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 migratiegereedheid te garanderen.
    • Wanneer voorbereiding wordt uitgevoerd, wordt het besturingsvlak (Azure-beheerbewerkingen) vergrendeld voor het hele virtuele netwerk, zodat er geen wijzigingen kunnen worden aangebracht in vm-metagegevens tijdens het valideren/voorbereiden/afbreken. Maar anders wordt elke 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. ExpressRoute-gateways met autorisatiekoppelingen kunnen momenteel niet worden gemigreerd zonder downtime. Zie ExpressRoute-circuits en gekoppelde virtuele netwerken migreren van het klassieke naar het Resource Manager-implementatiemodel voor de tijdelijke oplossing.

  • VM-extensies : extensies voor virtuele machines zijn mogelijk een van de grootste obstakels voor het migreren van actieve VM's. Herstel van VM-extensies kan meer dan 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 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 VM bestaan, is zowel een werkende agent als een uitgaande internetverbinding (met DNS) nodig voor de migratie.

    • Als de verbinding met een DNS-server tijdens de migratie wordt verbroken, moeten alle VM-extensies behalve BGInfo v1.* eerst worden verwijderd van elke VIRTUELE machine 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 ongedaan wordt gemaakt, hoeven VM-extensies niet te worden verwijderd. Opmerking: Veel extensies zoals Azure Diagnostics en Defender for Cloud-bewaking worden na de migratie opnieuw geïnstalleerd, dus het verwijderen ervan is geen probleem.

    • Zorg er bovendien voor dat netwerkbeveiligingsgroepen de uitgaande internettoegang niet beperken. Dit kan gebeuren bij 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 VM is gemaakt met behulp van de Azure Portal of PowerShell, heeft de VM waarschijnlijk de extensie v1. 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 op JSON gebaseerde v2-versie van BGInfo, die kan worden gemigreerd naar Azure Resource Manager op voorwaarde dat 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 vóór Voorbereiden en installeert u de VM-extensies na de migratie opnieuw.

    • Hersteloptie 2. Als VM-extensies te groot zijn, is een andere optie om alle VM's vóór de migratie af te sluiten of de toewijzing ervan ongedaan te maken. Migreer de niet-toegewezen VM's en start ze vervolgens opnieuw op aan de azure-Resource Manager zijde. 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 dat de VM's worden afgesloten, wat een veel grotere impact heeft op werkende toepassingen.

      Notitie

      Als een Microsoft Defender voor cloudbeleid is geconfigureerd voor de actieve VM's die worden gemigreerd, moet het beveiligingsbeleid worden gestopt voordat extensies worden verwijderd. Anders wordt de uitbreiding voor beveiligingsbewaking automatisch opnieuw geïnstalleerd op de VM nadat deze is verwijderd.

  • Beschikbaarheidssets: een virtueel netwerk (vNet) kan alleen worden gemigreerd naar Azure Resource Manager als de klassieke implementatie (cloudservice) zich allemaal in één beschikbaarheidsset bevindt of dat de VM's zich niet allemaal in een beschikbaarheidsset bevinden. Het hebben van meer dan één beschikbaarheidsset in de cloudservice is niet compatibel met Azure Resource Manager en stopt de migratie. Bovendien kunnen sommige VM's zich niet in een beschikbaarheidsset bevinden en sommige VM's niet in een beschikbaarheidsset. U kunt dit oplossen door uw cloudservice te herstellen of opnieuw te rangschikken. Plan dienovereenkomstig, omdat dit tijdrovend kan zijn.

  • Implementaties van web-/werkrollen: Cloud Services met web- en werkrollen kunnen niet worden gemigreerd naar Azure Resource Manager. De web-/werkrollen moeten eerst uit het virtuele netwerk worden verwijderd voordat de migratie kan worden gestart. Een typische oplossing is om web-/werkrolexemplaren te verplaatsen 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). In het vorige geval van herimplementatie maakt u een nieuw klassiek virtueel netwerk, verplaatst/implementeert u de web-/werkrollen opnieuw naar dat nieuwe virtuele netwerk en verwijdert u vervolgens de implementaties uit het virtuele netwerk dat wordt verplaatst. Er zijn geen codewijzigingen vereist. De nieuwe Virtual Network Peering-mogelijkheid 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 omdat gekoppelde virtuele netwerken niet kunnen worden gemigreerd), waardoor dezelfde mogelijkheden worden geboden zonder prestatieverlies en geen boetes voor latentie/bandbreedte. Gezien de toevoeging van Virtual Network Peering, kunnen implementaties van web-/werkrollen nu eenvoudig worden beperkt en de migratie naar Azure Resource Manager niet blokkeren.

  • Azure Resource Manager-quota: Azure-regio's hebben afzonderlijke quota/limieten voor zowel klassieke als Azure-Resource Manager. Hoewel 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 aanwezig zijn met voldoende capaciteit voordat de migratie kan worden gestart. Hieronder ziet u de belangrijkste limieten die problemen veroorzaken. Open een ondersteuningsticket voor quota om de limieten te verhogen.

    Notitie

    Deze limieten moeten worden verhoogd in dezelfde regio als uw huidige omgeving om te worden gemigreerd.

    • Netwerkinterfaces

    • Load balancers

    • Openbare IP-adressen

    • 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-adressen, openbare IP-adressen, netwerkbeveiligingsgroepen, netwerkinterfaces, load balancers, routetabellen)

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

      Storage(Opslagaccount)

      az storage account show-usage

  • Azure Resource Manager API-beperkingslimieten: als u een omgeving hebt die groot genoeg is (bijvoorbeeld > 400 VM's in een VNET), bereikt u mogelijk de standaard-API-beperkingslimieten voor schrijfbewerkingen (momenteel 1200 schrijfbewerkingen per uur) in Azure Resource Manager. Voordat u de migratie start, moet u een ondersteuningsticket indienen om deze limiet voor uw abonnement te verhogen.

  • Vm-status met time-out voor inrichting : als er een time-out optreedt voor een VM met de status van inrichting, moet dit voorafgaand aan de migratie worden opgelost. De enige manier om dit te doen, is met downtime door de inrichting van de VM ongedaan te maken of opnieuw in te delen (verwijder deze, behoud de schijf en maak de VM 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 wordt uitgevoerd. Deze fout verdwijnt meestal vanzelf (geen herstel vereist) na een paar minuten en is vaak een tijdelijk type dat vaak wordt gezien tijdens het starten, stoppen en opnieuw opstarten van een virtuele machine. Aanbevolen procedure: probeer de migratie na een paar minuten opnieuw uit te voeren.

  • Infrastructuurcluster bestaat niet : in sommige gevallen kunnen bepaalde VM's om verschillende redenen niet worden gemigreerd. Een van deze bekende gevallen is als de VM onlangs is gemaakt (in de afgelopen week of zo) en een Azure-cluster heeft ontvangen dat nog niet is uitgerust voor Azure Resource Manager-workloads. U krijgt een foutbericht met de mededeling dat het infrastructuurcluster niet bestaat en dat de VM 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 onmiddellijke tijdelijke oplossing is echter voor stop-deallocate de VM, ga vervolgens verder met de migratie en start de VM na de migratie een back-up in Azure Resource Manager.

Valkuilen om te vermijden

  • Gebruik geen snelkoppelingen en laat de migraties voor het valideren/voorbereiden/afbreken van de drooguitvoering niet achterwege.
  • De meeste, zo niet alle, potentiële problemen komen naar boven tijdens de stappen voor valideren,voorbereiden/afbreken.

Migratie

Technische overwegingen en compromissen

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

Voor de echte migraties kunt u het volgende overwegen:

  1. Plan en plan het virtuele netwerk (kleinste migratie-eenheid) met toenemende prioriteit. Doe eerst de eenvoudige virtuele netwerken en ga verder met de complexere virtuele netwerken.
  2. De meeste klanten hebben niet-productie- en productieomgevingen. De laatste productie plannen.
  3. (OPTIONEEL) Plan een uitvaltijd voor onderhoud met voldoende buffer voor het geval zich onverwachte problemen voordoen.
  4. Communiceer met en stem af met uw ondersteuningsteams in het geval zich problemen voordoen.

Patronen van succes

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

Valkuilen om te vermijden

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

Meer dan migratie

Technische overwegingen en compromissen

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

Aandachtspunten:

  • De migratie bundelen met andere activiteiten. De meeste klanten kiezen voor een onderhoudsvenster voor toepassingen. Als dat het zo is, kunt u deze downtime gebruiken om andere Azure Resource Manager-mogelijkheden in te schakelen, zoals versleuteling en migratie naar Managed Disks.
  • Bekijk de technische en zakelijke redenen voor Azure Resource Manager; schakel de aanvullende services in die alleen beschikbaar zijn op 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 aantrekkelijk voor hun Azure-omgevingen:

Valkuilen om te vermijden

Vergeet niet waarom u dit migratietraject van klassiek naar Azure Resource Manager hebt gestart. Wat waren de oorspronkelijke zakelijke redenen? Hebt u de zakelijke reden bereikt?

Volgende stappen