Migrera arbetsbelastningar till Azure VMware Solution

Den här artikeln innehåller vägledning som hjälper beslutsfattare att definiera sin migreringsstrategi för Azure VMware Solution, inklusive planerings-, körnings- och avvecklingsfaser.

Azure VMware Solution tillhandahåller en strukturerad sökväg för att migrera VMware-baserade arbetsbelastningar till Azure med minimal programändring. Framgång beror på mer än att flytta virtuella datorer. Organisationer behöver tydliga migreringsprinciper, kriterier för utvärdering av arbetsbelastningar, valideringsstandarder och körningskontroller som minskar risken, upprätthåller driftkontinuitet och stöder långsiktiga plattformsmål.

Rekommendation: Definiera din migreringsstrategi, arbetsbelastningsbedömningsmetod, migreringssekvens och valideringskrav innan du migrerar arbetsbelastningar till Azure VMware Solution.

1. Planering av migrering

Innan du utformar något skapar du en tydlig bild av vad du migrerar, i vilken ordning och varför. Använd metoden Cloud Adoption Framework Plan för att utvärdera din egendom. Azure VMware Solution passar bäst för en rehost-metod, där du behöver minimala störningar och ingen modernisering på kort sikt. Det är inte rätt plats för varje applikation, och planeringsfasen är den fas där du avgör det.

1.1 Identifiering och inventering

Azure Migrate söker igenom din lokala vSphere-miljö och skapar en inventering av virtuella datorer, deras resursanvändning och deras beroenden. Dessa uppgifter ligger till grund för både dimensionering (hur många värdar och vilken värdtyp) och vågindelning (vilka arbetslaster som flyttas tillsammans). Azure Migrate utför inte flytten till Azure VMware Solution. Det ger dig bevis för storlek och sekvensering av projektet.

1.2 Migreringsstrategi

Azure VMware Solution har främst stöd för rehost-metoden. Program som behöver refaktorisering eller omarbetning av arkitekturen kan vara bättre lämpade för Azures inbyggda beräkningstjänster. Registrera dessa beslut så att planen återspeglar avsiktliga val snarare än standardinställningar. Se Välj en strategi för molnmigrering.

1.3 Utvärdering av arbetsbelastning

Inte varje arbetsbelastning är en lika lämplig kandidat för Azure VMware Solution. Innan du tilldelar arbetsbelastningar till migreringsvågor bör du utvärdera deras tekniska krav, driftberoenden och plattformsanpassning. En strukturerad utvärdering hjälper dig att identifiera risker tidigt, validera lämpligheten och se till att migreringsplanerna återspeglar affärsprioriteringar snarare än antaganden.

1.3.1 Krav

Innan du tilldelar en arbetsbelastning till en migreringsvåg bör du utvärdera de tekniska, operativa och affärsmässiga krav som påverkar dess framgång på Azure VMware Solution. Den här utvärderingen hjälper dig att fastställa plattformens lämplighet, identifiera potentiella migreringsutmaningar och tillhandahålla den information som behövs för beslut om storlek, sekvensering och beredskap. När du utvärderar varje arbetsbelastning fokuserar du på:

Prestandakrav: Förstå processor-, minnes-, lagrings-IOPS- och nätverksdataflödeskrav. Koppla dessa krav till värd-SKU:er och vSAN-lagringsprinciper för Azure VMware Solution, inklusive RAID-konfiguration och FTT-inställningar (feltolerans).
Programberoenden: Identifiera vilka system varje arbetsbelastning kommunicerar med. Beroenden avgör planeringen av migreringsvågen och om beroende system behöver flyttas tillsammans.
Kompatibilitetskrav: Bekräfta att gästoperativsystem och programvara från tredje part stöds på Azure VMware Solution. De flesta arbetsbelastningar som körs i lokala vSphere-miljöer kan köras på Azure VMware Solution utan modifieringar, men validera i stället för att anta, och säkerställ att du testar din metod för återgång vid problematiska migreringar.
Nätverkskrav: Dokumentera nätverkssegment, IP-adresser, DNS-konfigurationer och brandväggsregler som varje arbetsbelastning kräver. Identifiera svarstidskänsliga arbetsbelastningar och se till att nätverksarkitekturen är optimerad för att stödja deras krav.

1.3.2 Arbetsbelastningsbehandling

