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 | Premium

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. Voor dit scenario migreert u uw exemplaar door de VNet-configuratie-instellingen bij te werken. Kijk of u dit moet doen.

Als u een niet-VNnet-geïnjecteerde API Management wilt migreren die op het stv1 platform wordt gehost, raadpleegt u Een niet-VNet-geïnjecteerd API Management-exemplaar migreren naar het stv2-platform.

Belangrijk

Ondersteuning voor API Management-exemplaren die op het stv1 platform worden gehost, wordt op 31 augustus 2024 buiten gebruik gesteld. Als u exemplaren op het stv1 platform hebt gehost, migreert u deze vóór die datum naar het stv2 platform om serviceonderbrekingen te voorkomen. Meer informatie.

Let op

  • Het migreren van uw API Management-exemplaar naar het stv2 platform is een langdurige bewerking.
  • Het VIP-adres van uw exemplaar wordt gewijzigd. Na de migratie moet u alle netwerkafhankelijkheden, waaronder DNS, firewallregels en VNets, bijwerken om het nieuwe VIP-adres te kunnen gebruiken. Plan uw migratie dienovereenkomstig.
  • 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.
  • De API Management-status in Azure Portal wordt bijgewerkt.
  • Het VIP-adres (of de adressen, voor een implementatie met meerdere regio's) van het exemplaar wordt gewijzigd.
  • Azure beheert de DNS van het beheereindpunt en werkt de nieuwe berekening onmiddellijk bij een geslaagde migratie bij.
  • 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 ongeveer 15 minuten automatisch buiten gebruik gesteld, met een optie om deze maximaal 48 uur te vertragen. De vertragingsoptie van 48 uur is alleen beschikbaar voor door VNet geïnjecteerde services.

Vereisten

  • Een API Management-exemplaar dat wordt gehost op het stv1 rekenplatform. Als u wilt controleren of uw exemplaar wordt gehost op het stv1 platform, raadpleegt u Hoe kan ik weet welk platform als host fungeert voor mijn API Management-exemplaar? Het exemplaar moet worden geïnjecteerd in een virtueel netwerk.

  • 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 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. Zie Vereisten voor netwerkverbindingen voor meer informatie.

    Belangrijk

    • Vanaf mei 2024 is een openbaar IP-adres 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. In de externe VNet-modus wordt het openbare IP-adres gebruikt voor runtime-API-verkeer.
    • Als u momenteel zoneredundantie inschakelt voor een API Management-exemplaar in een VNet in de interne modus of externe modus, moet u een nieuw openbaar IP-adres opgeven.

  • (Optioneel) Neem contact op met ondersteuning voor Azure om aan te vragen dat de oorspronkelijke service-infrastructuur gedurende maximaal 48 uur na een geslaagde migratie parallel wordt onderhouden. Deze optie verlengt de periode waarin de oude infrastructuur beschikbaar is na de migratie na de standaardwaarde van 15 minuten voordat deze wordt opgeschoond. Deze optie is alleen beschikbaar voor door VNet geïnjecteerde services, zodat service-eigenaren netwerkinstellingen kunnen bijwerken en toepassingen kunnen testen om de nieuwe infrastructuur te gebruiken. Deze extensieaanvraag is van toepassing op alle API Management-exemplaren in een abonnement.

    Notitie

    Als u van plan bent om uw met VNet geïnjecteerde API Management-exemplaar na de migratie terug te migreren naar het oorspronkelijke subnet, wordt u aangeraden de extensie van 48 uur niet aan te vragen.

Triggermigratie van een door het netwerk geïnjecteerd API Management-exemplaar

Triggermigratie van een door het netwerk geïnjecteerd API Management-exemplaar naar het stv2 platform door de bestaande netwerkconfiguratie bij te werken voor het gebruik van nieuwe netwerkinstellingen in elke regio waar het exemplaar wordt geïmplementeerd. Nadat deze update is voltooid, kunt u als optionele stap teruggaan naar de oorspronkelijke VNets en subnetten die u hebt gebruikt.

U kunt ook migreren naar het stv2 platform door zoneredundantie in te schakelen die beschikbaar is in de Premium-laag.

Belangrijk

Het VIP-adres(en) van uw API Management-exemplaar wordt gewijzigd. API-aanvragen blijven echter 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 gekoppelde VNets, bijwerken om het nieuwe VIP-adres(en) te kunnen gebruiken.

Netwerkconfiguratie bijwerken

U kunt Azure Portal of andere Azure-hulpprogramma's gebruiken om te migreren naar een nieuw subnet in hetzelfde of een ander VNet. 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.

Als u bijvoorbeeld de portal wilt gebruiken:

  1. Navigeer in de portal naar uw API Management-exemplaar.
  2. Selecteer in het linkermenu Netwerk>virtueel netwerk.
  3. Selecteer de netwerkverbinding op de locatie die u wilt bijwerken.
  4. Selecteer het virtuele netwerk en subnet dat u wilt configureren. Selecteer eventueel een nieuw openbaar IP-adres. Selecteer Toepassen.
  5. Ga door met het configureren van VNet-instellingen voor de resterende locaties van uw API Management-exemplaar.
  6. 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.

(Optioneel) Terug migreren naar het oorspronkelijke subnet

U kunt desgewenst terugkeren naar het oorspronkelijke subnet dat u in elke regio hebt gebruikt voordat u naar het stv2 platform migreert. 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.

Notitie

Als u van plan bent om terug te migreren naar het oorspronkelijke subnet, raden we u aan de verlenging van 48 uur niet aan te vragen voor uw abonnement voor het onderhouden van de oude infrastructuur; anders wordt uw migratie vertraagd. Als u een verlenging wilt annuleren, neemt u contact op met ondersteuning voor Azure.

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 openbaar IP-adres 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. In de externe VNet-modus wordt het openbare IP-adres gebruikt voor runtime-API-verkeer.
    • Als u momenteel zoneredundantie inschakelt voor een API Management-exemplaar in een VNet in de interne modus of externe modus, moet u een nieuw openbaar IP-adres opgeven.

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. Herhaal de migratiestappen in de vorige sectie. Geef in elke regio het oorspronkelijke VNet en subnet op. Selecteer eventueel een nieuw openbaar IP-adres.
  5. 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

Na een geslaagde migratie van een met VNet geïnjecteerd API Management-exemplaar, bestaan de oude en de nieuwe berekening die tijdens de migratie is gemaakt gedurende een korte periode, ongeveer 15 minuten. Dit is een klein tijdvenster dat u kunt gebruiken om de implementatie te valideren en dat uw toepassingen werken zoals verwacht. (Dit venster kan worden verlengd tot 48 uur door vooraf contact op te nemen met ondersteuning voor Azure.)

  • 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.

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 voor probleemtype Beheer beheer en beheer.
  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?

    Voor door VNet geïnjecteerde exemplaren hebt u een nieuw subnet nodig om te migreren in elk VNet (externe of interne modus). Geef in de externe modus desgewenst een openbare IP-adresresource op. Aan het subnet moet een NSG zijn gekoppeld volgens de regels voor stv2 het platform, zoals hier wordt beschreven.

  • Veroorzaakt de migratie downtime?

    Omdat de oude gateway alleen wordt opgeschoond nadat de nieuwe berekening in orde is en online is, mag er geen downtime zijn als standaardhostnamen in gebruik zijn. 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 aanvragen dat de oude gateway maximaal 48 uur wordt bewaard door vooraf een ondersteuning voor Azure ticket te maken. 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 eerst voor dat de nieuwe subnetten die u voor de migratie hebt gemaakt, de volgende configuratie behouden (deze moeten al zijn geconfigureerd in uw huidige subnet):
      • 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.

  • Hoe bevestigt u dat de migratie is voltooid en geslaagd?

    De migratie wordt beschouwd als voltooid en geslaagd wanneer de status op de overzichtspagina Online leest, samen met de platformversie als of stv2stv2.1. Controleer ook of de netwerkstatus op de netwerkblade 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 door de subnetconfiguratie(s) in de blade Netwerk te wijzigen.

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

    Er is momenteel geen manier om het IP-adres te behouden als uw exemplaar wordt geïnjecteerd in een VNet.

  • 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. Na de migratie moet u alle netwerkafhankelijkheden, waaronder DNS, firewallregels en VNets, bijwerken om het nieuwe VIP-adres te kunnen gebruiken.

  • 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.

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

    U kunt een nieuw API Management-exemplaar implementeren met het nieuwe VNet, subnet en (optionele) IP-adresresource die u gebruikt 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.

    Nadat een door VNet geïnjecteerde service is gemigreerd, is er een kort venster waarin de oude gateway verkeer blijft bedienen en kunt u uw netwerkinstellingen bevestigen. Zie Instellingen bevestigen voordat de oude gateway wordt opgeschoond

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

    Met door VNet geïnjecteerde exemplaren in de interne modus moet u de privé-DNS-zones bijwerken naar het nieuwe VNet-IP-adres dat na de migratie is verkregen. 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. Elke locatie moet afzonderlijk worden gemigreerd door een nieuw subnet en een nieuw openbaar IP-adres op te geven (vereist bij het inschakelen van zoneredundantie). Navigeer naar de blade Locaties en voer de wijzigingen uit op elke vermelde locatie. 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?

    • U kunt het stv1 exemplaar niet in één enkele pass migreren naar hetzelfde subnet zonder uitvaltijd. U kunt uw gemigreerde exemplaar echter desgewenst weer naar het oorspronkelijke subnet verplaatsen. Hier vindt u meer informatie.
    • De oude gateway duurt tussen 15 minuten en 45 minuten om het subnet te verlaten, zodat u de verplaatsing kunt initiëren. U kunt echter aanvragen om deze tijd te verhogen tot maximaal 48 uur met een ondersteuningsticket.
    • Zorg ervoor dat het oude subnetnetwerk voor NSG en firewall is bijgewerkt voor stv2 afhankelijkheden.
    • Subnet-IP-adrestoewijzing is nietdeterministisch, daarom kan het oorspronkelijke IP-adres van de ILB (inkomend verkeer) voor interne modusimplementaties veranderen wanneer u teruggaat naar het oorspronkelijke subnet. Hiervoor is een DNS-wijziging vereist als u A-records gebruikt.

  • Kan ik de nieuwe gateway testen voordat ik het liveverkeer overschakel?

    • De oude en de nieuwe beheerde gateways bestaan standaard gedurende 15 minuten, wat een klein tijdvenster is om de implementatie te valideren. U kunt aanvragen om deze tijd te verhogen tot maximaal 48 uur via een ondersteuning voor Azure ticket. 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?

    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

Video’s

Gerelateerde inhoud