Delen via

Een door VNet geïnjecteerd API Management-exemplaar migreren dat wordt gehost op het stv1-platform naar stv2

  • Artikel

VAN TOEPASSING OP: Ontwikkelaar | Premie

Dit artikel bevat stappen voor het migreren van een API Management-exemplaar dat wordt gehost op het stv1 rekenplatform in-place naar het stv2 platform wanneer het exemplaar wordt geïnjecteerd (geïmplementeerd) in een extern of intern VNet. Kijk of u dit moet doen.

Notitie

Nieuw in augustus 2024: Om u te helpen bij het migreren van uw in VNet opgenomen exemplaar, hebben we de migratieopties in de portal verbeterd. U kunt uw exemplaar nu in-place migreren en hetzelfde subnet en IP-adres behouden.

Voor een VNet-inject-exemplaar hebt u de volgende migratieopties:

  • Optie 1: hetzelfde subnet behouden: migreer het exemplaar ter plaatse en behoud de bestaande subnetconfiguratie van de exemplaren. U kunt kiezen of het oorspronkelijke VIP-adres van het API Management-exemplaar behouden blijft (aanbevolen) of dat er een nieuw VIP-adres wordt gegenereerd.

  • Optie 2: Ga naar een nieuw subnet : migreer uw exemplaar door een ander subnet op te geven in hetzelfde of een ander VNet. Na de migratie migreert u desgewenst terug naar het oorspronkelijke subnet van het exemplaar. Het migratieproces wijzigt het VIP-adres(en) van het exemplaar. Na de migratie moet u alle netwerkafhankelijkheden, waaronder DNS, firewallregels en VNets, bijwerken om het nieuwe VIP-adres(en) te gebruiken.

Onder bepaalde, minder frequente omstandigheden is migratie in hetzelfde subnet mogelijk niet mogelijk of gedraagt zich anders. Zie Speciale voorwaarden en scenario's voor meer informatie.

Zie Een niet-VNet-geïnjecteerd API Management-exemplaar stv1 migreren naar het stv2-platform als u een niet-VNet-geïnjecteerd API Management-exemplaar wilt migreren naar het stv2-platform.

Belangrijk

Ondersteuning voor API Management-exemplaren die op het stv1 platform worden gehost, wordt buiten gebruik gesteld. In global Azure is de buitengebruikstellingsdatum 31 augustus 2024. In Azure Government en in Azure beheerd door 21Vianet (Azure in China), is de buitengebruikstellingsdatum 24 februari 2025. Als u exemplaren op het stv1 platform hebt gehost, migreert u deze vóór de buitengebruikstellingsdatum naar het stv2 platform om serviceonderbrekingen te voorkomen.

Let op

  • Het migreren van uw API Management-exemplaar naar het stv2 platform is een langdurige bewerking.
  • Migratie naar stv2 is niet omkeerbaar.

Wat gebeurt er tijdens de migratie?

Migratie van stv1 API Management-platform naar stv2 omvat het alleen bijwerken van de onderliggende rekenkracht en heeft geen invloed op de service-/API-configuratie die in de opslaglaag blijft bestaan.

  • Het upgradeproces omvat het maken van een nieuwe berekening parallel aan de oude berekening, die maximaal 45 minuten kan duren. Plan langere tijden voor implementaties in meerdere regio's en in scenario's waarbij het subnet meerdere keren moet worden gewijzigd.
  • De API Management-status in Azure Portal wordt bijgewerkt.
  • Voor bepaalde migratieopties kunt u ervoor kiezen om het VIP-adres te behouden of er wordt een nieuw openbaar VIP gegenereerd.
  • Voor migratiescenario's waarin een nieuw VIP-adres wordt gegenereerd:
    • Azure beheert de migratie.
    • De gateway-DNS verwijst nog steeds naar de oude berekening als een aangepast domein in gebruik is.
    • Als aangepaste DNS niet wordt gebruikt, verwijst de gateway en de portal DNS onmiddellijk naar de nieuwe berekening.
    • Voor een exemplaar in de interne VNet-modus beheert de klant de DNS, zodat de DNS-vermeldingen blijven verwijzen naar oude berekeningen totdat deze door de klant is bijgewerkt.
    • Het is de DNS die verwijst naar de nieuwe of de oude rekenkracht en dus geen downtime voor de API's.
    • Wijzigingen zijn vereist voor uw firewallregels, indien aanwezig, zodat het nieuwe rekensubnet de back-ends kan bereiken.
    • Na een geslaagde migratie wordt de oude berekening na een korte periode automatisch buiten gebruik gesteld. Wanneer u overschakelen naar een nieuw subnet met behulp van de blade Platformmigratie in de portal, kunt u een migratie-instelling inschakelen om de oude gateway gedurende 48 uur te behouden. De vertragingsoptie van 48 uur is alleen beschikbaar voor door VNet geïnjecteerde services.

