Dela via

Planera för migrering av IaaS-resurser från klassisk till Azure Resource Manager

  • Artikel

Gäller för: ✔️ Virtuella Linux-datorer ✔️, virtuella Windows-datorer

Viktigt!

Idag använder cirka 90 % av de virtuella IaaS-datorerna Azure Resource Manager. Från och med den 28 februari 2020 har klassiska virtuella datorer blivit inaktuella och kommer att dras tillbaka helt den 6 september 2023. Läs mer om den här utfasningen och hur den påverkar dig.

Även om Azure Resource Manager erbjuder många fantastiska funktioner är det viktigt att planera migreringsresan för att se till att det går smidigt. När du planerar ser du till att du inte stöter på problem när du kör migreringsaktiviteter.

Kommentar

Följande vägledning bidrogs starkt till av Azures kundrådgivningsteam och molnlösningsarkitekter som arbetar med kunder för att migrera stora miljöer. Därför fortsätter det här dokumentet att uppdateras när nya lyckade mönster dyker upp, så kom tillbaka då och då för att se om det finns några nya rekommendationer.

Det finns fyra allmänna faser i migreringsresan:

Migreringsfaser

Planera

Tekniska överväganden och kompromisser

Beroende på dina tekniska kravs storlek, geografiska områden och operativa metoder kanske du vill överväga:

  1. Varför är Azure Resource Manager önskat för din organisation? Vilka är affärsorsakerna till en migrering?
  2. Vilka är de tekniska orsakerna till Azure Resource Manager? Vilka (om några) andra Azure-tjänster vill du använda?
  3. Vilket program (eller uppsättningar med virtuella datorer) ingår i migreringen?
  4. Vilka scenarier stöds med migrerings-API:et? Granska de funktioner och konfigurationer som inte stöds.
  5. Kommer dina operativa team nu att ha stöd för program/virtuella datorer i både klassiska och Azure Resource Manager?
  6. Hur (om alls) ändrar Azure Resource Manager dina processer för distribution, hantering, övervakning och rapportering av virtuella datorer? Behöver dina distributionsskript uppdateras?
  7. Vad är kommunikationsplanen för att varna intressenter (slutanvändare, programägare och infrastrukturägare)?
  8. Bör det finnas en underhållsperiod där programmet inte är tillgängligt för slutanvändare och programägare beroende på miljöns komplexitet? Om så är fallet, hur länge?
  9. Vad är utbildningsplanen för att säkerställa att intressenterna är kunniga och skickliga i Azure Resource Manager?
  10. Vad är programhanterings- eller projekthanteringsplanen för migreringen?
  11. Vilka är tidslinjerna för Azure Resource Manager-migreringen och andra relaterade tekniköversikter? Är de optimalt justerade?

Lyckade mönster

Framgångsrika kunder har detaljerade planer där föregående frågor diskuteras, dokumenteras och styrs. Se till att migreringsplanerna i stort sett förmedlas till sponsorer och intressenter. Ge dig själv kunskap om dina migreringsalternativ; läs igenom det här migreringsdokumentet nedan rekommenderas starkt.

Fallgropar att undvika

  • Det gick inte att planera. Teknikstegen i den här migreringen bevisas och resultatet är förutsägbart.
  • Antagandet att plattformen som stöds av migrerings-API:et kommer att ta hänsyn till alla scenarier. Läs de funktioner och konfigurationer som inte stöds för att förstå vilka scenarier som stöds.
  • Planerar inte potentiellt programstopp för slutanvändare. Planera tillräckligt med buffert för att varna slutanvändarna om potentiellt otillgänglig programtid.

Labbtest

Replikera din miljö och utföra en testmigrering

Kommentar

Exakt replikering av din befintliga miljö körs med hjälp av ett community-bidraget verktyg som inte stöds officiellt av Microsoft Support. Därför är det ett valfritt steg, men det är det bästa sättet att ta reda på problem utan att röra dina produktionsmiljöer. Om det inte är ett alternativ att använda ett community-bidraget kan du läsa om rekommendationen Verifiera/förbereda/avbryt torrkörning nedan.

Att utföra ett labbtest av ditt exakta scenario (beräkning, nätverk och lagring) är det bästa sättet att säkerställa en smidig migrering. På så sätt kan du se till att:

  • Ett helt separat labb eller en befintlig icke-produktionsmiljö att testa. Vi rekommenderar ett helt separat labb som kan migreras upprepade gånger och som kan ändras destruktivt. Skript för att samla in/hydratisera metadata från de verkliga prenumerationerna visas nedan.

  • Det är en bra idé att skapa labbet i en separat prenumeration. Anledningen är att labbet kommer att rivas upprepade gånger, och att ha en separat, isolerad prenumeration minskar risken för att något verkligt tas bort av misstag.

    Detta kan åstadkommas med hjälp av verktyget AsmMetadataParser. Läs mer om det här verktyget här