Arbetsbelastningsbedömning identifierar vad en arbetsbelastning behöver. Arbetsbelastningsbehandling avgör vilka åtgärder som ska vidtas. Beslutsfattarna bör utvärdera om varje program hör till Azure VMware Solution, om det ska förbli lokalt eller om delar av programmet hanteras bättre av Azure interna tjänster. För varje arbetsbelastning avgör du:

Om arbetsbelastningen hör hemma där. Arbetsbelastningar som redan körs bra på vSphere är naturliga kandidater, särskilt de som inte har någon moderniseringsplan på kort sikt. För en arbetslast som ska avvecklas eller ersättas med en SaaS-lösning bör du överväga om det tillför något värde att flytta den eller om den bör ligga kvar till slutet av livscykeln.
Om varje nivå hör hemma där. En arbetsbelastning har ofta mer än en nivå, till exempel en webbklientdel och en databas. Du kan köra de virtuella programdatorerna på Azure VMware Solution och ansluta dem till Azure interna datatjänster som Azure SQL Database. Den konfigurationen ger dig fördelar med hanterade databaser tillsammans med dina VMware-arbetsbelastningar och minskar dina VMware-värd- och licenskostnader.

1.4 Beredskap för migrering

Definiera minimikraven för drift, prestanda, säkerhet och styrning som varje arbetsbelastning måste uppfylla innan du godkänner den för produktionsanvändning.

Tillämpa ett konsekvent valideringsramverk för varje migreringsvåg. Ramverket bör definiera obligatoriska kontroller, godkännandekriterier och den dokumentation som teamen måste tillhandahålla före godkännande av driftsättning. Verifiera minst:

HCX-replikeringsstatus
Routbarhet för NSX-segment
ESXi-värdhälsa
Identitets- och autentiseringstillgänglighet från målsegmentet
Hälsotillstånd för stödtjänster som säkerhetskopiering och övervakning

Bestäm om teamen måste samla in baslinjeprestandamått från källmiljön före migreringen. Dessa mätningar ger en referenspunkt för validering av prestanda efter migreringen och identifiering av regressioner.

Inför driftsättningen ska teamen fastställa om externa DNS-poster, lastbalanserarkonfigurationer, applikationsändpunkter eller andra anslutningsberoenden behöver uppdateras. Inkludera alla nödvändiga ändringar i vågräckningsplanen för att minska risken för avbrott i tjänsten.

1.5 Azure VMware Solution migreringssekvens

Migreringssekvensering avgör vilka arbetsbelastningar som flyttas till Azure VMware Solution första, andra och så vidare. God vågplanering minskar risken och undviker onödiga störningar.

Gruppera efter beroende: Använd beroendedata från identifiering för att hitta uppsättningar med virtuella datorer som fungerar nära varandra, till exempel en programserver och dess databas. Flytta dem i samma våg så att trafiken inte passerar nätverket för varje begäran när en del fortfarande väntar lokalt.
Mappa befintliga regler: Dokumentera eventuella tillhörighets- eller antitillhörighetsregler från din lokala miljö och planera hur de ska återskapas. Azure VMware Solution placeringsprinciper upprätthåller affinitet mellan virtuella datorer och värdar, vilket är viktigt vid licensbegränsningar som SQL Server och för strikta prestandakrav.
Sekvens efter risk: Börja med arbetsbelastningar med lägre risk, till exempel icke-produktionssystem eller program med få beroenden. Ditt team skapar förtroende för processen innan den tar sig an affärskritiska program. Övergå till arbetsbelastningar med högre komplexitet allt eftersom upplevelsen växer.
Anpassa efter planer för nätverksutbyggnad: Basera sekvensen på layouten för ditt lokala nätverk. När flera program delar ett nätverkssegment migrerar du dem i samma våg eller i efterföljande vågor. Du kan sedan snabbt flytta över segmentet till ett Azure VMware Solution-internt nätverk och ta bort den tillfälliga utökningen.

1.6 Migreringsverktyg

Använd VMware HCX för att flytta arbetsbelastningar till Azure VMware Solution med minimala störningar. HCX Enterprise ingår utan extra kostnad och installeras som standard, vilket ger tillgång till funktioner som replikeringsassisterad vMotion och mobilitetsoptimerade nätverk. Du behöver inte använda HCX, och du kan också migrera fysiska arbetsbelastningar med hjälp av en migreringslösning från en partner.

1.6.1 Migreringsmetod