Vereisten

Andere vereisten zijn specifiek voor de migratieopties in de volgende secties.

Optie 1: Hetzelfde subnet migreren en behouden

U kunt uw API Management-exemplaar migreren naar het stv2 platform waarbij de bestaande subnetconfiguratie behouden blijft. Dit vereenvoudigt uw migratie. U kunt migreren met behulp van de blade Platformmigratie in Azure Portal of de Migrate to Stv2 REST API.

Vereisten

  • Er moet een netwerkbeveiligingsgroep worden gekoppeld aan elk subnet en NSG-regels voor API Management op het stv2 platform moeten worden geconfigureerd. Hieronder ziet u de minimale connectiviteitsinstellingen:

    • Uitgaand naar Azure Storage via poort 443
    • Uitgaand naar Azure SQL via poort 1433
    • Uitgaand naar Azure Key Vault via poort 443
    • Binnenkomend van Azure Load Balancer via poort 6390
    • Binnenkomend van apiManagement-servicetag via poort 3443
    • Binnenkomend via poort 80/443 voor clients die API Management-service aanroepen
    • Het subnet moet service-eindpunten hebben ingeschakeld voor Azure Storage, Azure SQL en Azure Key Vault

  • De adresruimte van elk bestaand subnet moet groot genoeg zijn om tijdens de migratie een kopie van uw bestaande service naast uw bestaande service te hosten.

  • Andere netwerkoverwegingen:

    • Schakel alle regels voor automatische schaalaanpassing uit die zijn geconfigureerd voor API Management-exemplaren die zijn geïmplementeerd in het subnet. Regels voor automatisch schalen kunnen het migratieproces verstoren.
    • Als u meerdere API Management-exemplaren in hetzelfde subnet hebt, migreert u elk exemplaar op volgorde. U wordt aangeraden alle exemplaren in het subnet onmiddellijk te migreren om potentiële problemen te voorkomen met exemplaren die op verschillende platforms in hetzelfde subnet worden gehost.

Opties voor openbaar IP-adres - migratie van hetzelfde subnet

U kunt kiezen of het oorspronkelijke VIP-adres van het API Management-exemplaar behouden blijft (aanbevolen) of dat er een nieuw VIP-adres wordt gegenereerd.

  • Virtueel IP-adres behouden: als u het VIP-adres in een VNet in de externe modus behoudt, kunnen API-aanvragen reageren tijdens de migratie (zie Verwachte downtime). Voor een VNet in de interne modus wordt tijdelijke downtime verwacht. Infrastructuurconfiguratie (zoals aangepaste domeinen, locaties en CA-certificaten) wordt 45 minuten vergrendeld. Er is geen verdere configuratie vereist na de migratie.

    Met deze optie wordt de stv1 berekening definitief verwijderd nadat de migratie is voltooid. Er is geen optie om het tijdelijk te bewaren.

    In de volgende afbeelding ziet u een overzicht op hoog niveau van wat er gebeurt wanneer het IP-adres behouden blijft.

    Diagram van in-place migratie naar hetzelfde subnet en het behoud van IP-adres.

  • Nieuw virtueel IP-adres : als u deze optie kiest, genereert API Management een nieuw VIP-adres voor uw exemplaar. API-aanvragen blijven responsief tijdens de migratie. Infrastructuurconfiguratie (zoals aangepaste domeinen, locaties en CA-certificaten) wordt 30 minuten vergrendeld. Na de migratie moet u alle netwerkafhankelijkheden, waaronder DNS, firewallregels en VNets, bijwerken om het nieuwe VIP-adres te kunnen gebruiken.

    Met deze optie wordt de berekening standaard gedurende een korte periode bewaard nadat de stv1 migratie is voltooid, zodat u het gemigreerde exemplaar kunt valideren en de netwerk- en DNS-configuratie kunt bevestigen.

    In de volgende afbeelding ziet u een algemeen overzicht van wat er gebeurt wanneer een nieuw IP-adres wordt gegenereerd.

    Diagram van in-place migratie naar hetzelfde subnet en het genereren van een nieuw IP-adres.

Vooraf gemaakt IP-adres voor migratie

Voor API Management-exemplaren die bereikbaar zijn via een openbaar IP-adres, maakt API Management een openbaar IP-adres voor het migratieproces vooraf. Zoek het vooraf gemaakte IP-adres in de JSON-uitvoer van de eigenschappen van uw API Management-exemplaar. Onder customPropertiesis het vooraf gemaakte IP-adres de waarde van de Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps eigenschap. Voor een implementatie met meerdere regio's is de waarde een door komma's gescheiden lijst met vooraf gemaakte IP-adressen.

