Migrering till App Service-miljön v3 med hjälp av migreringsfunktionen sida vid sida

Kommentar

Migreringsfunktionen som beskrivs i den här artikeln används för automatisk migrering sida vid sida (olika undernät) för App Service-miljön v2 till App Service-miljön v3. Om du inte har begärt en respitperiod på 30 dagar granskar du översikten över respitperioden och begär sedan en respitperiod genom att gå till Azure Portal och besöka migreringsbladet för var och en av dina App Service-miljön.

Om du letar efter information om migreringsfunktionen på plats kan du läsa Migrera till App Service-miljön v3 med hjälp av migreringsfunktionen på plats. Information om manuella migreringsalternativ finns i Manuella migreringsalternativ. Mer information om vilket migreringsalternativ som passar dig finns i Beslutsträd för migreringssökväg. Mer information om App Service-miljön v3 finns i översikten över App Service-miljön v3.

Migrering sida vid sida medför ytterligare utmaningar jämfört med migrering på plats. För kunder som behöver välja mellan de två alternativen är rekommendationen att använda migrering på plats eftersom det finns färre steg och mindre komplexitet. Om du bestämmer dig för att använda migrering sida vid sida granskar du vanliga problemkällor när du migrerar med hjälp av avsnittet med migreringsfunktioner sida vid sida för att undvika vanliga fallgropar.

App Service kan automatisera migreringen av din App Service-miljön v1 och v2 till en App Service-miljön v3. Det finns olika migreringsalternativ. Granska beslutsträdet för migreringssökvägen för att avgöra vilket alternativ som är bäst för ditt användningsfall. App Service-miljön v3 ger fördelar och funktionsskillnader jämfört med tidigare versioner. Se till att granska funktionerna i App Service-miljön v3 innan du migrerar för att minska risken för ett oväntat programproblem.

Migreringsfunktionen sida vid sida automatiserar migreringen till App Service-miljön v3. Migreringsfunktionen sida vid sida skapar en ny App Service-miljön v3 med alla dina appar i ett annat undernät. Din befintliga App Service-miljön tas inte bort förrän du initierar borttagningen i slutet av migreringsprocessen. Det här migreringsalternativet passar bäst för kunder som vill migrera till App Service-miljön v3 utan driftavbrott och som har stöd för att använda ett annat undernät för sin nya miljö. Om du behöver använda samma undernät och har stöd för ungefär en timmes programavbrott kan du läsa migreringsfunktionen på plats. Manuella migreringsalternativ som gör att du kan migrera i din egen takt finns i manuella migreringsalternativ.

Viktigt!

Om du inte kan slutföra alla steg som beskrivs i den här självstudien får du driftstopp. Om du till exempel inte uppdaterar alla beroende resurser med de nya IP-adresserna eller om du inte tillåter åtkomst till/från ditt nya undernät, till exempel fallet med nyckelvalvet för det anpassade domänsuffixet, får du avbrott tills det åtgärdas.

Vi rekommenderar att du använder den här funktionen för utvecklingsmiljöer först innan du migrerar några produktionsmiljöer för att repetera processen och se till att det inte finns några oväntade problem. Ge feedback om den här artikeln eller funktionen med hjälp av knapparna längst ned på sidan.

Stödda scenarier

För närvarande stöder inte migreringsfunktionen sida vid sida migreringar till App Service-miljön v3 i följande regioner:

Azure Public

• Förenade Arabemiraten, centrala

Azure Government

• US DoD, centrala
• US DoD, östra
• US Gov, Arizona
• US Gov, Texas
• US Gov, Virginia

Microsoft Azure drivs av 21Vianet

• Östra Kina 2
• Norra Kina 2

Följande App Service-miljön konfigurationer kan migreras med hjälp av migreringsfunktionen sida vid sida. Tabellen ger App Service-miljön v3-konfiguration när du använder migreringsfunktionen sida vid sida baserat på din befintliga App Service-miljön.

Konfiguration	App Service-miljön v3-konfiguration
Intern lastbalanserare (ILB) App Service-miljön v2	ILB App Service-miljön v3
Extern (ELB/internetuppkopplad med offentlig IP)-App Service-miljön v2	ELB App Service-miljön v3
ILB App Service-miljön v2 med ett anpassat domänsuffix	ILB App Service-miljön v3 med ett anpassat domänsuffix

App Service-miljön v3 kan distribueras som zonredundant. Zonredundans kan aktiveras så länge din App Service-miljön v3 finns i en region som stöder zonredundans.

Om du vill att din nya App Service-miljön v3 ska använda ett anpassat domänsuffix och du inte använder ett för närvarande kan anpassat domänsuffix konfigureras när som helst när migreringen är klar. Mer information finns i Konfigurera anpassat domänsuffix för App Service-miljön. Om din befintliga miljö har ett anpassat domänsuffix och du inte längre vill använda den måste du konfigurera ett anpassat domänsuffix för migreringen. Du kan ta bort det anpassade domänsuffixet när migreringen är klar.

Funktionsbegränsningar för migrering sida vid sida

Följande är begränsningar när du använder migreringsfunktionen sida vid sida:

• Din nya App Service-miljön v3 finns i ett annat undernät men samma virtuella nätverk som din befintliga miljö.
• Du kan inte ändra regionen som App Service-miljön finns i.
• ELB App Service-miljön kan inte migreras till ILB App Service-miljö v3 och vice versa.
• Om din befintliga App Service-miljö använder ett anpassat domänsuffix måste du konfigurera ett anpassat domänsuffix för App Service-miljön v3 under migreringsprocessen.
  • Om du inte längre vill använda ett anpassat domänsuffix tar du bort det när migreringen är klar.
• Migreringsfunktionen sida vid sida är endast tillgänglig med hjälp av CLI eller via REST API. Funktionen är inte tillgänglig i Azure Portal.

App Service-miljön v3 stöder inte följande funktioner som du kanske använder med din aktuella App Service-miljön v2.

• Konfigurera en IP-baserad TLS/SSL-bindning till dina appar.
• Om de anpassade DNS-servrar du konfigurerat i ditt virtuella nätverk inte kan lösa ett angivet namn, kommer App Service-miljön v3 inte att försöka använda Azure DNS som reserv. För att säkerställa detta beteende bör du antingen ha en vidarebefordrare till en offentlig DNS inställd eller lägga till Azure DNS i din lista över anpassade DNS-servrar.

Migreringsfunktionen sida vid sida stöder inte följande scenarier. Se alternativen för manuell migrering om din App Service-miljön ingår i någon av dessa kategorier.

