Dela via

Migrera en VNet-inmatad API Management-instans som finns på stv1-plattformen till stv2

  • Artikel

GÄLLER FÖR: Utvecklare | Premie

Den här artikeln innehåller steg för att migrera en API Management-instans som finns på beräkningsplattformen stv1 stv2 på plats till plattformen när instansen matas in (distribueras) i ett externt eller internt virtuellt nätverk. Ta reda på om du behöver göra detta.

Kommentar

Nytt i augusti 2024: För att hjälpa dig att migrera din VNet-inmatade instans har vi förbättrat migreringsalternativen i portalen! Nu kan du migrera din instans på plats och behålla samma undernät och IP-adress.

För en VNet-instans har du följande migreringsalternativ:

  • Alternativ 1: Behåll samma undernät – Migrera instansen på plats och behåll instansernas befintliga undernätskonfiguration. Du kan välja om API Management-instansens ursprungliga VIP-adress bevaras (rekommenderas) eller om en ny VIP-adress ska genereras.

  • Alternativ 2: Ändra till ett nytt undernät – Migrera instansen genom att ange ett annat undernät i samma eller ett annat virtuellt nätverk. Efter migreringen kan du migrera tillbaka till instansens ursprungliga undernät. Migreringsprocessen ändrar VIP-adresserna för instansen. Efter migreringen måste du uppdatera eventuella nätverksberoenden, inklusive DNS, brandväggsregler och virtuella nätverk för att använda de nya VIP-adresserna.

Under vissa, mindre frekventa förhållanden kanske migrering i samma undernät inte är möjligt eller fungerar annorlunda. Mer information finns i Särskilda villkor och scenarier.

Om du behöver migrera en icke-VNet-inmatad API Management som finns på stv1 plattformen kan du läsa Migrera en instans av API Management som inte är VNet-inmatad till stv2-plattformen.

Viktigt!

Stöd för API Management-instanser som finns på stv1 plattformen dras tillbaka. I globala Azure är slutdatumet den 31 augusti 2024. I Azure Government och i Azure som drivs av 21Vianet (Azure i Kina) är slutdatumet den 24 februari 2025. Om du har instanser som finns på stv1 plattformen migrerar du dem till stv2 plattformen före slutdatumet för att undvika avbrott i tjänsten.

Varning

  • Att migrera DIN API Management-instans till stv2 plattformen är en tidskrävande åtgärd.
  • Migrering till stv2 är inte reversibel.

Vad händer under migreringen?

Api Management-plattformsmigrering från stv1 till innebär att stv2 enbart den underliggande beräkningen uppdateras och påverkar inte den tjänst-/API-konfiguration som finns kvar i lagringslagret.

  • Uppgraderingsprocessen innebär att du skapar en ny beräkning parallellt med den gamla beräkningen, vilket kan ta upp till 45 minuter. Planera längre tider för distributioner i flera regioner och i scenarier som innebär att ändra undernätet mer än en gång.
  • API Management-statusen i Azure Portal uppdateras.
  • För vissa migreringsalternativ kan du välja att bevara VIP-adressen eller så genereras en ny offentlig VIP.
  • För migreringsscenarier när en ny VIP-adress genereras:
    • Azure hanterar migreringen.
    • Gateway-DNS pekar fortfarande på den gamla beräkningen om en anpassad domän används.
    • Om anpassad DNS inte används pekar gatewayen och portalens DNS direkt på den nya beräkningen.
    • För en instans i internt VNet-läge hanterar kunden DNS, så DNS-posterna fortsätter att peka på gammal beräkning tills kunden har uppdaterat den.
    • Det är DNS som pekar på antingen den nya eller den gamla beräkningen och därmed ingen stilleståndstid för API:erna.
    • Ändringar krävs i eventuella brandväggsregler för att det nya beräkningsundernätet ska kunna nå serverdelarna.
    • Efter lyckad migrering inaktiveras den gamla beräkningen automatiskt efter en kort period. När du ändrar till ett nytt undernät med bladet Plattformsmigrering i portalen kan du aktivera en migreringsinställning för att behålla den gamla gatewayen i 48 timmar. Alternativet 48 timmars fördröjning är endast tillgängligt för VNet-inmatade tjänster.