Lyckade mönster

Följande problem upptäcktes i många av de större migreringarna. Det här är inte en fullständig lista och du bör gå till funktioner och konfigurationer som inte stöds för mer information. Du kanske eller kanske inte stöter på dessa tekniska problem, men om du löser dessa innan du försöker migrera kommer det att säkerställa en smidigare upplevelse.

  • Gör en validering/förberedelse/avbryt torrkörning – Det här är kanske det viktigaste steget för att säkerställa att migreringen från klassisk till Azure Resource Manager lyckas. Migrerings-API:et har tre huvudsakliga steg: Verifiera, Förbereda och Checka in. Verifiera läser tillståndet för din klassiska miljö och returnerar ett resultat av alla problem. Men eftersom vissa problem kan finnas i Azure Resource Manager-stacken fångar Validate inte allt. Nästa steg i migreringsprocessen, Förbered, hjälper dig att exponera dessa problem. Förbered flyttar metadata från klassisk till Azure Resource Manager, men checkar inte in flytten och tar inte bort eller ändrar ingenting på den klassiska sidan. Den torra körningen innebär att förbereda migreringen och sedan avbryta (inte genomföra) migreringarna förbereds. Målet med att validera/förbereda/avbryta torrkörning är att se alla metadata i Azure Resource Manager-stacken, undersöka den (programmatiskt eller i portalen) och kontrollera att allt migreras korrekt och arbeta med tekniska problem. Det ger dig också en känsla av migreringstid så att du kan planera för stilleståndstid i enlighet med detta. En verifiering/förberedelse/abort orsakar inte några driftstopp för användaren. Därför är det inte indisruptivt för programanvändning.

    • Objekten nedan måste lösas före den torra körningen, men ett test av torrkörning kommer också att säkert spola ut dessa förberedelsesteg om de missas. Under företagsmigreringen har vi upptäckt att den torra körningen är ett säkert och ovärderligt sätt att säkerställa migreringsberedskap.
    • När förberedelsen körs låses kontrollplanet (Azure-hanteringsåtgärder) för hela det virtuella nätverket, så inga ändringar kan göras i VM-metadata under validering/förberedelse/abort. Men annars påverkas inte alla programfunktioner (RD, VM-användning osv.). Användare av de virtuella datorerna vet inte att den torra körningen körs.

  • Express Route-kretsar och VPN. Express Route Gateways med auktoriseringslänkar kan för närvarande inte migreras utan driftstopp. En lösning finns i Migrera ExpressRoute-kretsar och associerade virtuella nätverk från den klassiska till Resource Manager-distributionsmodellen.

  • VM-tillägg – Tillägg för virtuella datorer är potentiellt en av de största vägspärrarna för migrering av virtuella datorer som körs. Reparation av VM-tillägg kan ta upp till 1–2 dagar, så planera därefter. En fungerande Azure-agent krävs för att rapportera status för VM-tillägg för virtuella datorer som körs. Om statusen kommer tillbaka som felaktig för en virtuell dator som körs stoppas migreringen. Själva agenten behöver inte vara i funktion för att aktivera migrering, men om det finns tillägg på den virtuella datorn behövs både en fungerande agent och utgående Internetanslutning (med DNS) för att migreringen ska kunna gå vidare.

    • Om anslutningen till en DNS-server går förlorad under migreringen måste alla VM-tillägg utom BGInfo v1.* först tas bort från varje virtuell dator innan migreringen förbereds och sedan läggas tillbaka till den virtuella datorn efter Azure Resource Manager-migreringen. Detta gäller endast för virtuella datorer som körs. Om de virtuella datorerna stoppas behöver inte VM-tillägg tas bort. Obs! Många tillägg som Azure-diagnostik och Övervakning av Defender för molnet installerar om sig själva efter migreringen, så det är inget problem att ta bort dem.

    • Se dessutom till att nätverkssäkerhetsgrupper inte begränsar utgående internetåtkomst. Detta kan inträffa med vissa konfigurationer av nätverkssäkerhetsgrupper. Utgående internetåtkomst (och DNS) krävs för att VM-tillägg ska migreras till Azure Resource Manager.

    • Det finns två versioner av BGInfo-tillägget: v1 och v2. Om den virtuella datorn skapades med Hjälp av Azure-portalen eller PowerShell kommer den virtuella datorn sannolikt att ha v1-tillägget på sig. Det här tillägget behöver inte tas bort och hoppas över (inte migreras) av migrerings-API:et. Men om den klassiska virtuella datorn skapades med den nya Azure-portalen kommer den sannolikt att ha den JSON-baserade v2-versionen av BGInfo, som kan migreras till Azure Resource Manager förutsatt att agenten fungerar och har utgående Internetåtkomst (och DNS).

    • Reparationsalternativ 1. Om du vet att dina virtuella datorer inte har utgående internetåtkomst, en fungerande DNS-tjänst och fungerande Azure-agenter på de virtuella datorerna avinstallerar du alla VM-tillägg som en del av migreringen innan du förbereder och installerar sedan om VM-tilläggen efter migreringen.

    • Reparationsalternativ 2. Om VM-tillägg är för stora av ett hinder är ett annat alternativ att stänga av/frigöra alla virtuella datorer före migreringen. Migrera de frigjorda virtuella datorerna och starta sedan om dem på Azure Resource Manager-sidan. Fördelen här är att VM-tillägg migreras. Nackdelen är att alla offentliga virtuella IP-adresser kommer att gå förlorade (detta kan vara en icke-starter), och uppenbarligen kommer de virtuella datorerna att stängas av vilket orsakar en mycket större inverkan på arbetsprogram.

      Kommentar

      Om en Microsoft Defender for Cloud-princip har konfigurerats mot de virtuella datorer som körs som migreras måste säkerhetsprincipen stoppas innan tillägg tas bort. Annars installeras tillägget för säkerhetsövervakning om automatiskt på den virtuella datorn när den har tagits bort.

  • Tillgänglighetsuppsättningar – För att ett virtuellt nätverk (vNet) ska migreras till Azure Resource Manager måste den klassiska distributionen (dvs. molntjänsten) innehålla virtuella datorer vara i en tillgänglighetsuppsättning, eller så får de virtuella datorerna inte finnas i någon tillgänglighetsuppsättning. Att ha fler än en tillgänglighetsuppsättning i molntjänsten är inte kompatibel med Azure Resource Manager och stoppar migreringen. Dessutom kan det inte finnas vissa virtuella datorer i en tillgänglighetsuppsättning och vissa virtuella datorer som inte finns i en tillgänglighetsuppsättning. För att lösa detta måste du åtgärda eller ombilda din molntjänst. Planera i enlighet med detta eftersom det kan vara tidskrävande.

  • Distribution av webb-/arbetsroll – Molntjänster som innehåller webb- och arbetsroller kan inte migreras till Azure Resource Manager. Webb-/arbetsrollerna måste först tas bort från det virtuella nätverket innan migreringen kan starta. En vanlig lösning är att bara flytta webb-/arbetsrollinstanser till ett separat klassiskt virtuellt nätverk som också är länkat till en ExpressRoute-krets, eller att migrera koden till nyare PaaS App Services (den här diskussionen ligger utanför omfånget för det här dokumentet). I det tidigare omdistribueringsfallet skapar du ett nytt klassiskt virtuellt nätverk, flyttar/distribuerar om webb-/arbetsrollerna till det nya virtuella nätverket och tar sedan bort distributionerna från det virtuella nätverk som flyttas. Inga kodändringar krävs. Den nya peeringfunktionen för virtuellt nätverk kan användas för att peerkoppla det klassiska virtuella nätverket som innehåller webb-/arbetsroller och andra virtuella nätverk i samma Azure-region, till exempel det virtuella nätverk som migreras (efter att migreringen av virtuella nätverk har slutförts eftersom peer-kopplade virtuella nätverk inte kan migreras), vilket ger samma funktioner utan prestandaförlust och inga svarstider/bandbreddspåföljder. Med tanke på tillägget av peering för virtuella nätverk kan distributioner av webb-/arbetsroller nu enkelt minimeras och inte blockera migreringen till Azure Resource Manager.

  • Azure Resource Manager-kvoter – Azure-regioner har separata kvoter/gränser för både klassiska och Azure Resource Manager. Även om ny maskinvara inte används i ett migreringsscenario (vi byter befintliga virtuella datorer från klassisk till Azure Resource Manager), måste Azure Resource Manager-kvoter fortfarande finnas på plats med tillräckligt med kapacitet innan migreringen kan starta. Nedan visas de viktigaste gränserna som vi har sett orsaka problem. Öppna en kvotsupportbegäran för att höja gränserna.

    Kommentar

    Dessa gränser måste höjas i samma region som den aktuella miljön för att migreras.

    • Nätverksgränssnitt

    • Lastbalanserare

    • Offentliga IP-adresser

    • Statiska offentliga IP-adresser

    • Kärnor

    • Nätverkssäkerhetsgrupper

    • Routningstabeller

      Du kan kontrollera dina aktuella Azure Resource Manager-kvoter med hjälp av följande kommandon med den senaste versionen av Azure CLI.

      Beräkning (kärnor, tillgänglighetsuppsättningar)

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

      Nätverk (virtuella nätverk, statiska offentliga IP-adresser, offentliga IP-adresser, nätverkssäkerhetsgrupper, nätverksgränssnitt, lastbalanserare, routningstabeller)

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

      Lagring (lagringskonto)

      az storage account show-usage

  • Begränsningar för Api-begränsning i Azure Resource Manager – Om du har en tillräckligt stor miljö (t.ex. > 400 virtuella datorer i ett virtuellt nätverk) kan du nå standardgränsen för API-begränsning för skrivningar (för närvarande 1 200 skrivningar/timme) i Azure Resource Manager. Innan du påbörjar migreringen bör du skapa ett supportärende för att öka den här gränsen för din prenumeration.

  • Timeoutstatus för etablering av virtuell dator – Om någon virtuell dator har statusen för etableringen överskriden tidsgräns måste detta lösas före migreringen. Det enda sättet att göra detta är med stilleståndstid genom att avetablera/återskapa den virtuella datorn (ta bort den, behålla disken och återskapa den virtuella datorn).

  • RoleStateUnknown VM Status – Om migreringen stoppas på grund av ett okänt felmeddelande om rolltillstånd kontrollerar du den virtuella datorn med hjälp av portalen och kontrollerar att den körs. Det här felet försvinner vanligtvis på egen hand (ingen reparation krävs) efter några minuter och är ofta en tillfällig typ som ofta visas när en virtuell dator startar, stoppar och startar om . Rekommenderad metod: Försök migrera igen igen efter några minuter.

  • Infrastrukturkluster finns inte – i vissa fall kan vissa virtuella datorer inte migreras av olika udda skäl. Ett av dessa kända fall är om den virtuella datorn nyligen skapades (inom den senaste veckan eller så) och råkade landa ett Azure-kluster som ännu inte är utrustat för Azure Resource Manager-arbetsbelastningar. Du får ett felmeddelande om att infrastrukturklustret inte finns och att den virtuella datorn inte kan migreras. Att vänta ett par dagar löser vanligtvis det här problemet eftersom klustret snart kommer att få Azure Resource Manager aktiverat. En omedelbar lösning är dock till stop-deallocate den virtuella datorn, fortsätt sedan framåt med migreringen och starta den virtuella datorn igen i Azure Resource Manager efter migreringen.