• App Service-miljön v1
  • Du hittar versionen av din App Service-miljön genom att gå till din App Service-miljön i Azure Portal och välja Konfiguration under Inställningar till vänster. Du kan också använda Azure Resource Explorer och granska värdet för kind egenskapen för din App Service-miljön.
  • Om du har en App Service-miljön v1 kan du migrera med hjälp av migreringsfunktionen på plats eller något av alternativen för manuell migrering.
• ELB App Service-miljön v2 med IP SSL-adresser
• Zonfäst App Service-miljön v2
• App Service-miljön med ett namn som inte uppfyller teckengränserna. Hela namnet, inklusive domänsuffixet, måste vara 64 tecken eller färre. Till exempel: my-ase-name.appserviceenvironment.net för ILB och my-ase-name.p.azurewebsites.net för ELB måste vara 64 tecken eller färre. Om du inte uppfyller teckengränsen måste du migrera manuellt. Teckenbegränsningarna specifikt för App Service-miljön namn är följande:
  • ILB App Service-miljön namnteckengräns: 36 tecken
  • ELB App Service-miljön namnteckengräns: 42 tecken

App Service-plattformen granskar din App Service-miljön för att bekräfta stöd för migrering sida vid sida. Om ditt scenario inte klarar alla valideringskontroller kan du inte migrera just nu med hjälp av migreringsfunktionen sida vid sida. Om din miljö är i ett felfritt eller pausat tillstånd kan du inte migrera förrän du gör de nödvändiga uppdateringarna.

Kommentar

App Service-miljön v3 stöder inte IP SSL. Om du använder IP SSL måste du ta bort alla IP SSL-bindningar innan du migrerar till App Service-miljön v3. Migreringsfunktionen stöder din miljö när alla IP SSL-bindningar har tagits bort.

Felsökning

Om din App Service-miljön inte klarar verifieringskontrollerna eller om du försöker utföra ett migreringssteg i fel ordning visas något av följande felmeddelanden:

Felmeddelande	beskrivning	Rekommendation
Migrering kan bara anropas på en ASE i ARM VNET och denna ASE finns i klassiskt VNET.	App Service-miljön i klassiska virtuella nätverk kan inte migreras med hjälp av migreringsfunktionen sida vid sida.	Migrera med något av alternativen för manuell migrering.
ASEv3-migreringen är ännu inte klar.	Den underliggande infrastrukturen är inte redo att stödja App Service-miljön v3.	Migrera med något av alternativen för manuell migrering om du vill migrera direkt. Annars väntar du på att migreringsfunktionen sida vid sida ska vara tillgänglig i din region.
Det går inte att aktivera zonredundans för denna ASE.	Den region som App Service-miljön finns i stöder inte zonredundans.	Om du behöver aktivera zonredundans använder du något av alternativen för manuell migrering för att migrera till en region som stöder zonredundans.
Migrering kan inte anropas för det här anpassade DNS-suffixet ASE just nu.	Migrering av anpassat domänsuffix blockeras.	Öppna ett supportärende för att kontakta supporten för att lösa problemet.
Zonredundant ASE-migrering kan inte anropas just nu.	Zonredundant App Service-miljön migrering blockeras.	Öppna ett supportärende för att kontakta supporten för att lösa problemet.
Migrering kan inte anropas på ASEv2 som är zonfäst.	App Service-miljön v2 som är zonansluten kan inte migreras med hjälp av migreringsfunktionen sida vid sida för tillfället.	Migrera med något av alternativen för manuell migrering om du vill migrera direkt.
Befintlig återställningsmigrering pågår. Försök igen senare.	Ett tidigare migreringsförsök återställs.	Vänta tills återställningen som pågår slutförs innan du försöker starta migreringen igen.
Properties.VirtualNetwork.Id ska innehålla resurs-ID:t för undernätet.	Felet visas om du försöker migrera utan att ange ett nytt undernät för placeringen av din App Service-miljön v3.	Se till att du följer vägledningen och slutför steget för att identifiera det undernät som du ska använda för din App Service-miljön v3.
Det går inte att flytta till <requested phase> från den aktuella fasen <previous phase> av migrering utan stilleståndstid.	Det här felet visas om du försöker utföra ett migreringssteg i fel ordning.	Se till att du följer migreringsstegen i ordning.
Det gick inte att starta återställningsåtgärden på ASE i hybridtillstånd. Försök igen senare.	Det här felet visas om du försöker återställa migreringen men något går fel. Det här felet påverkar inte din gamla eller nya miljö.	Öppna ett supportärende för att kontakta supporten för att lösa problemet.
Detta ASE kan inte migreras utan driftstopp.	Det här felet visas om du försöker använda migreringsfunktionen sida vid sida på en App Service-miljön v1.	Migreringsfunktionen sida vid sida stöder inte App Service-miljön v1. Migrera med hjälp av migreringsfunktionen på plats eller något av alternativen för manuell migrering.
Migrering är inte tillgängligt för den här prenumerationen.	Stöd måste användas för att migrera den här App Service-miljön.	Öppna ett supportärende för att kontakta supporten för att lösa problemet.
Zonredundant migrering kan inte anropas eftersom IP-adresserna som skapades under förmigreringen inte är zonredundanta.	Det här felet visas om du försöker utföra en zonredundant migrering, men ip-adresserna som genererades under IP-generationssteget inte skapades som zonredundanta. Plattformen försöker göra alla IP-adresser zonredundanta för att säkerställa serverdelsåterhämtning.	Öppna ett supportärende för att kontakta supporten om du behöver aktivera zonredundans. Teknikerna återställer migreringen och tillåter ett nytt försök att skapa IP-adresserna. Annars kan du migrera utan att aktivera zonredundans.
Migrering kan inte anropas om IP SSL är aktiverat på någon av platserna.	App Service-miljön som har platser med IP SSL aktiverat kan inte migreras med hjälp av migreringsfunktionen sida vid sida.	Ta bort IP SSL från alla dina appar i App Service-miljön för att aktivera migreringsfunktionen.
Det går inte att migrera inom samma undernät.	Felet visas om du anger samma undernät som din aktuella miljö finns i för placering av din App Service-miljön v3.	Du måste ange ett annat undernät för din App Service-miljön v3. Om du behöver använda samma undernät migrerar du med hjälp av migreringsfunktionen på plats.
Prenumerationen har för många App Service-miljön. Ta bort några innan du försöker skapa mer.	Den App Service-miljön kvoten för din prenumeration uppfylls.	Ta bort onödiga miljöer eller kontakta supporten för att granska dina alternativ.
Migrering kan inte anropas på denna ASE förrän den aktiva uppgraderingen har slutförts.	App Service-miljön kan inte migreras under plattformsuppgraderingar. Du kan ange uppgraderingsinställningar från Azure-portalen. Uppgraderingar tar 8–12 timmar eller längre beroende på storleken (antalet instanser/kärnor) för App Service-miljön.	Vänta tills uppgraderingen är klar och migrera sedan.
App Service-miljön hanteringsåtgärd pågår.	Din App Service-miljön genomgår en hanteringsåtgärd. Dessa åtgärder kan omfatta aktiviteter som distributioner eller uppgraderingar. Migreringen blockeras tills dessa åtgärder har slutförts.	Du kan migrera när de här åtgärderna har slutförts.
InteralLoadBalancingMode stöds inte för närvarande.	App Service-miljön som har InternalLoadBalancingMode inställt på vissa värden kan inte migreras med hjälp av migreringsfunktionen just nu. Microsoft-teamet måste ändra InternalLoadBalancingMode manuellt.	Öppna ett supportärende för att kontakta supporten för att lösa problemet. Begär en uppdatering av InternalLoadBalancingMode.
Fullständig migrering kan inte anropas innan IP-adresser genereras.	Det här felet visas om du försöker migrera innan du slutför förmigreringsstegen.	Se till att du slutför alla förmigreringssteg innan du försöker migrera. Se steg för steg-guiden för migrering.
Fullständig migrering kan inte anropas på Ase med anpassat dns-suffix inställt, men utan en Konfigurerad anpassad AseV3-Suffixkonfiguration.	Din befintliga App Service-miljön använder ett anpassat domänsuffix. Du måste konfigurera anpassat domänsuffix för din App Service-miljön v3 under migreringsprocessen.	Konfigurera ett anpassat domänsuffix. Om du inte längre vill använda ett anpassat domänsuffix tar du bort det när migreringen är klar.