Förutsättningar

Andra förutsättningar är specifika för migreringsalternativen i följande avsnitt.

Alternativ 1: Migrera och behåll samma undernät

Du kan migrera din API Management-instans till plattformen stv2 som behåller den befintliga undernätskonfigurationen, vilket förenklar migreringen. Du kan migrera med hjälp av bladet Plattformsmigrering i Azure Portal eller REST-API:et Migrera till Stv2.

Förutsättningar

  • En nätverkssäkerhetsgrupp måste kopplas till varje undernät och NSG-regler för API Management på stv2 plattformen måste konfigureras. Följande är lägsta anslutningsinställningar:

    • Utgående trafik till Azure Storage via port 443
    • Utgående trafik till Azure SQL via port 1433
    • Utgående trafik till Azure Key Vault via port 443
    • Inkommande trafik från Azure Load Balancer via port 6390
    • Inkommande från ApiManagement-tjänsttagg över port 3443
    • Inkommande trafik via port 80/443 för klienter som anropar API Management-tjänsten
    • Undernätet måste ha tjänstslutpunkter aktiverade för Azure Storage, Azure SQL och Azure Key Vault

  • Adressutrymmet för varje befintligt undernät måste vara tillräckligt stort för att vara värd för en kopia av din befintliga tjänst sida vid sida med din befintliga tjänst under migreringen.

  • Andra nätverksöverväganden:

    • Inaktivera alla autoskalningsregler som konfigurerats för API Management-instanser som distribuerats i undernätet. Regler för autoskalning kan störa migreringsprocessen.
    • Om du har flera API Management-instanser i samma undernät migrerar du varje instans i följd. Vi rekommenderar att du snabbt migrerar alla instanser i undernätet för att undvika eventuella problem med instanser som finns på olika plattformar i samma undernät.

Alternativ för offentlig IP-adress – migrering av samma undernät

Du kan välja om API Management-instansens ursprungliga VIP-adress bevaras (rekommenderas) eller om en ny VIP-adress ska genereras.

  • Bevara virtuell IP-adress – Om du bevarar VIP-adressen i ett virtuellt nätverk i externt läge kan API-begäranden förbli dynamiska under migreringen (se Förväntad stilleståndstid), för ett virtuellt nätverk i internt läge förväntas tillfällig stilleståndstid. Infrastrukturkonfiguration (till exempel anpassade domäner, platser och CA-certifikat) låses i 45 minuter. Ingen ytterligare konfiguration krävs efter migreringen.

    Med det här alternativet stv1 tas beräkningen bort permanent när migreringen är klar. Det finns inget alternativ för att behålla den tillfälligt.

    Följande bild visar en översikt på hög nivå över vad som händer när IP-adressen bevaras.

    Diagram över migrering på plats till samma undernät och bevarande av IP-adress.

  • Ny virtuell IP-adress – Om du väljer det här alternativet genererar API Management en ny VIP-adress för din instans. API-begäranden förblir dynamiska under migreringen. Infrastrukturkonfiguration (till exempel anpassade domäner, platser och CA-certifikat) låses i 30 minuter. Efter migreringen måste du uppdatera eventuella nätverksberoenden, inklusive DNS, brandväggsregler och virtuella nätverk för att använda den nya VIP-adressen.

    Med det här alternativet stv1 behålls beräkningen under en kort period som standard när migreringen är klar så att du kan verifiera den migrerade instansen och bekräfta nätverket och DNS-konfigurationen.

    Följande bild visar en översikt på hög nivå över vad som händer när en ny IP-adress genereras.

    Diagram över migrering på plats till samma undernät och generering av ny IP-adress.

Fördefinierad IP-adress för migrering

För API Management-instanser som kan nås av en offentlig IP-adress skapar API Management en offentlig IP-adress för migreringsprocessen. Hitta den förskapade IP-adressen i JSON-utdata för API Management-instansens egenskaper. Under customPropertiesär den förskapade IP-adressen värdet för Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps egenskapen. För en distribution i flera regioner är värdet en kommaavgränsad lista över förskapade IP-adresser.

