Share via

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

  • Artikel

Gäller för: ✔️ Virtuella Linux-datorer ✔️ med 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 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. Om du lägger tid på planering ser du till att du inte stöter på problem när du kör migreringsaktiviteter.

Anteckning

Följande vägledning har starkt bidragits 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 framgångsmö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 krav, storlek, geografiska områden och driftsmetoder 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 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 avisera 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? I så fall, 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 Migrering av Azure Resource Manager och andra relaterade tekniska vägkartor? Ä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 kommuniceras brett till sponsorer och intressenter. Utrusta dig med kunskap om dina migreringsalternativ; läs igenom den här migreringsdokumentuppsättningen nedan rekommenderas starkt.

Fallgropar att undvika

  • Det gick inte att planera. Teknikstegen i den här migreringen är bevisade 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ändare om potentiellt otillgänglig programtid.

Labbtest

Replikera din miljö och gör en testmigrering

Anteckning

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-bidragit verktyg läser du rekommendationen Validate/Prepare/Abort Dry Run 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 läsa mer om funktioner och konfigurationer som inte stöds . Du kanske eller kanske inte stöter på dessa tekniska problem, men om du löser dessa innan du försöker migrera kommer att säkerställa en smidigare upplevelse.

  • Gör en Valid/Prepare/Abort Dry Run – det här är kanske det viktigaste steget för att säkerställa att migreringen lyckas med klassisk till Azure Resource Manager. 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 verifiera/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 uppfattning om migreringstiden 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 torrkörningen, men ett test för torrkörning kommer också att spola ut dessa förberedelsesteg på ett säkert sätt om de missas. Under företagsmigreringen har vi upptäckt att torrkö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 programfunktionen (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 hindren 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 till på nytt till den virtuella datorn efter azure-Resource Manager migrering. Detta gäller endast för virtuella datorer som körs. Om de virtuella datorerna stoppas behöver inte VM-tillägg tas bort. Observera: Många tillägg som Azure Diagnostics och Defender for Cloud-övervakning 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 Portal eller PowerShell kommer den virtuella datorn troligen att ha v1-tillägget på sig. Det här tillägget behöver inte tas bort och hoppas över (migreras inte) av migrerings-API:et. Men om den klassiska virtuella datorn skapades med den nya Azure Portal har den förmodligen 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 före Förbered 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 naturligtvis stängs de virtuella datorerna av vilket orsakar en mycket större inverkan på fungerande program.

      Anteckning

      Om en Microsoft Defender för molnprincip har konfigurerats mot de virtuella datorer som körs som migreras måste säkerhetsprincipen stoppas innan tillägg tas bort. Annars installeras säkerhetsövervakningstillägget om automatiskt på den virtuella datorn när det 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 finnas 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 kompatibelt med Azure Resource Manager och stoppar migreringen. Dessutom kan det inte finnas några 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 därefter eftersom det kan vara tidskrävande.

  • Distributioner av webb-/arbetsroll – Cloud Services 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 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 omdistributionsfallet 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 Virtual Network peering-funktionen kan användas för att peer-koppla ihop 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 (när migreringen av virtuella nätverk har slutförts eftersom peerkopplade virtuella nätverk inte kan migreras), vilket ger samma funktioner utan prestandaförlust och inga svarstids-/bandbreddsförseningar. Med tanke på tillägget av Virtual Network peering kan distributioner av webb-/arbetsroller nu enkelt undvikas 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 klassiska datorer 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 begränsningarna som vi har sett orsaka problem. Öppna en kvotsupportbegäran för att höja gränserna.

    Anteckning

    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.

      Compute(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

  • Azure Resource Manager API-begränsningsgränser – Om du har en tillräckligt stor miljö (t.ex. > 400 virtuella datorer i ett virtuellt nätverk) kan du nå standardgränserna 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.

  • Status för tidsgränsen för etablering av virtuell dator – Om någon virtuell dator har statusen för etableringens 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/ometablera den virtuella datorn (ta bort den, behåll disken och återskapa den virtuella datorn).

  • RoleStateUnknown VM Status – Om migreringen stoppas på grund av ett okänt 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 under en virtuell dator som startar, stoppar och startar om . Rekommenderad metod: försök att migrera 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 (under 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 specifika problemet eftersom klustret snart kommer att aktivera Azure Resource Manager. 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 för att validera/förbereda/avbryta torrkörning.
  • De flesta, om inte alla, potentiella problem visas under stegen för att validera/förbereda/avbryta.

Migrering

Tekniska överväganden och kompromisser

Nu är du redo eftersom du har gått igenom kända problem 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 sist.
  3. (VALFRITT) Schemalägg ett underhållsavbrott med gott om buffert om oväntade problem skulle uppstå.
  4. Kommunicera med och anpassa med dina supportteam om det skulle uppstå problem.

Lyckade mönster

Den tekniska vägledningen från avsnittet Lab Test ovan bör övervägas och åtgärdas 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öjningar i migreringen.

Bortom migrering

Tekniska överväganden och kompromisser

Nu när du är i Azure Resource Manager kan du maximera plattformen. Läs översikten över Azure Resource Manager om du vill veta mer om ytterligare fördelar.

Saker att tänka på:

  • Paketering av migreringen med andra aktiviteter. De flesta kunder väljer en programunderhållsperiod. 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 Managed Disks.
  • Gå tillbaka till de tekniska och affärsmässiga orsakerna för Azure Resource Manager. Aktivera endast de ytterligare tjänster som ä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 uppmärksam på 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 den här migreringsresan från klassisk till Azure Resource Manager. Vilka var de ursprungliga affärsorsakerna? Har du uppnått affärsorsaken?

Nästa steg