Översikt över migreringsprocessen med hjälp av migreringsfunktionen sida vid sida

Migrering sida vid sida består av en serie steg som måste följas i ordning. Viktiga punkter betonas för en delmängd av stegen. Det är viktigt att förstå processerna inom dessa steg samt hur de påverkar din omgivning och program. När du har granskat följande information och du är redo att migrera följer du den stegvisa guiden.

Kontrollera att migrering stöds med hjälp av migreringsfunktionen sida vid sida för din App Service-miljön

Plattformen verifierar att din App Service-miljön kan migreras med hjälp av migreringsfunktionen sida vid sida. Om din App Service-miljön inte klarar alla valideringskontroller kan du inte migrera just nu med hjälp av migreringsfunktionen sida vid sida. Mer information om möjliga orsaker till valideringsfel finns i felsökningsavsnittet. Om din miljö är i ett felfritt eller pausat tillstånd kan du inte migrera förrän du gör de nödvändiga uppdateringarna. Om du inte kan migrera med hjälp av migreringsfunktionen sida vid sida läser du alternativen för manuell migrering.

Valideringen kontrollerar också om din App Service-miljön är på den lägsta version som krävs för migrering. Den här versionen kan vara nyare än den standardversion som distribueras med den rutinmässiga plattformsuppgraderings-/underhållscykeln. Den minsta versionen uppdateras regelbundet för att säkerställa att de senaste felkorrigeringarna och förbättringarna är tillgängliga. Om din App Service-miljön inte är på lägsta version måste du starta uppgraderingen själv. Den här uppgraderingen är en standardprocess där din App Service-miljön inte påverkas, men du kan inte skala eller göra ändringar i App Service-miljön medan uppgraderingen pågår. Du kan inte migrera förrän uppgraderingen har slutförts. Uppgraderingar kan ta 8–12 timmar att slutföra eller längre beroende på miljöns storlek. Om du planerar ett visst tidsfönster för migreringen bör du köra verifieringskontrollen 24–48 timmar före den planerade migreringstiden för att säkerställa att du har tid för en uppgradering om det behövs.

Välj och förbered undernätet för din nya App Service-miljön v3

Plattformen skapar din nya App Service-miljön v3 i ett annat undernät än din befintliga App Service-miljön. Du måste välja ett undernät som uppfyller följande krav:

• Undernätet måste finnas i samma virtuella nätverk och därmed region som din befintliga App Service-miljön.
  • Om ditt virtuella nätverk inte har något tillgängligt undernät måste du skapa ett. Du kan behöva öka adressutrymmet för ditt virtuella nätverk för att skapa ett nytt undernät. Mer information finns i Skapa ett virtuellt nätverk.
• Undernätet måste kunna kommunicera i båda riktningarna med det undernät som din befintliga App Service-miljön är i. Se till att det inte finns nätverkssäkerhetsgrupper eller andra nätverkskonfigurationer som förhindrar kommunikation mellan undernäten.
• Undernätet måste ha en enda delegering av Microsoft.Web/hostingEnvironments.
• Undernätet måste ha tillräckligt med tillgängliga IP-adresser för att stödja din nya App Service-miljön v3. Antalet IP-adresser som behövs beror på hur många instanser du vill använda för din nya App Service-miljön v3. Mer information finns i Nätverk för App Service-miljö V3.
• Undernätet får inte ha några lås på sig. Om det finns lås måste de tas bort före migreringen. Låsen kan läsas om det behövs när migreringen är klar. Mer information om lås och lås arv finns i Lås dina resurser för att skydda infrastrukturen.
• Det får inte finnas några Azure-principer som blockerar migrering eller relaterade åtgärder. Om det finns principer som blockerar skapandet av App Service-miljön eller ändring av undernät måste de tas bort före migreringen. Principerna kan läsas om det behövs när migreringen är klar. Mer information om Azure Policy finns i Översikt över Azure Policy.

Generera utgående IP-adresser för din nya App Service-miljön v3

Plattformen skapar de nya utgående IP-adresserna. Under tiden som dessa IP-adresser skapas avbryts inga aktiviteter i din befintliga App Service-miljö, men det går inte att skala eller göra ändringar i den befintliga miljön. Den här processen tar cirka 15 minuter.

När det är klart skapas de nya utgående IP-adresser som din framtida App Service-miljön v3 använder. Dessa nya IP-adresser påverkar inte din befintliga miljö.

Du får den nya inkommande IP-adressen när migreringen är klar, men innan du gör DNS-ändringen för att omdirigera kundtrafik till din nya App Service-miljön v3. Du får inte den inkommande IP-adressen just nu i processen eftersom det finns beroenden för App Service-miljön v3-resurser som skapas under migreringssteget. Du har möjlighet att uppdatera alla resurser som är beroende av den nya inkommande IP-adressen innan du omdirigerar trafik till din nya App Service-miljön v3.

Uppdatera beroende resurser med nya utgående IP-adresser