Gebruik het vooraf gemaakte IP-adres (of de adressen) om u te helpen bij het beheren van het migratieproces:

  • Wanneer u het VIP-adres migreert en behoudt, wordt het vooraf gemaakte IP-adres tijdelijk toegewezen aan de nieuwe stv2 implementatie, voordat het oorspronkelijke IP-adres aan de stv2 implementatie wordt toegewezen. Als u bijvoorbeeld firewallregels hebt die de toegang tot het API Management-exemplaar beperken, kunt u het vooraf gemaakte IP-adres toevoegen aan de acceptatielijst om de continuïteit van clienttoegang tijdens de migratie te behouden. Nadat de migratie is voltooid, kunt u het vooraf gemaakte IP-adres verwijderen uit uw acceptatielijst.
  • Wanneer u een nieuw VIP-adres migreert en genereert, wordt het vooraf gemaakte IP-adres tijdens de migratie toegewezen aan de nieuwe stv2 implementatie en blijft het behouden nadat de migratie is voltooid. Gebruik het vooraf gemaakte IP-adres om uw netwerkafhankelijkheden, zoals DNS en firewallregels, bij te werken om naar het nieuwe IP-adres te verwijzen.

Verwachte downtime en retentie van rekenkracht

Bij het migreren van een door VNet geïnjecteerd exemplaar en het behouden van dezelfde subnetconfiguratie, wordt minimaal of geen downtime verwacht voor de API-gateway. De volgende tabel bevat een overzicht van de verwachte downtime en stv1 retentie van rekenkracht voor elk migratiescenario wanneer hetzelfde subnet wordt bewaard:

VNet-modus Optie Openbaar IP-adres Verwachte downtime stv1 rekenretentie
External VIP behouden Geen downtime; verkeer wordt gedurende maximaal 20 minuten uitgevoerd op een tijdelijk IP-adres tijdens de migratie naar de nieuwe stv2 implementatie Geen retentie
External Nieuw VIP Geen downtime Standaard 15 minuten bewaard, zodat u netwerkafhankelijkheden kunt bijwerken
Intern VIP behouden Downtime gedurende ongeveer 20 minuten tijdens de migratie terwijl het bestaande IP-adres is toegewezen aan de nieuwe stv2 implementatie. Geen retentie
Intern Nieuw VIP Geen downtime Standaard 15 minuten bewaard, zodat u netwerkafhankelijkheden kunt bijwerken; kan worden uitgebreid tot 48 uur wanneer u de portal gebruikt

Migratiestappen: hetzelfde subnet behouden

  1. Blader in Azure Portal naar uw API Management-exemplaar.
  2. Selecteer platformmigratie in het linkermenu onder Instellingen.
  3. Selecteer onder Een migratieoptie selecteren de optie Hetzelfde subnet behouden.
  4. Selecteer een van de twee IP-adresopties onder Kies een van de twee IP-adresopties.

    Notitie

    Als uw VNet zich in de externe modus bevindt, noteert u het vooraf gemaakte openbare IP-adres voor het migratieproces. Gebruik dit adres om de netwerkverbinding voor uw gemigreerde exemplaar te configureren.

  5. (Bijvoorbeeld opgenomen in de interne modus en migreren naar een nieuw VIP) Kies onder Kies het scenario dat overeenkomt met uw vereisten een van de twee opties, afhankelijk van of u de oorspronkelijke stv1 berekening voor een periode na de migratie wilt behouden.
  6. Selecteer Verifiëren om geautomatiseerde controles uit te voeren op het subnet. Als er problemen worden gedetecteerd, past u de configuratie van het subnet aan en voert u de controles opnieuw uit. Voor andere netwerkafhankelijkheden, zoals DNS- en firewallregels, controleert u handmatig.
  7. Bevestig dat u wilt migreren en selecteer Migratie starten. De status van uw API Management-exemplaar wordt gewijzigd in Bijwerken. Het migratieproces duurt ongeveer 45 minuten. Wanneer de status verandert in Online, is de migratie voltooid.

Optie 2: Migreren en wijzigen in nieuw subnet

Met behulp van Azure Portal kunt u uw exemplaar migreren door een ander subnet in hetzelfde of een ander VNet op te geven. Na de migratie migreert u desgewenst terug naar het oorspronkelijke subnet van het exemplaar.

In de volgende afbeelding ziet u een overzicht op hoog niveau van wat er gebeurt tijdens de migratie naar een nieuw subnet.

Diagram van in-place migratie naar een nieuw subnet.