Använd den förskapade IP-adressen (eller adresserna) för att hantera migreringsprocessen:

  • När du migrerar och bevarar VIP-adressen tilldelas den förskapade IP-adressen tillfälligt till den nya stv2 distributionen innan den ursprungliga IP-adressen tilldelas distributionen stv2 . Om du till exempel har brandväggsregler som begränsar åtkomsten till API Management-instansen kan du lägga till den förskapade IP-adressen i listan över tillåtna för att bevara kontinuiteten för klientåtkomst under migreringen. När migreringen är klar kan du ta bort den förskapade IP-adressen från listan över tillåtna adresser.
  • När du migrerar och genererar en ny VIP-adress tilldelas den förskapade IP-adressen till den nya stv2 distributionen under migreringen och bevaras när migreringen är klar. Använd den förskapade IP-adressen för att uppdatera dina nätverksberoenden, till exempel DNS och brandväggsregler, för att peka på den nya IP-adressen.

Förväntad stilleståndstid och beräkningskvarhållning

När du migrerar en VNet-inmatad instans och behåller samma undernätskonfiguration förväntas minimal eller ingen stilleståndstid för API-gatewayen. I följande tabell sammanfattas den förväntade stilleståndstiden och stv1 beräkningskvarhållningen för varje migreringsscenario när samma undernät behålls:

VNet-läge Offentligt IP-alternativ Förväntad stilleståndstid stv1 beräkningsbevarande
Externt Bevara VIP Ingen stilleståndstid; trafik hanteras på en tillfällig IP-adress i upp till 20 minuter under migreringen till den nya stv2 distributionen Ingen kvarhållning
Externt Ny VIP Ingen stilleståndstid Behålls som standard i 15 minuter så att du kan uppdatera nätverksberoenden
Internt Bevara VIP Stilleståndstid i cirka 20 minuter under migreringen medan den befintliga IP-adressen tilldelas till den nya stv2 distributionen. Ingen kvarhållning
Internt Ny VIP Ingen stilleståndstid Behålls som standard i 15 minuter så att du kan uppdatera nätverksberoenden. kan utökas till 48 timmar när du använder portalen

Migreringssteg – behåll samma undernät

  1. I Azure Portal navigerar du till din API Management-instans.
  2. I den vänstra menyn går du till Inställningar och väljer Plattformsmigrering.
  3. Under Välj ett migreringsalternativ väljer du Behåll samma undernät.
  4. Under Alternativet Välj en IP-adress väljer du något av de två IP-adressalternativen.

    Kommentar

    Om ditt virtuella nätverk är i externt läge noterar du den förskapade offentliga IP-adressen för migreringsprocessen. Använd den här adressen för att konfigurera nätverksanslutningen för din migrerade instans.

  5. (För instanser som matas in i internt läge och migreras till en ny VIP) Under Välj det scenario som överensstämmer med dina krav väljer du ett av de två alternativen, beroende på om du vill behålla den ursprungliga stv1 beräkningen under en period efter migreringen.
  6. Välj Verifiera för att köra automatiserade kontroller i undernätet. Om problem upptäcks justerar du konfigurationen av undernätet och kör kontrollerna igen. För andra nätverksberoenden, till exempel DNS och brandväggsregler, kontrollerar du manuellt.
  7. Bekräfta att du vill migrera och välj Starta migrering. Status för DIN API Management-instans ändras till Uppdatering. Migreringsprocessen tar cirka 45 minuter att slutföra. När statusen ändras till Online slutförs migreringen.

Alternativ 2: Migrera och ändra till nytt undernät

Med hjälp av Azure Portal kan du migrera instansen genom att ange ett annat undernät i samma eller ett annat virtuellt nätverk. Efter migreringen kan du migrera tillbaka till instansens ursprungliga undernät.

Följande bild visar en översikt på hög nivå över vad som händer under migreringen till ett nytt undernät.

Diagram över migrering på plats till ett nytt undernät.