De nya utgående IP-adresserna skapas och ges till dig innan du påbörjar den faktiska migreringen. Den nya standardutgående till internets offentliga adresser ges så att du kan justera eventuella externa brandväggar, DNS-routning, nätverkssäkerhetsgrupper och andra resurser som förlitar sig på dessa IP-adresser innan du slutför migreringen. Det är ditt ansvar att uppdatera alla resurser som påverkas av DEN IP-adressändring som är associerad med den nya App Service-miljön v3. Gå inte vidare till nästa steg förrän du har gjort alla nödvändiga uppdateringar. Du kan uppleva stilleståndstid under och efter migreringssteget om du har beroenden på de utgående IP-adresserna och inte kan göra alla nödvändiga uppdateringar. Detta beror på att när migreringen startar, även om trafiken fortfarande går till din App Service-miljön v2-klientdelar, är din underliggande beräkning din nya App Service-miljön v3 i det nya undernätet.

Det här steget är också ett bra tillfälle att granska ändringarna av inkommande och utgående nätverksberoende när du flyttar till App Service-miljön v3, inklusive portändringen för Azure Load Balancer-hälsoavsökningen, som nu använder port 80.

Delegera ditt App Service-miljön undernät

App Service-miljön v3 kräver att det undernät som det finns i har en enda delegering av Microsoft.Web/hostingEnvironments. Migreringen kan inte lyckas om App Service-miljön undernät inte delegeras eller om du delegerar det till en annan resurs. Kontrollera att det undernät som du väljer för din nya App Service-miljön v3 har en enda delegering av Microsoft.Web/hostingEnvironments.

Bekräfta ändringar i instansstorleken

Dina App Service-planer skapas med motsvarande isolerad v2 SKU som en del av migreringen. Till exempel motsvarar I2-planer I2v2. Dina appar kan vara överetablerade efter migreringen eftersom nivån Isolerad v2 har mer minne och processor per motsvarande instansstorlek. Du har möjlighet att skala din miljö efter behov när migreringen är klar. Mer information finns i SKU-informationen.

Kontrollera att det inte finns några lås på dina resurser

Virtuellt nätverk låser blockplattformsåtgärder under migreringen. Om det virtuella nätverket har lås måste du ta bort dem innan du migrerar. Låsen kan läsas om det behövs när migreringen är klar. Lås kan finnas i tre olika omfång: prenumeration, resursgrupp och resurs. När du använder ett lås i ett överordnat omfång ärver alla resurser inom det omfånget samma lås. Om du har lås som tillämpas på prenumerationen, resursgruppen eller resursomfånget måste de tas bort före migreringen. Mer information om lås och lås arv finns i Lås dina resurser för att skydda infrastrukturen.

Se till att det inte finns några Azure-principer som blockerar migrering

Azure Policy kan användas för att neka resursskapande och ändring av vissa huvudkonton. Om du har en princip som blockerar skapandet av App Service-miljön eller ändring av undernät måste du ta bort den innan du migrerar. Principen kan läsas om det behövs när migreringen är klar. Mer information om Azure Policy finns i Översikt över Azure Policy.

Lägga till ett anpassat domänsuffix (valfritt)

Om din befintliga App Service-miljön använder ett anpassat domänsuffix måste du konfigurera ett anpassat domänsuffix för din nya App Service-miljön v3. Suffix för anpassad domän på App Service-miljön v3 implementeras på ett annat sätt än på App Service-miljön v2. Du måste ange det anpassade domännamnet, den hanterade identiteten och certifikatet, som måste lagras i Azure Key Vault. Mer information om App Service-miljön suffix för anpassad v3-domän, inklusive krav, stegvisa instruktioner och metodtips finns i Konfigurera anpassat domänsuffix för App Service-miljön. Om din App Service-miljön v2 har ett anpassat domänsuffix måste du konfigurera ett anpassat domänsuffix för den nya miljön även om du inte längre vill använda det. När migreringen är klar kan du ta bort suffixkonfigurationen för anpassad domän om det behövs.

Om din migrering innehåller ett anpassat domänsuffix för App Service-miljön v3 visas inte den anpassade domänen i avsnittet Essentials på sidan Översikt i portalen som den är för App Service-miljön v1/v2. För App Service-miljön v3 går du i stället till sidan Suffix för anpassad domän där du kan bekräfta att ditt anpassade domänsuffix har konfigurerats korrekt. På App Service-miljön v2, om du har ett anpassat domänsuffix, innehåller standardvärdnamnet ditt anpassade domänsuffix och finns i formuläret APP-NAME.internal.contoso.com. På App Service-miljön v3 använder standardvärdnamnet alltid standarddomänsuffixet och är i formuläret APP-NAME.ASE-NAME.appserviceenvironment.net. Den här skillnaden beror på att App Service-miljön v3 behåller standarddomänsuffixet när du lägger till ett anpassat domänsuffix. Med App Service-miljön v2 finns det bara ett enda domänsuffix.

Migrering till App Service-miljö v3

När du har slutfört föregående steg fortsätter du med migreringen så snart som möjligt.

Det finns ingen programavbrott under migreringen, men som i STEGET IP-generering kan du inte skala, ändra din befintliga App Service-miljön eller distribuera appar till den under den här processen.

Viktigt!

Eftersom skalning blockeras under migreringen bör du skala din miljö till önskad storlek innan du påbörjar migreringen. Om du har aktiverat automatisk skalning måste du vänta tills skalningshändelsen har slutförts innan du påbörjar migreringen om en skalningshändelse inträffar innan migreringen påbörjas. Du bör inaktivera automatisk skalning innan du påbörjar migreringen för att undvika det här problemet. Om du behöver skala din miljö efter migreringen kan du göra det när migreringen är klar.

Det här steget är också där du bestämmer om du vill aktivera zonredundans för din nya App Service-miljön v3. Zonredundans kan aktiveras så länge din App Service-miljön v3 finns i en region som stöder zonredundans.

Sida vid sida-migrering kräver ett tjänstfönster på tre till sex timmar för App Service-miljön v2 till v3-migreringar. Under migreringen blockeras skalnings- och miljökonfigurationer och följande händelser inträffar:

