Een Azure API Management-exemplaar implementeren in meerdere Azure-regio's

Azure API Management ondersteunt implementatie in meerdere regio's, waardoor API-uitgevers regionale API-gateways kunnen toevoegen aan een bestaand API Management-exemplaar in een of meer ondersteunde Azure-regio's. Implementatie in meerdere regio's helpt bij het verminderen van de latentie van aanvragen die worden waargenomen door geografisch gedistribueerde API-gebruikers en verbetert de beschikbaarheid van de service als één regio offline gaat.

Wanneer u een regio toevoegt, configureert u het volgende:

Belangrijk

De functie voor het opslaan van klantgegevens in één regio is momenteel alleen beschikbaar in de regio Azië - zuidoost (Singapore) van het geografische gebied Azië en Stille Oceaan. Voor alle andere regio's worden klantgegevens opgeslagen in Geo.

Beschikbaarheid

Belangrijk

Deze functie is alleen beschikbaar in de Premium-laag van API Management.

Over implementatie in meerdere regio's

  • Bij implementatie in meerdere regio's wordt alleen het gatewayonderdeel van uw API Management-exemplaar gerepliceerd naar meerdere regio's. Het beheervlak en de ontwikkelaarsportal van het exemplaar blijven alleen gehost in de primaire regio, de regio waar u de service oorspronkelijk hebt geïmplementeerd.

  • Gatewayconfiguraties, zoals API's en beleidsdefinities, worden regelmatig gesynchroniseerd tussen de primaire en secundaire regio's die u toevoegt. Implementatie in meerdere regio's biedt beschikbaarheid van de API-gateway in meer dan één regio en biedt servicebeschikbaarheid als één regio offline gaat.

  • Wanneer API Management openbare HTTP-aanvragen ontvangt naar het eindpunt van de primaire gateway, wordt verkeer gerouteerd naar een regionale gateway op basis van de laagste latentie, waardoor de latentie van geografisch gedistribueerde API-gebruikers kan worden verminderd.

  • Als een regio offline gaat, worden API-aanvragen automatisch gerouteerd rond de mislukte regio naar de dichtstbijzijnde gateway.

  • Als de primaire regio offline gaat, zijn de API Management beheervlak en ontwikkelaarsportal niet meer beschikbaar, maar secundaire regio's blijven API-aanvragen verwerken met behulp van de meest recente gatewayconfiguratie.

Vereisten

  • Zie Een API Management service-exemplaar maken als u nog geen API Management service-exemplaar hebt gemaakt. Selecteer de Premium-servicelaag.
  • Als uw API Management-exemplaar is geïmplementeerd in een virtueel netwerk, moet u ervoor zorgen dat u een virtueel netwerk, subnet en openbaar IP-adres instelt op de locatie die u wilt toevoegen. Zie Vereisten voor virtuele netwerken.

API Management-service implementeren in een extra regio

  1. Navigeer in de Azure Portal naar uw API Management service en selecteer Locaties in het menu links.
  2. Selecteer + Toevoegen in de bovenste balk.
  3. Selecteer de toegevoegde locatie in de vervolgkeuzelijst.
  4. Selecteer het aantal schaaleenheden op de locatie.
  5. Selecteer desgewenst een of meer beschikbaarheidszones.
  6. Als het API Management-exemplaar is geïmplementeerd in een virtueel netwerk, configureert u instellingen voor het virtuele netwerk op de locatie. Selecteer een bestaand virtueel netwerk, subnet en openbaar IP-adres die beschikbaar zijn op de locatie.
  7. Selecteer Toevoegen om te bevestigen.
  8. Herhaal dit proces totdat u alle locaties configureert.
  9. Selecteer Opslaan in de bovenste balk om het implementatieproces te starten.

Een API Management serviceregio verwijderen

  1. Navigeer in de Azure Portal naar uw API Management service en selecteer Locaties in het menu links.
  2. Voor de locatie die u wilt verwijderen, selecteert u het contextmenu met behulp van de knop ... aan het einde van de tabel. Selecteer Verwijderen.
  3. Bevestig de verwijdering en selecteer Opslaan om de wijzigingen toe te passen.

API-aanroepen routeren naar regionale back-endservices

Standaard routeert elke API aanvragen naar één BACK-endservice-URL. Zelfs als u Azure API Management-gateways in verschillende regio's hebt geconfigureerd, stuurt de API-gateway nog steeds aanvragen door naar dezelfde back-endservice, die slechts in één regio is geïmplementeerd. In dit geval is de prestatieverbetering alleen afkomstig van antwoorden die in de cache zijn opgeslagen in Azure API Management in een regio die specifiek is voor de aanvraag. Als u contact opneemt met de back-end over de hele wereld, kan dit nog steeds leiden tot hoge latentie.