Fallgropar att undvika

  • Ta inte genvägar och utelämna migreringarna validate/prepare/abort dry run.
  • De flesta, om inte alla, av dina potentiella problem visas under verifierings-/förberedelse-/abortstegen.

Migrering

Tekniska överväganden och kompromisser

Nu är du redo eftersom du har gått igenom de kända problemen med din miljö.

För de verkliga migreringarna kanske du vill överväga:

  1. Planera och schemalägg det virtuella nätverket (den minsta migreringsenheten) med ökad prioritet. Gör de enkla virtuella nätverken först och gå vidare med de mer komplicerade virtuella nätverken.
  2. De flesta kunder kommer att ha icke-produktions- och produktionsmiljöer. Schemalägg produktion senast.
  3. (VALFRITT) Schemalägg ett underhållsavbrott med gott om buffert om oväntade problem skulle uppstå.
  4. Kommunicera med och anpassa dig till dina supportteam om det skulle uppstå problem.

Lyckade mönster

Den tekniska vägledningen från avsnittet Labbtest ovan bör övervägas och minimeras före en verklig migrering. Med adekvat testning är migreringen faktiskt en icke-händelse. För produktionsmiljöer kan det vara bra att ha ytterligare support, till exempel en betrodd Microsoft-partner eller Microsoft Premier-tjänster.