• Den nya App Service-miljön v3 skapas i det undernät som du har valt.
• Dina nya App Service-planer skapas i den nya App Service-miljön v3 med motsvarande isolerad v2-nivå.
• Dina appar skapas i den nya App Service-miljön v3.
• Underliggande beräkning/arbetare för dina appar flyttas till den nya App Service-miljön v3, vilket innebär att dina appar nu körs på din App Service-miljön v3. Men dina App Service-miljön v2-klientdelar körs som standard fortfarande och betjänar trafik. Din gamla inkommande IP-adress används fortfarande, men dina nya utgående IP-adresser används. Dessutom skapas dina nya App Service-miljön v3-klientdelar och är redo att hantera trafik.
  • För ILB-App Service-miljön används inte dina App Service-miljön v3-klientdelar förrän du uppdaterar dina privata DNS-zoner med den nya inkommande IP-adressen.
  • För ELB-App Service-miljön omdirigerar migreringsprocessen inte trafik till App Service-miljön v3-klientdelar förrän du har slutfört det sista steget i migreringen.

När det här steget är klart går programtrafiken fortfarande till dina gamla App Service-miljön v2-klientdelar och den inkommande IP-adress som tilldelades den. Men dina appar körs faktiskt på arbetare i din nya App Service-miljön v3.

Kommentar

På grund av en känd bugg kanske webbjobb inte startar under hybriddistributionssteget. Om du använder webbjobb kan den här buggen orsaka appproblem/driftstopp. Öppna ett supportärende om du har några frågor eller problem med det här problemet.

Hämta den inkommande IP-adressen för din nya App Service-miljön v3 och uppdatera beroende resurser

Den nya inkommande IP-adressen ges så att du kan konfigurera nya slutpunkter med tjänster som Traffic Manager eller Azure Front Door och uppdatera någon av dina privata DNS-zoner. Gå inte vidare till nästa steg förrän du gör dessa ändringar. Det finns stilleståndstid om du inte uppdaterar beroende resurser med den nya inkommande IP-adressen. Det är ditt ansvar att uppdatera alla resurser som påverkas av den IP-adressändring som är associerad med den nya App Service-miljön v3. Gå inte vidare till nästa steg förrän du har gjort alla nödvändiga uppdateringar.

Omdirigera kundtrafik, verifiera din App Service-miljön v3 och slutför migreringen

Det sista steget är att omdirigera trafik till dina nya App Service-miljön v3-klientdelar och slutföra migreringen. Innan du gör det här steget bör du granska din nya App Service-miljön v3 och utföra alla nödvändiga tester för att verifiera att det fungerar som avsett. Som standard går trafiken till dina App Service-miljön v2-klientdelar. Om du använder en ILB-App Service-miljön v3 kan du testa dina App Service-miljön v3-klientdelar genom att uppdatera din privata DNS-zon med den nya inkommande IP-adressen. Om du använder en ELB-App Service-miljön v3 beror testprocessen på din specifika nätverkskonfiguration. En enkel metod att testa för ELB-miljöer är att uppdatera värdfilen så att den använder din nya inkommande IP-adress App Service-miljön v3. Om du har tilldelat anpassade domäner till dina enskilda appar kan du också uppdatera deras DNS så att de pekar på den nya inkommande IP-adressen. Genom att testa den här ändringen kan du verifiera din App Service-miljön v3 helt innan du påbörjar det sista steget i migreringen där din gamla App Service-miljön tas bort.

När du är redo att omdirigera trafik kan du slutföra det sista steget i migreringen. Det här steget uppdaterar interna/plattforms-DNS-poster så att de pekar på lastbalanserarens IP-adress för din nya App Service-miljön v3 och klientdelarna som skapades under migreringen. Ändringarna är effektiva inom några minuter. Det är ditt ansvar att uppdatera dns-posterna så att de pekar på den nya inkommande IP-adressen. Om du stöter på problem eller avbrott i programmet kontrollerar du cache- och TTL-inställningarna. Det här steget stänger också av din gamla App Service-miljön och tar bort den. Din nya App Service-miljön v3 är nu din produktionsmiljö.

Viktigt!

Plattformen garanterar en migrering utan avbrott. Dns-inställningarna kan dock orsaka avbrott under DNS-ändringssteget. Detta kan bero på problem som rör TTL- och cacheinställningar eftersom trafiken fortfarande kan dirigeras till din gamla App Service-miljön efter DNS-ändringen. Du bör granska DNS-inställningarna och se till att du har en låg TTL och att DNS-providern stöder snabb spridning. Om du har en hög TTL kan det uppstå stilleståndstid under DNS-ändringssteget.

Kommentar

Det är viktigt att slutföra det här steget så snart som möjligt. När din App Service-miljön är i hybridtillståndet kan den inte ta emot plattformsuppgraderingar och säkerhetskorrigeringar, vilket gör den mer sårbar för instabilitet och säkerhetshot.

Du har 14 dagar på dig att slutföra det här steget. Efter 14 dagar slutför plattformen automatiskt migreringen och tar bort din gamla miljö. Om du behöver mer tid kan du öppna ett supportärende för att diskutera dina alternativ.

Om du upptäcker några problem med din nya App Service-miljön v3 kör du inte kommandot för att omdirigera kundtrafik. Det här kommandot initierar också borttagningen av din App Service-miljön v2. Kontakta supporten om du hittar ett problem.

Använda migreringsfunktionen sida vid sida

Förutsättningar

Se till att du förstår hur migrering till App Service-miljön v3 påverkar dina program. Granska migreringsprocessen i sin helhet för att förstå processens tidslinje och var och när du behöver engagera dig. Läs även vanliga frågor och svar, som kan besvara några av dina frågor.

Se till att det inte finns några lås i ditt virtuella nätverk, resursgrupper, resurser eller prenumeration. Låser blockplattformsåtgärder under migreringen.

Se till att inga Azure-principer blockerar åtgärder som krävs för migreringen, inklusive ändringar i undernätet och skapande av Azure App Service-resurser. Principer som blockerar resursändringar och skapanden kan orsaka att migreringen fastnar eller misslyckas.

Eftersom din App Service-miljön v3 finns i ett annat undernät i det virtuella nätverket måste du se till att du har ett tillgängligt undernät i det virtuella nätverket som uppfyller undernätskraven för App Service-miljön v3. Det undernät som du väljer måste också kunna kommunicera med det undernät som din befintliga App Service-miljön finns i. Se till att det inte finns något som blockerar kommunikationen mellan de två undernäten. Om du inte har ett tillgängligt undernät måste du skapa ett innan du migrerar. Att skapa ett nytt undernät kan innebära att du ökar adressutrymmet för det virtuella nätverket. Mer information finns i Skapa ett virtuellt nätverk och undernät.

Eftersom skalning blockeras under migreringen bör du skala din miljö till önskad storlek innan du påbörjar migreringen. Om du behöver skala din miljö efter migreringen kan du göra det när migreringen är klar. Om du har aktiverat automatisk skalning blockeras migreringen tills skalningshändelsen har slutförts om en skalningshändelse inträffar innan migreringen startar. Du bör inaktivera automatisk skalning innan du påbörjar migreringen för att undvika det här problemet.