Als u wilt profiteren van de geografische distributie van uw systeem, moet u back-endservices hebben geïmplementeerd in dezelfde regio's als Azure API Management-exemplaren. Vervolgens kunt u met behulp van beleid en @(context.Deployment.Region) eigenschap het verkeer routeren naar lokale exemplaren van uw back-end.

Tip

Stel eventueel de disableGateway eigenschap in een regionale gateway in om routering van API-verkeer daar uit te schakelen. Schakel bijvoorbeeld een regionale gateway tijdelijk uit bij het testen of bijwerken van een regionale back-endservice.

  1. Navigeer naar uw Azure API Management-exemplaar en selecteer API's in het menu links.

  2. Selecteer de gewenste API.

  3. Selecteer Code-editor in de pijlvervolgkeuzelijst in de binnenkomende verwerking.

    API-code-editor

  4. Gebruik de set-backend in combinatie met voorwaardelijk choose beleid om een correct routeringsbeleid te maken in de <inbound> </inbound> sectie van het bestand.

    Het volgende XML-bestand werkt bijvoorbeeld voor de regio's VS - west en Azië - oost:

    <policies>
        <inbound>
            <base />
            <choose>
                <when condition="@("West US".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                    <set-backend-service base-url="http://contoso-backend-us.com/" />
                </when>
                <when condition="@("East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                    <set-backend-service base-url="http://contoso-backend-asia.com/" />
                </when>
                <otherwise>
                    <set-backend-service base-url="http://contoso-backend-other.com/" />
                </otherwise>
            </choose>
        </inbound>
        <backend>
            <base />
        </backend>
        <outbound>
            <base />
        </outbound>
        <on-error>
            <base />
        </on-error>
    </policies>
    

Tip

U kunt uw back-endservices ook fronteren met Azure Traffic Manager, de API-aanroepen omleiden naar Traffic Manager en de routering automatisch laten oplossen.

Aangepaste routering gebruiken om regionale gateways te API Management

API Management stuurt de aanvragen naar een regionale gateway op basis van de laagste latentie. Hoewel het niet mogelijk is om deze instelling in API Management te overschrijven, kunt u uw eigen Traffic Manager gebruiken met aangepaste routeringsregels.

  1. Maak uw eigen Azure Traffic Manager.
  2. Als u een aangepast domein gebruikt, gebruikt u dit met Traffic Manager in plaats van met de API Management-service.
  3. Configureer de API Management regionale eindpunten in Traffic Manager. De regionale eindpunten volgen het URL-patroon van https://<service-name>-<region>-01.regional.azure-api.net, bijvoorbeeld https://contoso-westus2-01.regional.azure-api.net.
  4. Configureer de API Management regionale statuseindpunten in Traffic Manager. De regionale statuseindpunten volgen het URL-patroon van https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, bijvoorbeeld https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.
  5. Geef de routeringsmethode van Traffic Manager op.

Virtueel netwerk

Deze sectie bevat overwegingen voor implementaties in meerdere regio's wanneer het API Management-exemplaar wordt geïnjecteerd in een virtueel netwerk.

  • Configureer elk regionaal netwerk afzonderlijk. De connectiviteitsvereisten , zoals de vereiste regels voor netwerkbeveiligingsgroepen voor een virtueel netwerk in een toegevoegde regio, zijn dezelfde als die voor een netwerk in de primaire regio.
  • Virtuele netwerken in de verschillende regio's hoeven niet te worden gekoppeld.

IP-adressen

  • Er wordt een openbaar virtueel IP-adres gemaakt in elke regio die wordt toegevoegd aan een virtueel netwerk. Voor virtuele netwerken in de externe modus of interne modus is dit openbare IP-adres vereist voor het beheer van verkeer op poort 3443.

    • Externe VNet-modus : de openbare IP-adressen zijn ook vereist om openbaar HTTP-verkeer naar de API-gateways te routeren.

    • Interne VNet-modus : er wordt ook een privé-IP-adres gemaakt in elke regio die wordt toegevoegd met een virtueel netwerk. Gebruik deze adressen om binnen het netwerk verbinding te maken met de API Management eindpunten in de primaire en secundaire regio's.

Routering

  • Externe VNet-modus: routering van openbaar HTTP-verkeer naar de regionale gateways wordt automatisch verwerkt, op dezelfde manier als voor een niet-netwerk API Management exemplaar.

  • Interne VNet-modus : privé-HTTP-verkeer wordt niet standaard gerouteerd of verdeeld over de regionale gateways. Gebruikers zijn eigenaar van de routering en zijn verantwoordelijk voor het meenemen van hun eigen oplossing voor het beheren van routering en privétaakverdeling in meerdere regio's. Voorbeelden van oplossingen zijn Azure Application Gateway en Azure Traffic Manager.

Volgende stappen