Förutsättningar

  • Ett nytt undernät i det aktuella virtuella nätverket i varje region där API Management-instansen distribueras. (Du kan också konfigurera ett undernät i ett annat virtuellt nätverk i samma regioner och prenumeration som din API Management-instans). En nätverkssäkerhetsgrupp måste kopplas till varje undernät och NSG-regler för API Management på stv2 plattformen måste konfigureras.

  • (Valfritt) En ny offentlig IPv4-adressresurs för Standard SKU i samma region och prenumeration som din API Management-instans. Mer information finns i Krav för nätverksanslutningar.

Viktigt!

  • Från och med maj 2024 behövs inte längre en offentlig IP-adressresurs när du distribuerar (matar in) en API Management-instans i ett virtuellt nätverk i internt läge eller migrerar den interna VNet-konfigurationen till ett nytt undernät. I externt VNet-läge är det valfritt att ange en offentlig IP-adress. Om du inte anger en så konfigureras och används en Azure-hanterad offentlig IP-adress automatiskt för körnings-API-trafik. Ange endast den offentliga IP-adressen om du vill äga och kontrollera den offentliga IP-adress som används för inkommande eller utgående kommunikation till Internet.

Migreringssteg – ändra till ett nytt undernät

  1. I Azure Portal navigerar du till din API Management-instans.

  2. I den vänstra menyn går du till Inställningar och väljer Plattformsmigrering.

  3. Under Välj ett migreringsalternativ väljer du Ändra till ett nytt undernät.

  4. Under Välj det scenario som överensstämmer med dina krav väljer du ett av de två alternativen, beroende på om du vill behålla den ursprungliga stv1 beräkningen under en period efter migreringen.

    Skärmbild av alternativ för att behålla stv1-beräkning i portalen.

  5. Under Definiera migreringsinställningar för varje plats:

    1. Välj en plats som ska migreras.
    2. Välj det virtuella nätverk, undernät och valfria offentliga IP-adress som du vill migrera till.

    Skärmbild av hur du väljer inställningar för nätverksmigrering i portalen.

  6. Under Kontrollera att ditt undernät uppfyller migreringskraven väljer du Verifiera för att köra automatiserade kontroller på undernätet. Om problem upptäcks justerar du konfigurationen av undernätet och kör kontrollerna igen. För andra nätverksberoenden, till exempel DNS och brandväggsregler, kontrollerar du manuellt.

  7. Bekräfta att du vill migrera och välj Migrera. Status för DIN API Management-instans ändras till Uppdatering. Migreringsprocessen tar cirka 45 minuter att slutföra. När statusen ändras till Online slutförs migreringen.

Om DIN API Management-instans distribueras i flera regioner upprepar du föregående steg för att fortsätta migrera VNet-inställningar för de återstående platserna för din instans.

(Valfritt) Migrera tillbaka till det ursprungliga undernätet

Om du har migrerat och ändrat till ett nytt undernät kan du också migrera tillbaka till det ursprungliga undernätet som du använde i varje region. För att göra det uppdaterar du VNet-konfigurationen igen, den här gången anger du det ursprungliga virtuella nätverket och undernätet i varje region. Precis som i föregående migrering förväntar du dig en tidskrävande åtgärd och förväntar dig att VIP-adressen ändras.

Följande bild visar en översikt på hög nivå över vad som händer under migreringen tillbaka till det ursprungliga undernätet.

Diagram över migrering på plats tillbaka till det ursprungliga undernätet.

Viktigt!

Om det virtuella nätverket och undernätet är låsta (eftersom andra stv1 plattformsbaserade API Management-instanser distribueras där) eller resursgruppen där det ursprungliga virtuella nätverket distribueras har ett resurslås ska du ta bort låset innan du migrerar tillbaka till det ursprungliga undernätet. Vänta tills låsborttagningen har slutförts innan du försöker migrera till det ursprungliga undernätet. Läs mer.