Följ stegen som beskrivs här i ordning och enligt skrivning eftersom du gör Azure REST API-anrop. Vi rekommenderar att du använder Azure CLI för att göra dessa API-anrop. Information om andra metoder finns i Azure REST API-referens.

I den här guiden installerar du Azure CLI eller använder Azure Cloud Shell och använder ett Bash-gränssnitt.

Kommentar

Vi rekommenderar att du använder ett Bash-gränssnitt för att köra kommandona som anges i den här guiden. Kommandona kanske inte är kompatibla med PowerShell-konventioner och escape-tecken.

Viktigt!

Under migreringen kan Azure Portal visa felaktig information om dina App Service-miljön och dina appar. Gå inte till migreringsmiljön i Azure Portal eftersom migreringsfunktionen sida vid sida inte är tillgänglig där. Vi rekommenderar att du använder Azure CLI för att kontrollera statusen för migreringen. Kontakta supporten om du har frågor om status för migreringen eller dina appar.

1. Välj undernätet för din nya App Service-miljön v3

Välj ett undernät i din App Service-miljön v3 som uppfyller undernätskraven för App Service-miljön v3. Observera namnet på det undernät som du väljer. Det här undernätet måste skilja sig från det undernät som din befintliga App Service-miljön finns i.

2. Hämta ditt App Service-miljön-ID

Kör följande kommandon för att hämta ditt App Service-miljön-ID och lagra det som en miljövariabel. Ersätt platshållarna för namnet och resursgrupperna med dina värden för den App Service-miljön som du vill migrera. ASE_RGoch VNET_RG är samma om ditt virtuella nätverk och App Service-miljön finns i samma resursgrupp.

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)

3. Verifiera att migrering stöds

Följande kommando kontrollerar om din App Service-miljön stöds för migrering. Det här kommandot verifierar också att din App Service-miljön finns på den version som stöds för migrering. Om din App Service-miljön inte finns på den version som stöds måste du starta uppgraderingen själv. Mer information om uppgraderingen före migreringen finns i Verifiera att migrering stöds med hjälp av migreringsfunktionen sida vid sida för din App Service-miljön.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"

Om det inte finns några fel stöds migreringen och du kan fortsätta till nästa steg.

Om du behöver starta en uppgradering för att uppgradera din App Service-miljön till den version som stöds, vilket kan ta 8–12 timmar eller längre beroende på miljöns storlek, kör du följande kommando. Kör bara det här kommandot om du misslyckas med valideringssteget och du uppmanas att uppgradera din App Service-miljön.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"

4. Generera utgående IP-adresser för din nya App Service-miljön v3

Kör följande kommando för att skapa nya utgående IP-adresser. Det här steget tar cirka 15 minuter att slutföra. Skala inte eller gör ändringar i din befintliga App Service-miljön under den här tiden.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01"

Kör följande kommando för att kontrollera statusen för det här steget:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status

Om steget pågår får du statusen Migrating. När du har fått statusen Readykör du följande kommando för att visa dina nya utgående IP-adresser. Om du inte ser de nya IP-adresserna omedelbart väntar du några minuter och försöker igen.

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses

5. Uppdatera beroende resurser med nya utgående IP-adresser

Genom att använda de nya utgående IP-adresserna uppdaterar du någon av dina resurser eller nätverkskomponenter för att säkerställa att den nya miljön fungerar som den är avsedd efter att migreringen har startats. Det är ditt ansvar att göra nödvändiga uppdateringar. De nya utgående IP-adresserna används när App Service-miljön v3 skapas under migreringssteget. Om du till exempel har ett anpassat domänsuffix och ett Azure Key Vault och hanterar åtkomstbegränsningar med en brandvägg, måste du uppdatera Azure Key Vaults brandvägg för att tillåta antingen bara de nya utgående IP-adresserna eller hela det nya undernätet.

6. Delegera ditt App Service-miljön undernät

App Service-miljön v3 kräver att det undernät som det finns i har en enda delegering av Microsoft.Web/hostingEnvironments. Tidigare versioner krävde inte den här delegeringen. Du måste bekräfta att ditt undernät har delegerats korrekt och uppdatera delegeringen (om det behövs) innan du migrerar. Du kan uppdatera delegeringen antingen genom att köra följande kommando eller genom att gå till undernätet i Azure Portal.

az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments

7. Bekräfta att det inte finns några lås i det virtuella nätverket

Virtuellt nätverk låser blockplattformsåtgärder under migreringen. Om det virtuella nätverket har lås måste du ta bort dem innan du migrerar. Om det behövs kan du lägga till låsen igen när migreringen är klar.

Använd följande kommando för att kontrollera om det virtuella nätverket har några lås:

az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Ta bort alla befintliga lås med hjälp av följande kommando:

az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Relaterade kommandon för att kontrollera om din prenumeration eller resursgrupp har lås finns i Azure CLI-referensen för lås.

8. Förbered dina konfigurationer

Om din befintliga App Service-miljön använder ett anpassat domänsuffix måste du konfigurera ett för din nya App Service-miljön v3-resurs under migreringsprocessen. Migreringen misslyckas om du inte konfigurerar ett anpassat domänsuffix och använder ett för närvarande. Mer information om App Service-miljön anpassade v3-domänsuffix, inklusive krav, stegvisa instruktioner och metodtips finns i Suffix för anpassad domän för App Service-miljön.

Kommentar

Om du konfigurerar ett anpassat domänsuffix bör du när du lägger till nätverksbehörigheterna i ditt Azure-nyckelvalv se till att ditt nyckelvalv tillåter åtkomst från ditt App Service-miljön v3:s nya undernät. Om du kommer åt ditt nyckelvalv med en privat slutpunkt kontrollerar du att du har konfigurerat privat åtkomst korrekt med det nya undernätet. Du får avbrottstid om du inte ställer in den här åtkomsten korrekt före migreringen.

Du kan göra din nya App Service-miljön v3-zon redundant om din befintliga miljö finns i en region som stöder zonredundans. Zonredundans kan konfigureras genom att ställa in egenskapen på zoneRedundant true. Zonredundans är en valfri konfiguration. Den här konfigurationen kan bara ställas in när du skapar din nya App Service-miljön v3 och kan inte tas bort vid ett senare tillfälle.

Om du vill ange dessa konfigurationer, inklusive att identifiera det undernät som du valde tidigare, skapar du en fil med namnet parameters.json med följande information baserat på ditt scenario. Se till att använda det nya undernätet som du har valt för din nya App Service-miljön v3. Inkludera inte egenskaperna för ett anpassat domänsuffix om den här funktionen inte gäller för migreringen. Var uppmärksam på värdet för zoneRedundant egenskapen och ställ in den enligt ditt återhämtningskrav.