vMotion flyttar en arbetsbelastning under drift utan driftstopp, och på Generation 2 går den i allmänhet snabbare än bulkmetoder. Replikeringsassisterad migrering och massmigrering kan gå långsammare på Generation 2 i dag, så planera längre tidsfönster och schemalägg vågor därefter. Se designöverväganden för Azure VMware Solution generation 2 för privata moln.

1.6.2 Styrning av nätverkstillägg

Vissa team betraktar nätverksutökning som en permanent lösning. Det är det inte. Håll tilläggen öppna endast för migreringsfönstret. HCX-nätverkstillägget sträcker ut ett lokalt nätverk till Azure VMware Solution på Layer 2, vilket gör att arbetsbelastningar kan behålla sina befintliga adresser under flytten. Den här designen undviker att konfigurera om program i förväg, och det medför kompromisser som en beslutsfattare måste styra.

Lokalt beroende. Ett utökat nätverk behåller vanligtvis sin gateway lokalt, så arbetsbelastningen är fortfarande beroende av källplatsen när den flyttas.
Ineffektiv routning. Trafik kan gå tillbaka till lokala miljöer och sedan tillbaka igen, ett mönster som kallas tromboning och som ökar latensen och antalet felpunkter.

Sätt en tydlig policy. Utöka bara ett nätverk när en arbetsbelastning inte kan ändra sin adress och ta bort varje tillägg när arbetsbelastningarna har flyttats. Utvärdera ditt lokala nätverk först så att du vet vilka segment som behöver tillägg och hur länge. Den bedömningen ligger till grund för både din utrullningsplan och tidsplanen för din utökning. Mobility Optimized Networking kan minska tromboning i vissa fall, så kontrollera vilka konfigurationer som stöds innan du aktiverar funktionen. Se Konfigurera HCX-nätverkstillägg.

2. Förberedelse av migrering

Följande distributionssekvens återspeglar beroendena mellan faserna. Varje steg förutsätter att föregående steg är slutfört och verifierat.

Plattformslandningszon: Se till att alla nödvändiga centraliserade nätverk, identitets-, säkerhets- och övervakningstjänster är redo att integreras med Azure VMware-arbetsbelastningar. Tillämpa styrnings- och säkerhetsbaslinjer via Azure Policy på din hanteringsgruppshierarki som hjälper dig att uppnå dina efterlevnadskrav. Generation 2 distribueras till ditt virtuella nätverk, så en principbaslinje som tillämpar strikta regler för nätverkssäkerhetsgrupper eller routningstabeller kan blockera distributionen. Ta bort dessa specifika principer från det privata molnets virtuella nätverk innan du distribuerar och tillämpa dem sedan igen efteråt. Planera det här undantaget i baslinjen så att styrningen inte stoppar distributionen.
Landningszoner för arbetslaster: Placera dina landningszoner för arbetslaster (abonnemang) under rätt hanteringsgrupp, onlinebaserade eller interna ("Corp").
IP-adressintervall: Reservera ett minsta /22-adressblock för det privata molnet. I generation 2, reservera även ytterligare två /24-block för HCX-hantering och upplänk. Bekräfta att inget av dessa intervall överlappar ditt lokala, Azure eller något annat molnadressutrymme. Du kan inte enkelt korrigera det här tillståndet efter driftsättning. Se designöverväganden för generation 2.
Kvotbegäran: Begär kvot tidigt eftersom allokeringen kan ta upp till fem arbetsdagar. Begär tillräckligt för framtida tillväxt och katastrofåterställning, till exempel N+1-redundans, vilket innebär en ytterligare värd utöver vad arbetslasten behöver. Bekräfta den portabla VMware Cloud Foundation-licensen som krävs för nya distributioner. Se Begär värdkvot.
Driftsättning av Azure VMware Solution-privatmoln: Distribuera Generation 2-privatmolnet i dess virtuella Azure-nätverk. Se Skapa ett privat moln i generation 2.
Nätverks- och identitetskonfiguration: Peer-koppla det privata molnnätverket till din hubb och upprätta en lokal anslutning. Anslut vCenter Server till din externa identitetskälla så att administratörer loggar in med hanterade konton i stället för delade inbyggda autentiseringsuppgifter.
Övervakning och hantering: Vidarebefordra loggar till din logghanteringslösning och konfigurera Service Health-aviseringar. Registrera virtuella gästdatorer via Azure Arc så att du kan styra dem med samma Azure verktyg som du använder någon annanstans.
HCX-installation: Installera HCX och testa plats-till-plats-anslutningen innan du startar den första vågen.