Ytterligare förutsättningar

  • Det olåst ursprungliga undernätet i varje region där API Management-instansen distribueras. En nätverkssäkerhetsgrupp måste vara kopplad till undernätet och NSG-regler för API Management måste konfigureras.

  • (Valfritt) En ny offentlig IPv4-adressresurs för Standard SKU i samma region och prenumeration som din API Management-instans.

    Viktigt!

    • Från och med maj 2024 behövs inte längre en offentlig IP-adressresurs när du distribuerar (matar in) en API Management-instans i ett virtuellt nätverk i internt läge eller migrerar den interna VNet-konfigurationen till ett nytt undernät. I externt VNet-läge är det valfritt att ange en offentlig IP-adress. Om du inte anger en så konfigureras och används en Azure-hanterad offentlig IP-adress automatiskt för körnings-API-trafik. Ange endast den offentliga IP-adressen om du vill äga och kontrollera den offentliga IP-adress som används för inkommande eller utgående kommunikation till Internet.

Uppdatera VNet-konfiguration

  1. Gå till det ursprungliga virtuella nätverket i portalen.
  2. I den vänstra menyn väljer du Undernät och sedan det ursprungliga undernätet.
  3. Kontrollera att de ursprungliga IP-adresserna har släppts av API Management. Under Tillgängliga IP-adresser noterar du antalet IP-adresser som är tillgängliga i undernätet. Alla adresser (förutom reserverade Azure-adresser) ska vara tillgängliga. Om det behövs väntar du på att IP-adresser ska släppas.
  4. Gå till din API Management-instans.
  5. I den vänstra menyn går du till Nätverk och väljer Virtuellt nätverk.
  6. Välj nätverksanslutningen på den plats som du vill uppdatera.
  7. Välj det ursprungliga VNet-nätverket och undernätet. Du kan också välja en ny offentlig IP-adress. Välj Använd.
  8. Om din API Management-instans distribueras i flera regioner fortsätter du att konfigurera VNet-inställningar för de återstående platserna för din instans.
  9. I det övre navigeringsfältet väljer du Spara.

När du har uppdaterat VNet-konfigurationen ändras statusen för DIN API Management-instans till Uppdatera. Migreringsprocessen tar cirka 45 minuter att slutföra. När statusen ändras till Online slutförs migreringen.

Verifiera migrering

Kontrollera att migreringen lyckades när statusen ändras till Online genom att kontrollera plattformsversionen av DIN API Management-instans. Efter lyckad migrering är stv2 värdet eller stv2.1.

Bekräfta inställningarna innan den gamla gatewayen rensas

För scenarier där den gamla gatewayen tillfälligt behålls efter migreringen samexisterar den gamla och den nya beräkningen som skapades under migreringen under en kort tidsperiod, cirka 15 minuter, som du kan använda för att verifiera distributionen och att dina program fungerar som förväntat. I vissa scenarier kan du utöka kvarhållningsperioden till 48 timmar via en portalinställning.

  • Under det här fönstret är de gamla och nya gatewayerna både online och betjänar trafik. Du debiteras inte under den här tiden.
  • Använd det här fönstret om du vill uppdatera eventuella nätverksberoenden, inklusive DNS, brandväggsregler och virtuella nätverk för att använda den nya VIP-adressen och undernätets adressutrymme.
  • Kontrollera dessutom den uppdaterade instansens nätverksstatus för att säkerställa anslutningen av instansen till dess beroenden. I portalen går du till den vänstra menyn under Distribution och infrastruktur och väljer Nätverksnätverksstatus>. Uppdatera vid behov inställningar som UDR och NSG-regler.
  • Efter fönstret inaktiveras den gamla gatewayen och den nya gatewayen är den enda som betjänar trafiken.

Återställ automatiskt om migreringen misslyckas

Om det uppstår ett fel under migreringsprocessen återgår instansen automatiskt till stv1 plattformen. Om migreringen har slutförts (plattformsversionen av instansen visas som stv2 eller stv2.1 och statusen online) kan du inte återställa till stv1 plattformen.

Kontakta Azure Support om migreringen misslyckas.

Om du behöver funktionen för att återställa manuellt rekommenderar vi att du distribuerar en ny stv2 instans sida vid sida med din ursprungliga API Management-instans.

Särskilda villkor och scenarier