Om du migrerar utan ett anpassat domänsuffix använder du den här koden:

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>"
    }
}

Om du använder en användartilldelad hanterad identitet för din anpassade domänsuffixkonfiguration använder du den här koden:

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

Om du använder en systemtilldelad hanterad identitet för din anpassade domänsuffixkonfiguration använder du den här koden:

{
    "properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

9. Migrera till App Service-miljön v3 och kontrollera status

När du har slutfört alla föregående steg kan du starta migreringen. Se till att du förstår konsekvenserna av migreringen.

Det här steget tar tre till sex timmar att slutföra. Under den tiden finns det ingen programavbrottstid om du har följt föregående steg. Skalning, distributioner och ändringar av dina befintliga App Service-miljön blockeras under det här steget.

Kommentar

På grund av en känd bugg kanske webbjobb inte startar under hybriddistributionssteget. Om du använder webbjobb kan den här buggen orsaka appproblem/driftstopp. Öppna ett supportärende om du har några frågor eller problem med det här problemet.

Kör följande kommando för att starta migreringen:

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json

Kör följande kommando för att kontrollera statusen för migreringen:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

När du har fått statusen MigrationPendingDnsChangeär migreringen klar och du har en App Service-miljön v3-resurs. Dina appar körs nu i din nya miljö och i din gamla miljö.

Hämta information om den nya miljön genom att köra följande kommando:

az appservice ase show --name $ASE_NAME --resource-group $ASE_RG

Viktigt!

Under migreringen och under MigrationPendingDnsChange steget visar Azure Portal felaktig information om dina App Service-miljön och dina appar. Använd Azure CLI för att kontrollera statusen för migreringen. Kontakta supporten om du har frågor om status för migreringen eller dina appar.

Kommentar

Om din migrering innehåller ett anpassat domänsuffix kan din anpassade domänsuffixkonfiguration visas som degraderad när migreringen är klar på grund av en känd bugg. Din App Service-miljön bör fortfarande fungera som förväntat. Den degraderade statusen bör matcha sig själv inom 6–8 timmar. Om konfigurationen har degraderats efter 8 timmar eller om ditt anpassade domänsuffix inte fungerar kontaktar du supporten.

10. Hämta inkommande IP-adresser för dina nya App Service-miljön v3 och uppdatera beroende resurser

Du har två uppsättningar med App Service-miljön klientdelar i det här skedet i migreringsprocessen och båda uppsättningarna kan hantera programtrafik. Din DNS ändras inte, så som standard skickas trafik till den gamla App Service-miljön klientdelen. Du måste uppdatera alla beroende resurser för att använda den nya IP-inkommande adressen för din nya App Service-miljön v3. För interna motkopplade (ILB) App Service-miljön måste du uppdatera dina privata DNS-zoner så att de pekar på den nya inkommande IP-adressen.

Du kan hämta den nya inkommande IP-adressen för din nya App Service-miljön v3 genom att köra följande kommando som motsvarar din App Service-miljön lastbalanserare. Det är ditt ansvar att göra nödvändiga uppdateringar.

För ILB-App Service-miljön hämtar du den privata inkommande IP-adressen genom att köra följande kommando:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses

För ELB-App Service-miljön hämtar du den offentliga inkommande IP-adressen genom att köra följande kommando:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses

Viktigt!

Om migreringen innehåller ett anpassat domänsuffix är standardbeteendet för värdnamn för App Service-miljön v3 annorlunda än för App Service-miljön v2. För App Service-miljön v3 använder standardvärdnamnet alltid standarddomänsuffixet och är i formuläret APP-NAME.ASE-NAME.appserviceenvironment.net. Granska alla dina beroende resurser, till exempel App Gateway, som använder värdnamnen för dina appar för att säkerställa att de uppdateras för att ta hänsyn till det här beteendet. Mer information om App Service-miljön funktionsskillnader mellan de olika versionerna finns i App Service-miljön versionsjämförelse.

11. Omdirigera kundtrafik, verifiera din App Service-miljön v3 och slutför migreringen

Det här steget är din möjlighet att testa och verifiera din nya App Service-miljön v3.

Viktigt!

Du har 14 dagar på dig att slutföra det här steget. Efter 14 dagar slutför plattformen automatiskt migreringen och tar bort din gamla miljö. Om du behöver mer tid kan du öppna ett supportärende för att diskutera dina alternativ.

När du har bekräftat att dina appar fungerar som förväntat kan du slutföra migreringen genom att köra följande kommando. Det här kommandot tar också bort din gamla miljö.

Om du hittar några problem eller bestämmer dig för att du inte längre vill fortsätta med migreringen kontaktar du supporten för att diskutera dina alternativ. Kör inte DNS-ändringskommandot eftersom kommandot slutför migreringen.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"

Kör följande kommando för att kontrollera statusen för det här steget:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

Under det här steget får du statusen CompletingMigration. När du får statusen utförs omdirigeringssteget MigrationCompletedför trafik och migreringen är klar.

Vanliga problemkällor vid migrering med hjälp av migreringsfunktionen sida vid sida

Följande är exempel på vanliga problemkällor som kunder stöter på när de migrerar med hjälp av migreringsfunktionen sida vid sida. Du bör granska dessa områden för att säkerställa att du inte upplever avbrott i tjänsten under eller efter migreringen.

• Azure Key Vault bör tillåta trafik från nya utgående IP-adresser/undernät.
• De två undernäten ska kunna kommunicera med varandra i båda riktningarna. Kunder tillåter vanligtvis trafik från det gamla till det nya undernätet, men glömmer att tillåta trafik från det nya till det gamla undernätet.
• App Gateway bör uppdateras med de nya IP-adresserna.
• DNS-poster bör uppdateras med de nya IP-adresserna.
• Om du har hårdkodade IP-adresser i dina program måste du uppdatera dem med de nya IP-adresserna.
• Routningstabeller bör uppdateras med alla nya vägar.

Prissättning

Det kostar ingenting att migrera App Service-miljön. Du debiteras dock för både din App Service-miljön v2 och din nya App Service-miljön v3 när du startar migreringsprocessen. Du slutar att debiteras för din gamla App Service-miljön v2 när du slutför det sista migreringssteget där den gamla miljön tas bort. Du bör slutföra valideringen så snabbt som möjligt för att förhindra att överskjutande avgifter ackumuleras. För mer information om priser för App Service Environment v3, se Information om priser.

När du migrerar till App Service-miljön v3 från tidigare versioner finns det scenarier som du bör överväga som potentiellt kan minska din månadskostnad. Överväg reservationer och sparplaner för att ytterligare minska dina kostnader. Information om kostnadsbesparingsmöjligheter finns i Kostnadsbesparande affärsmöjligheter efter uppgradering till App Service-miljön v3.

Kommentar

På grund av skillnaderna mellan prisnivåerna Isolerad till Isolerad v2 kan dina appar vara överetablerade efter migreringen eftersom nivån Isolerad v2 har mer minne och PROCESSOR per motsvarande instansstorlek. Du har möjlighet att skala din miljö efter behov när migreringen är klar. Mer information finns i SKU-informationen.

Skala ned dina App Service-planer

App Service-plan-SKU:er som är tillgängliga för App Service-miljön v3 körs på nivån Isolerad v2 (Iv2). Antalet kärnor och mängden RAM-minne fördubblas effektivt per motsvarande nivå jämfört med den isolerade nivån. När du migrerar konverteras dina App Service-planer till motsvarande nivå. Dina I2-instanser konverteras till exempel till I2v2. Medan I2 har två kärnor och 7 GB RAM har I2v2 fyra kärnor och 16 GB RAM-minne. Om du förväntar dig att dina kapacitetskrav förblir desamma är du överetablerad och betalar för beräkning och minne som du inte använder. I det här scenariot kan du skala ned din I2v2-instans till I1v2 och sluta med ett liknande antal kärnor och RAM-minne som du hade tidigare.

Vanliga frågor och svar

• Vad händer om migrering av min App Service-miljön inte stöds för närvarande?
  Du kan inte migrera med hjälp av migreringsfunktionen sida vid sida just nu. Om du har en miljö som inte stöds och vill migrera omedelbart kan du läsa alternativen för manuell migrering.
• Hur gör jag för att välja vilket migreringsalternativ som passar mig bäst?
  Granska beslutsträdet för migreringssökvägen för att avgöra vilket alternativ som är bäst för ditt användningsfall.
• Hur gör jag för att vet om jag ska använda migreringsfunktionen sida vid sida?
  Migreringsfunktionen sida vid sida är bäst för kunder som vill migrera till App Service-miljön v3 men inte har stöd för programavbrott. Eftersom ett nytt undernät används för din nya miljö finns det nätverksöverväganden att tänka på, inklusive nya IP-adresser. Om du har stöd för stilleståndstid kan du läsa migreringsfunktionen på plats, vilket resulterar i minimala konfigurationsändringar eller manuella migreringsalternativ. Migreringsfunktionen på plats skapar din App Service-miljön v3 i samma undernät som din befintliga miljö och använder samma nätverksinfrastruktur.
• Kommer det att uppstå avbrott under migreringen?
  Plattformen garanterar att det inte finns någon stilleståndstid under migreringsprocessen sida vid sida. Dns-inställningarna kan dock orsaka avbrott under DNS-ändringssteget. Detta kan bero på problem som rör TTL- och cacheinställningar eftersom trafiken fortfarande kan dirigeras till din gamla App Service-miljön efter DNS-ändringen. Du bör granska DNS-inställningarna och se till att du har en låg TTL och att DNS-providern stöder snabb spridning.
• Kommer jag att behöva göra något med mina appar efter migreringen för att få dem att köras på den nya App Service-miljön?
  Nej, alla dina appar som körs i den gamla miljön migreras automatiskt till den nya miljön och kan köras som tidigare. Inga användarindata behövs.
• Vad händer om App Service-miljön har ett anpassat domänsuffix?
  Migreringsfunktionen sida vid sida stöder det här migreringsscenariot.
• Vad händer om min App Service-miljön är zonfäst?
  Migreringsfunktionen sida vid sida stöder inte det här migreringsscenariot just nu. Om du har en zon fäst App Service-miljön och vill migrera omedelbart läser du alternativen för manuell migrering.
• Vad händer om min App Service-miljön har IP SSL-adresser?
  IP SSL stöds inte på App Service-miljön v3. Du måste ta bort alla IP SSL-bindningar innan du migrerar med hjälp av migreringsfunktionen eller något av de manuella alternativen. Om du tänker använda migreringsfunktionen sida vid sida, när du tar bort alla IP SSL-bindningar, klarar du verifieringskontrollen och kan fortsätta med den automatiserade migreringen.
• Vilka egenskaper för min App Service-miljön ändras?
  Du är på App Service-miljön v3 så se till att granska funktionerna och funktionsskillnaderna jämfört med tidigare versioner. Både dina inkommande och utgående IP-adresser ändras när du använder migreringsfunktionen sida vid sida. Obs! För ELB-App Service-miljöer fanns det tidigare en enda IP-adress som användes som både inkommande och utgående. För App Service-miljön v3 används separata adresser. Mer information finns i Nätverk för App Service-miljö V3. En fullständig jämförelse av olika versioner av App Service-miljön finns i Versionsjämförelse för App Service-miljön.
• Vad händer om migreringen misslyckas eller om det uppstår ett oväntat problem under migreringen?
  Om det uppstår ett oväntat problem finns supportteam på plats. Vi rekommenderar att du migrerar utvecklingsmiljöer innan du rör vid några produktionsmiljöer för att lära dig mer om migreringsprocessen och se hur den påverkar dina arbetsbelastningar.
• Vad händer med min gamla App Service-miljön?
  Om du bestämmer dig för att migrera en App Service-miljön med hjälp av migreringsfunktionen sida vid sida används den gamla miljön fram till det sista steget i migreringsprocessen. När du har slutfört det sista steget kommer den gamla miljön och alla appar som finns på den att stängas av och tas bort. Din gamla miljö är inte längre tillgänglig. Det går inte att återgå till den gamla miljön just nu.
• Vad händer med resurser i App Service-miljön v1/v2 efter den 31 augusti 2024?
  Om du inte migrerar till App Service-miljön v3 efter den 31 augusti 2024 är dina App Service-miljön v1/v2s och apparna som distribueras i dem inte längre tillgängliga. App Service-miljön v1/v2 finns på App Service-skalningsenheter som körs på Cloud Services-arkitektur (klassisk) som kommer att tas ur bruk den 31 augusti 2024. Därför kommer App Service-miljön v1/v2 inte längre vara tillgänglig efter det datumet. För att säkerställa att dina appar fortsätter att fungera, bör du migrera till App Service-miljön v3. Se även till att spara eller ta säkerhetskopior av resurser och data som du vill bevara.

Nästa steg

App Service-miljön v3-nätverk

Använda en App Service-miljön v3

Suffix för anpassad domän