Vereisten

  • Een nieuw subnet in het huidige virtuele netwerk, in elke regio waar het API Management-exemplaar wordt geïmplementeerd. (U kunt ook een subnet instellen in een ander virtueel netwerk in dezelfde regio's en hetzelfde abonnement als uw API Management-exemplaar). Er moet een netwerkbeveiligingsgroep worden gekoppeld aan elk subnet en NSG-regels voor API Management op het stv2 platform moeten worden geconfigureerd.

  • (Optioneel) Een nieuwe openbare IPv4-adresresource van de Standard-SKU in dezelfde regio(s) en hetzelfde abonnement als uw API Management-exemplaar. Zie Vereisten voor netwerkverbindingen voor meer informatie.

Belangrijk

  • Vanaf mei 2024 is een openbare IP-adresresource niet meer nodig bij het implementeren (injecteren) van een API Management-exemplaar in een VNet in de interne modus of het migreren van de interne VNet-configuratie naar een nieuw subnet. In de externe VNet-modus is het opgeven van een openbaar IP-adres optioneel. Als u er geen opgeeft, wordt automatisch een door Azure beheerd openbaar IP-adres geconfigureerd en gebruikt voor runtime-API-verkeer. Geef alleen het openbare IP-adres op als u de eigenaar wilt zijn van het openbare IP-adres dat wordt gebruikt voor inkomende of uitgaande communicatie met internet.

Migratiestappen : wijzigen in een nieuw subnet

  1. Blader in Azure Portal naar uw API Management-exemplaar.

  2. Selecteer platformmigratie in het linkermenu onder Instellingen.

  3. Selecteer Onder Een migratieoptie selecteren de optie Wijzigen in een nieuw subnet.

  4. Kies onder Kies het scenario dat overeenkomt met uw vereisten een van de twee opties, afhankelijk van of u de oorspronkelijke stv1 berekening voor een periode na de migratie wilt behouden.

    Schermopname van opties voor het behouden van stv1-rekenproces in de portal.

  5. Onder Migratie-instellingen definiëren voor elke locatie:

    1. Selecteer een locatie om te migreren.
    2. Selecteer het virtuele netwerk, het subnet en het optionele openbare IP-adres waarnaar u wilt migreren.

    Schermopname van het selecteren van netwerkmigratie-instellingen in de portal.

  6. Selecteer Onder Controleren of uw subnet voldoet aan de migratievereisten, controleert u Controleren om geautomatiseerde controles uit te voeren op het subnet. Als er problemen worden gedetecteerd, past u de configuratie van het subnet aan en voert u de controles opnieuw uit. Voor andere netwerkafhankelijkheden, zoals DNS- en firewallregels, controleert u handmatig.

  7. Bevestig dat u wilt migreren en selecteer Migreren. De status van uw API Management-exemplaar wordt gewijzigd in Bijwerken. Het migratieproces duurt ongeveer 45 minuten. Wanneer de status verandert in Online, is de migratie voltooid.

Als uw API Management-exemplaar in meerdere regio's is geïmplementeerd, herhaalt u de voorgaande stappen om door te gaan met het migreren van VNet-instellingen voor de resterende locaties van uw exemplaar.

(Optioneel) Terug migreren naar het oorspronkelijke subnet

Als u bent gemigreerd en gewijzigd in een nieuw subnet, migreert u desgewenst terug naar het oorspronkelijke subnet dat u in elke regio hebt gebruikt. Werk hiervoor de VNet-configuratie opnieuw bij, waarbij u deze keer het oorspronkelijke VNet en subnet in elke regio opgeeft. Zoals in de voorgaande migratie verwacht u een langdurige bewerking en verwacht u dat het VIP-adres wordt gewijzigd.

In de volgende afbeelding ziet u een algemeen overzicht van wat er gebeurt tijdens de migratie naar het oorspronkelijke subnet.

Diagram van in-place migratie terug naar het oorspronkelijke subnet.

Belangrijk

Als het VNet en het subnet zijn vergrendeld (omdat er andere stv1 API Management-exemplaren op het platform zijn geïmplementeerd) of de resourcegroep waarin het oorspronkelijke VNet is geïmplementeerd, een resourcevergrendeling heeft, moet u de vergrendeling verwijderen voordat u teruggaat naar het oorspronkelijke subnet. Wacht tot het verwijderen van de vergrendeling is voltooid voordat u de migratie naar het oorspronkelijke subnet probeert uit te voeren. Meer informatie.

Aanvullende vereisten

  • Het ontgrendelde oorspronkelijke subnet, in elke regio waar het API Management-exemplaar wordt geïmplementeerd. Er moet een netwerkbeveiligingsgroep worden gekoppeld aan het subnet en NSG-regels voor API Management moeten worden geconfigureerd.

  • (Optioneel) Een nieuwe openbare IPv4-adresresource van de Standard-SKU in dezelfde regio(s) en hetzelfde abonnement als uw API Management-exemplaar.

    Belangrijk

    • Vanaf mei 2024 is een openbare IP-adresresource niet meer nodig bij het implementeren (injecteren) van een API Management-exemplaar in een VNet in de interne modus of het migreren van de interne VNet-configuratie naar een nieuw subnet. In de externe VNet-modus is het opgeven van een openbaar IP-adres optioneel. Als u er geen opgeeft, wordt automatisch een door Azure beheerd openbaar IP-adres geconfigureerd en gebruikt voor runtime-API-verkeer. Geef alleen het openbare IP-adres op als u de eigenaar wilt zijn van het openbare IP-adres dat wordt gebruikt voor inkomende of uitgaande communicatie met internet.

VNet-configuratie bijwerken

  1. Navigeer in de portal naar het oorspronkelijke VNet.
  2. Selecteer subnetten in het linkermenu en vervolgens het oorspronkelijke subnet.
  3. Controleer of de oorspronkelijke IP-adressen zijn vrijgegeven door API Management. Noteer onder Beschikbare IP-adressen het aantal IP-adressen dat beschikbaar is in het subnet. Alle adressen (met uitzondering van gereserveerde Azure-adressen) moeten beschikbaar zijn. Wacht zo nodig tot ip-adressen zijn vrijgegeven.
  4. Navigeer naar uw API Management-exemplaar.
  5. Selecteer in het linkermenu onder Netwerk de optie Virtueel netwerk.
  6. Selecteer de netwerkverbinding op de locatie die u wilt bijwerken.
  7. Selecteer het oorspronkelijke VNet-netwerk en subnet. Selecteer eventueel een nieuw openbaar IP-adres. Selecteer Toepassen.
  8. Als uw API Management-exemplaar in meerdere regio's is geïmplementeerd, kunt u doorgaan met het configureren van VNet-instellingen voor de resterende locaties van uw exemplaar.
  9. Selecteer Opslaan in de bovenste navigatiebalk.

Nadat u de VNet-configuratie hebt bijgewerkt, wordt de status van uw API Management-exemplaar gewijzigd in Bijwerken. Het migratieproces duurt ongeveer 45 minuten. Wanneer de status verandert in Online, is de migratie voltooid.

Migratie verifiëren

Als u wilt controleren of de migratie is geslaagd, controleert u de platformversie van uw API Management-exemplaar wanneer de status is gewijzigd in Online. Na een geslaagde migratie is stv2 de waarde of stv2.1.

Instellingen bevestigen voordat de oude gateway wordt opgeschoond

Voor scenario's waarin de oude gateway tijdelijk na de migratie wordt bewaard, bestaan de oude en de nieuwe berekening die tijdens de migratie is gemaakt gedurende een korte periode, ongeveer 15 minuten, die u kunt gebruiken om de implementatie te valideren en dat uw toepassingen werken zoals verwacht. Voor bepaalde scenario's kunt u eventueel de bewaarperiode uitbreiden naar 48 uur via een portalinstelling.

  • Tijdens dit venster zijn de oude en nieuwe gateways zowel online als het leveren van verkeer. Gedurende deze tijd worden er geen kosten in rekening gebracht.
  • Gebruik dit venster om netwerkafhankelijkheden, waaronder DNS, firewallregels en VNets, bij te werken voor het gebruik van het nieuwe VIP-adres en de subnetadresruimte.
  • Controleer ook de netwerkstatus van het bijgewerkte exemplaar om de connectiviteit van het exemplaar met de afhankelijkheden ervan te garanderen. Selecteer >in de portal in het linkermenu onder Implementatie en infrastructuur de netwerkstatus. Werk indien nodig instellingen bij, zoals UDR's en NSG-regels.
  • Na het venster wordt de oude gateway buiten gebruik gesteld en is de nieuwe gateway de enige die verkeer bedient.

Automatisch herstellen als de migratie mislukt

Als er een fout optreedt tijdens het migratieproces, wordt het exemplaar automatisch teruggezet naar het stv1 platform. Als de migratie is voltooid (de platformversie van het exemplaar wordt weergegeven als stv2 of stv2.1 de status als Online), kunt u niet terugdraaien naar het stv1 platform.

Neem contact op met ondersteuning voor Azure voor hulp als de migratie mislukt.

Als u de mogelijkheid nodig hebt om handmatig terug te draaien, is het raadzaam om een nieuw stv2 exemplaar naast uw oorspronkelijke API Management-exemplaar te implementeren.

Speciale voorwaarden en scenario's

Onder bepaalde voorwaarden is optie 1: Migreren en hetzelfde subnet behouden mogelijk niet beschikbaar of gedraagt zich anders. De portal detecteert deze voorwaarden en raadt de migratieopties aan. Als u optie 1 niet kunt gebruiken of als er meerdere voorwaarden aanwezig zijn, gebruikt u Optie 2: Wijzigen in een nieuw subnet.

  • VNet met speciale interne voorwaarden : als uw API Management-exemplaar momenteel wordt geïmplementeerd in een VNet met speciale interne voorwaarden (niet gerelateerd aan de klantconfiguratie), wordt u in de portal gewaarschuwd dat optie 1 voor migratie van hetzelfde subnet in de portal extra downtime (ongeveer 1 uur) bevat. Het wordt aanbevolen om de portal voor migratie te gebruiken. U kunt ook het volgende aangepaste Azure CLI-script gebruiken voor migratie met hetzelfde subnet met ongeveer 1 uur downtime:

    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"}'

  • Meerdere stv1-exemplaren in het subnet : er zijn mogelijk onvoldoende gratis IP-adressen beschikbaar voor een migratie van hetzelfde subnet als u probeert de exemplaren tegelijkertijd te migreren. U kunt exemplaren mogelijk sequentieel migreren met optie 1.

  • Subnetdelegering : als het subnet waarin API Management is geïmplementeerd momenteel wordt gedelegeerd aan andere Azure-services, moet u migreren met optie 2.

  • Azure Key Vault geblokkeerd : als de toegang tot Azure Key Vault momenteel wordt geblokkeerd, moet u migreren met optie 2, inclusief het instellen van NSG-regels in het nieuwe subnet voor toegang tot Azure Key Vault.

Help en ondersteuning

We zijn er om u te helpen bij het migreren naar het stv2 platform met minimale onderbrekingen naar uw services.

Als u vragen hebt, kunt u snel antwoorden krijgen van community-experts in Microsoft Q&A. Dien een ondersteuningsaanvraag in als u over een ondersteuningsplan beschikt en technische ondersteuning nodig hebt.

  1. Typ voor Samenvatting een beschrijving van uw probleem, bijvoorbeeld 'stv1 retirement'.
  2. Selecteer Technisch onder Type probleem.
  3. Selecteer onder Abonnement uw abonnement.
  4. Selecteer Onder Service de optie Mijn services en selecteer vervolgens API Management Service.
  5. Selecteer onder Resource de Azure-resource waarvoor u een ondersteuningsaanvraag maakt.
  6. Selecteer Beheer en beheer voor probleemtype.
  7. Voor subtype Probleem selecteert u Upgraden, Schalen of SKU-wijzigingen.

Veelgestelde vragen

  • Welke gegevens moeten we kiezen voor een migratiepad?

    • Wat is de netwerkmodus van het API Management-exemplaar?
    • Zijn aangepaste domeinen geconfigureerd?
    • Is er een firewall betrokken?
    • Zijn er bekende afhankelijkheden die door upstream/downstream worden genomen op de betrokken IP-adressen?
    • Is het een implementatie met meerdere regio's?
    • Kunnen we het bestaande exemplaar wijzigen of is een parallelle installatie vereist?
    • Kan er downtime zijn?
    • Kan de migratie worden uitgevoerd in niet-kantooruren?

  • Wat zijn de vereisten voor de migratie?

    Zie voor door VNet geïnjecteerde exemplaren de vereisten voor de opties voor het migreren en behouden van hetzelfde subnet of voor het migreren en wijzigen van een nieuw subnet.

  • Veroorzaakt de migratie downtime?

    Bij het migreren van een door VNet geïnjecteerd exemplaar en het behouden van dezelfde subnetconfiguratie, wordt minimaal of geen downtime verwacht voor de API-gateway. Zie de overzichtstabel in Verwachte downtime.

    Bij het migreren en wijzigen van een nieuw VIP-adres mag er geen downtime optreden als standaardhostnamen worden gebruikt. Het is essentieel dat alle netwerkafhankelijkheden vooraf worden afgehandeld, zodat de betrokken API's functioneel zijn. Als aangepaste domeinen echter in gebruik zijn, wijzen ze naar de opgeschoonde rekenkracht totdat ze worden bijgewerkt, wat tot downtime kan leiden. U kunt ook voor bepaalde migratieopties een migratie-instelling inschakelen om de oude gateway gedurende 48 uur te behouden. Als het oude en de nieuwe berekening naast elkaar bestaan, kunt u de validatie vergemakkelijken. Vervolgens kunt u de aangepaste DNS-vermeldingen bijwerken.

  • Mijn verkeer wordt geforceerd getunneld via een firewall. Welke wijzigingen zijn vereist?

    • Zorg er allereerst voor dat de subnetten die u gebruikt voor de migratie de volgende configuratie behouden (deze moeten al worden geconfigureerd als u uw huidige subnet migreert en bewaart):
      • Service-eindpunten inschakelen zoals hier wordt beschreven
      • De UDR (door de gebruiker gedefinieerde route) heeft de hop van de ApiManagement-servicetag ingesteld op 'Internet' en niet alleen op uw firewalladres
    • De vereisten voor NSG-configuratie voor stv2 blijven hetzelfde, ongeacht of u een firewall hebt of niet; zorg ervoor dat uw nieuwe subnet dit heeft
    • Firewallregels die verwijzen naar het huidige IP-adresbereik van het API Management-exemplaar, moeten worden bijgewerkt om het IP-adresbereik van uw nieuwe subnet te gebruiken.

  • Kunnen gegevens- of configuratieverlies optreden door/tijdens de migratie?

    stv1 voor stv2 migratie moet het rekenplatform alleen worden bijgewerkt en de interne opslaglaag niet wordt gewijzigd. Daarom is alle configuratie veilig tijdens het migratieproces. Dit omvat de door het systeem toegewezen beheerde identiteit, die, indien ingeschakeld, behouden blijft.

  • Controleren of de migratie is voltooid en geslaagd

    De migratie wordt beschouwd als voltooid en geslaagd wanneer de status op de overzichtspagina online wordt gelezen, samen met de platformversie als of stv2 stv2.1. Controleer ook of de netwerkstatus op de blade Netwerk groen wordt weergegeven voor alle vereiste connectiviteit.

  • Kan ik de migratie uitvoeren met behulp van de portal?

    Ja, door VNet geïnjecteerde exemplaren kunnen worden gemigreerd met behulp van de blade Platformmigratie .

  • Kan ik het IP-adres van het exemplaar behouden?

    Ja, de blade Platformmigratie in de portal en de REST API hebben opties om het IP-adres te behouden.

  • Is er een migratiepad zonder het bestaande exemplaar te wijzigen?

    Ja, u hebt een side-by-side migratie nodig. Dit betekent dat u een nieuw API Management-exemplaar parallel met uw huidige exemplaar maakt en de configuratie naar het nieuwe exemplaar kopieert.

  • Wat gebeurt er als de migratie mislukt?

    Als uw API Management-exemplaar de platformversie stv2 niet als of stv2.1 status als Online weergeeft nadat u de migratie hebt gestart, is dit waarschijnlijk mislukt. Uw service wordt automatisch teruggedraaid naar het oude exemplaar en er worden geen wijzigingen aangebracht.

  • Welke functionaliteit is niet beschikbaar tijdens de migratie?

    API-aanvragen blijven responsief tijdens de migratie. Infrastructuurconfiguratie (zoals aangepaste domeinen, locaties en CA-certificaten) is 30 minuten vergrendeld.

  • Hoe lang duurt de migratie?

    De verwachte duur voor een migratie naar een nieuwe VNet-configuratie is ongeveer 45 minuten. De indicator om te controleren of de migratie al is uitgevoerd, is om te controleren of de status van uw exemplaar weer online is en niet wordt bijgewerkt. Plan langere tijden voor implementaties in meerdere regio's en in scenario's waarbij het subnet meerdere keren moet worden gewijzigd.

  • Is er een manier om de VNet-configuratie te valideren voordat u de migratie uitvoert?

    Als u van plan bent om het subnet tijdens de migratie te wijzigen, kunt u een nieuw API Management-exemplaar implementeren met het VNet, subnet en (optionele) IP-adresresource die u gaat gebruiken voor de daadwerkelijke migratie. Navigeer naar de pagina Netwerkstatus nadat de implementatie is voltooid en controleer of elke eindpuntverbindingsstatus groen is. Zo ja, dan kunt u dit nieuwe API Management-exemplaar verwijderen en doorgaan met de echte migratie met uw oorspronkelijke gehoste stv1service.

  • Kan ik de migratie indien nodig terugdraaien?

    Als er een fout optreedt tijdens het migratieproces, wordt het exemplaar automatisch teruggedraaid naar het stv1 platform. Nadat de service is gemigreerd, kunt u echter niet terugdraaien naar het stv1 platform.

  • Is er een wijziging vereist in aangepaste domein-/privé-DNS-zones?

    Met door VNet geïnjecteerde exemplaren in de interne modus en overschakelen naar een nieuw VIP, moet u de privé-DNS-zones bijwerken naar het nieuwe VNet-IP-adres dat is verkregen na de migratie. Let ook op het bijwerken van niet-Azure DNS-zones (bijvoorbeeld uw on-premises DNS-servers die verwijzen naar het privé-IP-adres van API Management). In de externe modus wordt het migratieproces echter automatisch de standaarddomeinen bijgewerkt als deze in gebruik zijn.

  • Mijn stv1-exemplaar wordt geïmplementeerd in meerdere Azure-regio's (meerdere regio's). Hoe kan ik upgrade naar stv2?

    Implementaties in meerdere regio's omvatten meer beheerde gateways die zijn geïmplementeerd op andere locaties. Wanneer u migreert met behulp van de blade Platformmigratie in de portal, migreert u elke locatie afzonderlijk. De Migrate to Stv2 REST API migreert alle locaties in één aanroep. Het exemplaar wordt alleen gemigreerd naar het nieuwe platform wanneer alle locaties worden gemigreerd. Alle regionale gateways blijven normaal werken tijdens het migratieproces.

  • Kan ik mijn stv1-exemplaar upgraden naar hetzelfde subnet?

    Ja, gebruik de blade Platformmigratie in de portal of gebruik de Migratie naar stv2 REST API.

  • Kan ik de nieuwe gateway testen in een nieuw subnet voordat ik het liveverkeer overschakel?

    • Wanneer u migreert naar een nieuw subnet, bestaan de oude en de nieuwe beheerde gateways standaard gedurende 15 minuten, wat een klein tijdvenster is om de implementatie te valideren. U kunt een migratie-instelling inschakelen om de oude gateway gedurende 48 uur te behouden. Met deze wijziging blijven de oude en de nieuwe beheerde gateways actief om verkeer te ontvangen en validatie te vergemakkelijken.
    • Tijdens het migratieproces worden automatisch de standaarddomeinnamen bijgewerkt. Als dit wordt gebruikt, wordt het verkeer onmiddellijk naar de nieuwe gateways gerouteerd.
    • Als aangepaste domeinnamen worden gebruikt, moeten de bijbehorende DNS-records mogelijk worden bijgewerkt met het nieuwe IP-adres als u geen CNAME gebruikt. Klanten kunnen hun hosts-bestand bijwerken naar het nieuwe IP-adres van API Management en het exemplaar valideren voordat ze overschakelen. Tijdens dit validatieproces blijft de oude gateway het liveverkeer bedienen.

  • Zijn er overwegingen bij het gebruik van een standaarddomeinnaam in een nieuw subnet?

    Exemplaren die de standaard-DNS-naam in de externe modus gebruiken, worden automatisch door het migratieproces dns-updates uitgevoerd. Bovendien wordt het beheereindpunt, dat altijd gebruikmaakt van de standaarddomeinnaam, automatisch bijgewerkt door het migratieproces. Omdat de switch onmiddellijk plaatsvindt bij een geslaagde migratie, ontvangt het nieuwe exemplaar onmiddellijk verkeer en is het van cruciaal belang dat eventuele netwerkbeperkingen/afhankelijkheden van tevoren worden geregeld om te voorkomen dat betrokken API's niet beschikbaar zijn.

  • Wat moeten we overwegen voor zelf-hostende gateways?

    U hoeft niets te doen in uw zelf-hostende gateways. U hoeft alleen API Management-exemplaren te migreren die worden uitgevoerd in Azure die worden beïnvloed door de buitengebruikstelling van het stv1 platform. Houd er rekening mee dat er mogelijk een nieuw IP-adres is voor het configuratie-eindpunt van het API Management-exemplaar en dat netwerkbeperkingen die zijn vastgemaakt aan het IP-adres moeten worden bijgewerkt.

  • Hoe wordt de ontwikkelaarsportal beïnvloed door migratie?

    Er is geen invloed op de ontwikkelaarsportal. Als aangepaste domeinen worden gebruikt, moet de DNS-record worden bijgewerkt met het effectieve IP-adres, na de migratie. Als de standaarddomeinen echter worden gebruikt, worden ze automatisch bijgewerkt bij een geslaagde migratie. Er is geen downtime voor de ontwikkelaarsportal tijdens de migratie.

  • Is er invloed op de kosten zodra we naar stv2 zijn gemigreerd?

    Het factureringsmodel blijft hetzelfde voor stv2 en er worden geen kosten meer gemaakt tijdens en na de migratie.

  • Welke RBAC-machtigingen zijn vereist voor de migratie van stv1 naar stv2?

    De gebruiker/het proces dat de migratie uitvoert, heeft schrijftoegang nodig tot het API Management-exemplaar. Daarnaast zijn de volgende twee machtigingen vereist:

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

Gerelateerde inhoud