Under vissa förhållanden kanske alternativ 1: Migrera och behålla samma undernät inte är tillgängligt eller fungerar annorlunda. Portalen identifierar dessa villkor och rekommenderar migreringsalternativen. Om du inte kan använda alternativ 1 eller om det finns flera villkor använder du Alternativ 2: Ändra till ett nytt undernät.

  • VNet med särskilda interna villkor – Om din API Management-instans för närvarande distribueras i ett virtuellt nätverk med särskilda interna villkor (som inte är relaterade till kundkonfiguration) meddelas du i portalen att alternativ 1 för migrering av samma undernät i portalen innehåller ytterligare stilleståndstid (cirka 1 timme). Du rekommenderas att använda portalen för migrering. Du kan också använda följande ändrade Azure CLI-skript för migrering av samma undernät med cirka 1 timmes stilleståndstid:

    APIM_NAME={name of your API Management instance}
# In PowerShell, use the following syntax: $APIM_NAME={name of your API Management instance}
RG_NAME={name of your resource group} 
# Get resource ID of API Management instance
APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
# Call REST API to migrate to stv2 and preserve VIP address for special condition
az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2024-06-01-preview&migrateWithDowntime=true" --body '{"mode": "PreserveIP"}'

  • Flera stv1-instanser i undernätet – Det kanske inte finns tillräckligt med kostnadsfria IP-adresser för migrering av samma undernät om du försöker migrera instanserna samtidigt. Du kanske kan migrera instanser sekventiellt med alternativ 1.

  • Delegering av undernät – Om undernätet där API Management distribueras för närvarande delegeras till andra Azure-tjänster måste du migrera med alternativ 2.

  • Azure Key Vault blockerat – Om åtkomsten till Azure Key Vault för närvarande är blockerad måste du migrera med alternativ 2, inklusive att konfigurera NSG-regler i det nya undernätet för åtkomst till Azure Key Vault.

Hjälp och support

Vi är här för att hjälpa dig att migrera till stv2 plattformen med minimala avbrott i dina tjänster.

Om du har frågor får du snabba svar från communityexperter i Microsoft Q&A. Om du har ett supportavtal och behöver teknisk hjälp kan du skapa en supportbegäran.

  1. För Sammanfattning skriver du en beskrivning av problemet, till exempel "stv1 retirement".
  2. Under Problemtyp väljer du Teknisk.
  3. Välj din prenumeration under Prenumeration.
  4. Under Tjänst väljer du Mina tjänster och sedan API Management Service.
  5. Under Resurs väljer du den Azure-resurs som du skapar en supportbegäran för.
  6. För Problemtyp väljer du Administration och hantering.
  7. För Problemundertyp väljer du Uppgradera, Skala eller SKU-ändringar.