Fallgropar att undvika

Inte fullständig testning kan orsaka problem och fördröjning i migreringen.

Bortom migrering

Tekniska överväganden och kompromisser

Nu när du är i Azure Resource Manager maximerar du plattformen. Läs översikten över Azure Resource Manager för att ta reda på mer om ytterligare fördelar.

Saker att tänka på:

  • Kombinera migreringen med andra aktiviteter. De flesta kunder väljer ett programunderhållsfönster. I så fall kanske du vill använda den här stilleståndstiden för att aktivera andra Azure Resource Manager-funktioner som kryptering och migrering till hanterade diskar.
  • Gå tillbaka till de tekniska och affärsmässiga orsakerna för Azure Resource Manager. aktivera de ytterligare tjänster som endast är tillgängliga i Azure Resource Manager som gäller för din miljö.
  • Modernisera din miljö med PaaS-tjänster.

Lyckade mönster

Var medveten om vilka tjänster du nu vill aktivera i Azure Resource Manager. Många kunder tycker att nedanstående är intressant för deras Azure-miljöer:

Fallgropar att undvika

Kom ihåg varför du startade migreringsresan klassisk till Azure Resource Manager. Vilka var de ursprungliga affärsorsakerna? Har du uppnå affärsorsaken?

Nästa steg