3. Migreringsgenomförande

Definiera vad "färdig" betyder före varje våg. En etapp är klar när arbetsbelastningen valideras, nätverksutökningen tas bort och applikationen fungerar korrekt i sitt permanenta läge.

Definiera kriterier för återställning före varje etapp och testa återställningsprocessen innan du migrerar produktionssystem. HCX stöder omvänd migrering och den exakta metoden beror på vilken migreringstyp du använde. Framgångskriterier för Wave omfattar:

Varje virtuell dator i vågen körs på Azure VMware Solution och är inte längre beroende av nätverkstillägg för produktionstrafik.
Alla program kan nås av sina användare och dess beroende system.
Varje virtuell dator visas i dina övervakningsverktyg utan varningar eller fel.
Återställning behövs inte längre och du kan formellt stänga den.
Programmets prestanda motsvarar eller överträffar baslinjen.
Arbetsbelastningarna uppfyller dina säkerhets- och efterlevnadskrav.
Arbetsbelastningen har framgångsrikt integrerats med lösningar för säkerhetskopiering och katastrofåterställning.

4. Utvärdering och avveckling av migrering

Migreringen upphör inte när arbetsbelastningar aktiveras i Azure VMware Solution. Kontrollera att arbetsbelastningarna fungerar korrekt i den nya miljön, bekräfta att tillfälliga migreringsboenden tas bort och formellt dra tillbaka källinfrastrukturen. Om du lämnar den lokala infrastrukturen på plats kan det leda till oupptäckta och odokumenterade beroenden. En disciplinerad utvärderings- och avvecklingsprocess säkerställer att organisationen inser de förväntade fördelarna med migreringen utan att medföra onödiga driftskostnader eller risker.

4.1 Produktionsberedskap efter cutover

Fastställ kriterier efter driftsättning som bekräftar att arbetsbelastningen fungerar som förväntat. Kontrollera nätverkstillgänglighet och namnupplösning. Kontrollera programfunktionen och kommunikationen med beroende system. När varje virtuell dator har flyttats bekräftar du att den startar, att dess resurser matchar planen och att rätt lagringsprincip gäller. Jämför prestanda med baslinjen före migreringen.

Bestäm din policy för paritet. Det viktigaste beslutet är om en migrerad arbetsbelastning måste nå full paritet med det lokala tillståndet innan du kallar den produktionsklar eller om du tillåter tillfälliga avvikelser. Många organisationer kräver omedelbar prestandaparitet för kundinriktade system men beviljar interna program en kort stabiliseringsperiod med en fast tidsgräns för reparation.

4.2 Anslutningsverifiering

Verifiera anslutning från ände till ände i Azure VMware Solution, Azure, lokala miljöer, internet och namnupplösning. Kör smoketester för programmet för att säkerställa att arbetsbelastningen fyller sitt syfte. Bekräfta huruvida externa namnposter eller lastbalanserarinställningar behöver uppdateras som en del av övergången.

Om du har skapat en sekundär instans av Azure VMware Solution för haveriberedskap kontrollerar du att den kan nås från både den primära instansen och från alla klienter eller stödtjänster som behöver ansluta till den om den är aktiverad.

4.3 Upplösning av nätverkstillägg

När alla arbetsbelastningar på ett utökat segment har flyttats, tar du bort HCX Layer 2-utökningen och bekräftar att den Azure VMware Solution-inbyggda gatewayen dirigerar trafiken korrekt. Lämna inte kvar ett tillägg längre än vad migreringen kräver.

4.4 Inaktivera källmiljö

När du avaktiverar frigörs formellt källkapacitet, licenser och drifttäckning. Behandla det som en styrd överlämning i stället för en rensningsaktivitet. Om du hoppar över avvecklingen betalar du för inaktiv infrastruktur och medför säkerhetsexponering. Använd Avveckla källarbetsbelastningar efter migrering till molnet för att ange i vilken ordning åtgärder ska utföras, lagringsperioden för säkerhetskopior från källmiljön, vilka godkännanden som krävs för att stänga av källsystemen och kriterierna för att återta licenser och hårdvara.

Nästa steg

Design av arbetsbelastning:

Feedback

Var den här sidan till hjälp?

Last updated on 2026-08-26