Vanliga frågor och svar

  • Vilken information behöver vi för att välja en migreringsväg?

    • Vad är nätverksläget för API Management-instansen?
    • Är anpassade domäner konfigurerade?
    • Är en brandvägg inblandad?
    • Några kända beroenden som tas av uppströms/nedströms på de berörda IP-adresserna?
    • Är det en distribution i flera regioner?
    • Kan vi ändra den befintliga instansen eller krävs en parallell installation?
    • Kan det bli stilleståndstid?
    • Kan migreringen utföras i icke-arbetstid?

  • Vilka är förutsättningarna för migreringen?

    För VNet-inmatade instanser, se förutsättningarna för alternativen för att migrera och behålla samma undernät eller för att migrera och ändra till ett nytt undernät.

  • Kommer migreringen att orsaka stilleståndstid?

    När du migrerar en VNet-inmatad instans och behåller samma undernätskonfiguration förväntas minimal eller ingen stilleståndstid för API-gatewayen. Se sammanfattningstabellen i Förväntad stilleståndstid.

    När du migrerar och ändrar till en ny VIP-adress bör det inte finnas någon stilleståndstid om standardvärdnamn används. Det är viktigt att alla nätverksberoenden tas om hand i förväg för att de påverkade API:erna ska fungera. Men om anpassade domäner används pekar de på den rensade beräkningen tills de uppdateras, vilket kan orsaka driftstopp. För vissa migreringsalternativ kan du också aktivera en migreringsinställning för att behålla den gamla gatewayen i 48 timmar. Att ha den gamla och den nya beräknings samexistensen underlättar valideringen och sedan kan du uppdatera de anpassade DNS-posterna efter be vilja.

  • Min trafik är tvingad genom en brandvägg. Vilka ändringar krävs?

    • Kontrollera först och främst att de undernät som du använder för migreringen behåller följande konfiguration (de bör redan vara konfigurerade om du migrerar och behåller ditt aktuella undernät):
      • Aktivera tjänstslutpunkter enligt beskrivningen här
      • UDR (användardefinierad väg) har hopp från ApiManagement-tjänsttaggen inställd på "Internet" och inte bara till din brandväggsadress
    • Kraven för NSG-konfiguration för stv2 förblir desamma oavsett om du har brandvägg eller inte. Kontrollera att ditt nya undernät har det
    • Brandväggsregler som refererar till det aktuella IP-adressintervallet för API Management-instansen bör uppdateras för att använda IP-adressintervallet för det nya undernätet.

  • Kan data- eller konfigurationsförluster inträffa vid/under migreringen?

    stv1 till stv2 migrering innebär att du uppdaterar beräkningsplattformen ensam och att det interna lagringslagret inte ändras. Därför är all konfiguration säker under migreringsprocessen. Detta inkluderar den systemtilldelade hanterade identiteten, som om den är aktiverad bevaras.

  • Så här bekräftar du att migreringen har slutförts och slutförts

    Migreringen anses vara fullständig och lyckad när statusen på översiktssidan läser Online tillsammans med att plattformsversionen är antingen stv2 eller stv2.1. Kontrollera också att nätverksstatusen på bladet Nätverk visar grönt för alla nödvändiga anslutningar.

  • Kan jag utföra migreringen med hjälp av portalen?

    Ja, VNet-inmatade instanser kan migreras med hjälp av bladet Plattformsmigrering .

  • Kan jag bevara IP-adressen för instansen?

    Ja, bladet Plattformsmigrering i portalen och REST-API:et har alternativ för att bevara IP-adressen.

  • Finns det en migreringssökväg utan att ändra den befintliga instansen?

    Ja, du behöver en migrering sida vid sida. Det innebär att du skapar en ny API Management-instans parallellt med din aktuella instans och kopierar konfigurationen till den nya instansen.

  • Vad händer om migreringen misslyckas?

    Om din API Management-instans inte visar plattformsversionen som stv2 eller stv2.1 och status som Online efter att du initierat migreringen misslyckades den förmodligen. Tjänsten återställs automatiskt till den gamla instansen och inga ändringar görs.

  • Vilka funktioner är inte tillgängliga under migreringen?

    API-begäranden förblir dynamiska under migreringen. Infrastrukturkonfiguration (till exempel anpassade domäner, platser och CA-certifikat) är låst i 30 minuter.

  • Hur lång tid tar migreringen?

    Den förväntade varaktigheten för en migrering till en ny VNet-konfiguration är cirka 45 minuter. Indikatorn för att kontrollera om migreringen redan har utförts är att kontrollera om Status för din instans är tillbaka till Online och inte Uppdatera. Planera längre tider för distributioner i flera regioner och i scenarier som innebär att ändra undernätet mer än en gång.

  • Finns det något sätt att verifiera VNet-konfigurationen innan du försöker migrera?

    Om du planerar att ändra undernätet under migreringen kan du distribuera en ny API Management-instans med det virtuella nätverk, undernät och (valfritt) IP-adressresurs som du ska använda för den faktiska migreringen. Gå till sidan Nätverksstatus när distributionen har slutförts och kontrollera om varje slutpunktsanslutningsstatus är grön. Om ja kan du ta bort den här nya API Management-instansen och fortsätta med den verkliga migreringen med din ursprungliga stv1värdbaserade tjänst.

  • Kan jag återställa migreringen om det behövs?

    Om det uppstår ett fel under migreringsprocessen återställs instansen automatiskt till stv1 plattformen. Men när tjänsten har migrerats kan du inte återställa till stv1 plattformen.

  • Krävs det någon ändring i anpassade domäner/privata DNS-zoner?

    När VNet-inmatade instanser är i internt läge och byter till en ny VIP måste du uppdatera de privata DNS-zonerna till den nya VNet IP-adressen som hämtats efter migreringen. Var också uppmärksam på att uppdatera DNS-zoner som inte är Azure (till exempel dina lokala DNS-servrar som pekar på API Management privata IP-adress). Men i externt läge uppdaterar migreringsprocessen automatiskt standarddomänerna om de används.

  • Min stv1-instans distribueras till flera Azure-regioner (flera regioner). Hur gör jag för att uppgradera till stv2?

    Distributioner i flera regioner omfattar fler hanterade gatewayer som distribueras på andra platser. När du migrerar med bladet Plattformsmigrering i portalen migrerar du varje plats separat. REST-API:et Migrera till Stv2 migrerar alla platser i ett anrop. Instansen anses migrerad till den nya plattformen endast när alla platser migreras. Alla regionala gatewayer fortsätter att fungera normalt under hela migreringsprocessen.

  • Kan jag uppgradera min stv1-instans till samma undernät?

    Ja, använd bladet Plattformsmigrering i portalen eller använd REST-API:et Migrera till stv2.

  • Kan jag testa den nya gatewayen i ett nytt undernät innan jag växlar livetrafiken?

    • När du migrerar till ett nytt undernät samexisterar de gamla och nya hanterade gatewayerna som standard i 15 minuter, vilket är ett litet tidsfönster för att verifiera distributionen. Du kan aktivera en migreringsinställning för att behålla den gamla gatewayen i 48 timmar. Den här ändringen håller de gamla och nya hanterade gatewayerna aktiva för att ta emot trafik och underlätta validering.
    • Migreringsprocessen uppdaterar automatiskt standarddomännamnen, och om de används dirigeras trafiken direkt till de nya gatewayerna.
    • Om anpassade domännamn används kan motsvarande DNS-poster behöva uppdateras med den nya IP-adressen om de inte använder CNAME. Kunder kan uppdatera sin värdfil till den nya API Management-IP-adressen och verifiera instansen innan de gör växeln. Under den här valideringsprocessen fortsätter den gamla gatewayen att hantera livetrafiken.

  • Finns det några saker att tänka på när du använder standarddomännamnet i ett nytt undernät?

    Instanser som använder standard-DNS-namnet i externt läge har DNS automatiskt uppdaterad av migreringsprocessen. Dessutom uppdateras hanteringsslutpunkten, som alltid använder standarddomännamnet, automatiskt av migreringsprocessen. Eftersom växeln sker omedelbart vid en lyckad migrering börjar den nya instansen ta emot trafik omedelbart, och det är viktigt att alla nätverksbegränsningar/beroenden tas hand om i förväg för att undvika att påverkade API:er inte är tillgängliga.

  • Vad bör vi tänka på för gatewayer med egen värd?

    Du behöver inte göra något i dina lokala gatewayer. Du behöver bara migrera API Management-instanser som körs i Azure som påverkas av stv1 plattformens tillbakadragning. Observera att det kan finnas en ny IP-adress för konfigurationsslutpunkten för API Management-instansen och att eventuella nätverksbegränsningar som är fästa på IP-adressen bör uppdateras.

  • Hur påverkas utvecklarportalen av migreringen?

    Utvecklarportalen påverkas inte. Om anpassade domäner används bör DNS-posten uppdateras med den effektiva IP-adressen efter migreringen. Men om standarddomänerna används uppdateras de automatiskt vid lyckad migrering. Det finns ingen stilleståndstid för utvecklarportalen under migreringen.

  • Har kostnaden påverkats när vi migrerat till stv2?

    Faktureringsmodellen är densamma för stv2 och det kommer inte att uppstå några fler kostnader under och efter migreringen.

  • Vilka RBAC-behörigheter krävs för migreringen stv1 till stv2?

    Användaren/processen som utför migreringen skulle behöva skrivåtkomst till API Management-instansen. Dessutom krävs följande två behörigheter:

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/publicIPAddresses/join/action

Relaterat innehåll