Delen via

Exemplaar van Azure API Management implementeren in meerdere Azure-regio's

  • Artikel

VAN TOEPASSING OP: Premium

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 om het opslaan van klantgegevens in één regio in te schakelen is momenteel alleen beschikbaar in de regio Azië - zuidoost (Singapore) van het geografisch gebied Azië en Stille Oceaan. Voor alle andere regio's worden klantgegevens opgeslagen in Geo.

Over implementatie in meerdere regio's

  • Alleen het gatewayonderdeel van uw API Management-exemplaar wordt 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.

  • Als u een secundaire locatie wilt configureren voor uw API Management-exemplaar wanneer deze wordt geïmplementeerd (geïnjecteerd) in een virtueel netwerk, moet de VNet- en subnetregio overeenkomen met de secundaire locatie die u configureert. Als u de beschikbaarheidszone toevoegt, verwijdert of inschakelt in de primaire regio, of als u het subnet van de primaire regio wijzigt, wordt het VIP-adres van uw API Management-exemplaar gewijzigd. Zie IP-adressen van de Azure API Management-service voor meer informatie. Als u echter een secundaire regio toevoegt, verandert het VIP van de primaire regio niet omdat elke regio een eigen privé-VIP heeft.

  • Gateway-configuraties zoals API's en beleidsdefinities worden regelmatig gesynchroniseerd tussen de primaire en secundaire regio's die u toevoegt. Het doorgeven van updates aan de regionale gateways duurt normaal gesproken minder dan 10 seconden. 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 Traffic Manager-eindpunt (van toepassing op het externe VNet en niet-netwerkmodi van API Management), wordt verkeer doorgestuurd naar een regionale gateway op basis van de laagste latentie, wat de latentie kan verminderen die wordt ervaren door geografisch gedistribueerde API-consumenten. In de interne VNet-modus moeten klanten hun eigen oplossing configureren om verkeer over de regionale gateways te routeren en te verdelen. Zie Netwerkoverwegingen voor meer informatie.

  • De gateway in elke regio (inclusief de primaire regio) heeft een regionale DNS-naam die het URL-patroon volgt, https://<service-name>-<region>-01.regional.azure-api.netbijvoorbeeld https://contoso-westus2-01.regional.azure-api.net.

  • 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 het beheervlak API Management en de ontwikkelaarsportal niet meer beschikbaar, maar secundaire regio's blijven API-aanvragen verwerken met behulp van de meest recente gateway-configuratie.

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 en subnet instelt op de locatie die u wilt toevoegen en binnen hetzelfde abonnement. Zie vereisten voor virtuele netwerken.

API Management-service implementeren in een extra regio

  1. Navigeer in Azure Portal naar uw API Management-service en selecteer Locaties in het linkermenu.
  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 eventueel een of meer beschikbaarheidszones.
  6. Als het API Management-exemplaar is geïmplementeerd in een virtueel netwerk, configureert u de instellingen van het virtuele netwerk op de locatie, inclusief het virtuele netwerk, het subnet en het openbare IP-adres (als u beschikbaarheidszones inschakelt).
  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 Azure Portal naar uw API Management-service en selecteer Locaties in het linkermenu.
  2. Voor de locatie die u wilt verwijderen, selecteert u het contextmenu met behulp van de knop ... aan de rechterkant 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 in slechts één regio wordt geïmplementeerd. In dit geval komt de prestatiewinst alleen uit antwoorden die in de cache zijn opgeslagen in Azure API Management in een regio die specifiek is voor de aanvraag; het contact opnemen met de back-end over de hele wereld kan nog steeds een hoge latentie veroorzaken.

Als u wilt profiteren van de geografische distributie van uw systeem, moet back-endservices zijn 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 doorsturen naar lokale exemplaren van uw back-end.

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

  2. Selecteer de gewenste API.

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

    API-code-editor

  4. Gebruik de set-backend 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 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>

Traffic Manager gebruiken voor routering naar regionale back-ends

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

  • Voor verkeersdistributie en failover raden we u aan Traffic Manager te gebruiken met de geografische routeringsmethode. Het wordt afgeraden Traffic Manager te gebruiken met de gewogen routeringsmethode met API Management-back-ends.

  • Voor verkeersbeheer tijdens onderhoudsbewerkingen wordt u aangeraden de routeringsmethode Prioriteit te gebruiken.

Aangepaste routering gebruiken voor regionale API Management-gateways

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 de API Management-service.
  3. Configureer de regionale API Management-eindpunten in Traffic Manager. De regionale eindpunten volgen het URL-patroon van https://<service-name>-<region>-01.regional.azure-api.netbijvoorbeeld https://contoso-westus2-01.regional.azure-api.net.
  4. Configureer de regionale statuseindpunten van API Management in Traffic Manager. De regionale statuseindpunten volgen bijvoorbeeld het URL-patroon vanhttps://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdefhttps://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.
  5. Geef de routeringsmethode van Traffic Manager op.

Routering naar een regionale gateway uitschakelen

Onder sommige omstandigheden moet u mogelijk de routering naar een van de regionale gateways tijdelijk uitschakelen. Voorbeeld:

  • Nadat u een nieuwe regio hebt toegevoegd, kunt u deze uitgeschakeld houden tijdens het configureren en testen van de regionale back-endservice
  • Tijdens regelmatig back-endonderhoud in een regio
  • Verkeer omleiden naar andere regio's tijdens een geplande noodherstelanalyse die een niet-beschikbare regio simuleert of tijdens een regionale storing

Als u routering naar een regionale gateway in uw API Management-exemplaar wilt uitschakelen, werkt u de eigenschapswaarde van disableGateway de gateway bij naar true. U kunt de waarde instellen met behulp van de REST API voor de service maken of bijwerken , de opdracht az apim update in de Azure CLI, de set-azapimanagement Azure PowerShell-cmdlet of andere Azure-hulpprogramma's.

Notitie

U kunt routering naar een regionale gateway alleen uitschakelen wanneer u de standaardroutering van API Management gebruikt, niet een aangepaste routeringsoplossing.

Een regionale gateway uitschakelen met behulp van de Azure CLI:

  1. Gebruik de opdracht az apim show om de locaties, gatewaystatus en regionale URL's weer te geven die zijn geconfigureerd voor het API Management-exemplaar.

    az apim show --name contoso --resource-group apim-hello-world-resource \
    --query "additionalLocations[].{Location:location,Disabled:disableGateway,Url:gatewayRegionalUrl}" \
    --output table

    Voorbeelduitvoer:

    Location    Disabled    Url
----------  ----------  ------------------------------------------------------------
West US 2   True        https://contoso-westus2-01.regional.azure-api.net
West Europe True        https://contoso-westeurope-01.regional.azure-api.net

  2. Gebruik de opdracht az apim update om de gateway uit te schakelen op een beschikbare locatie, zoals US - west 2.

    az apim update --name contoso --resource-group apim-hello-world-resource \
--set additionalLocations[location="West US 2"].disableGateway=true

    De update kan enkele minuten duren.

  3. Controleer of verkeer dat is omgeleid naar de url van de regionale gateway, wordt omgeleid naar een andere regio.

Als u routering naar de regionale gateway wilt herstellen, stelt u de waarde van disableGateway in op false.

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 onafhankelijk. De connectiviteitsvereisten , zoals vereiste regels voor netwerkbeveiligingsgroepen voor een virtueel netwerk in een toegevoegde regio, zijn over het algemeen hetzelfde als die voor een netwerk in de primaire regio.
  • Virtuele netwerken in de verschillende regio's hoeven niet te worden gekoppeld.

Belangrijk

Wanneer deze is geconfigureerd in de interne VNet-modus, moet elke regionale gateway ook uitgaande connectiviteit hebben op poort 1433 naar de Azure SQL-database die is geconfigureerd voor uw API Management-exemplaar, dat zich alleen in de primaire regio bevindt. Zorg ervoor dat u connectiviteit met de FQDN of het IP-adres van deze Azure SQL-database toestaat in routes of firewallregels die u configureert voor netwerken in uw secundaire regio's; de Azure SQL-servicetag kan niet worden gebruikt in dit scenario. Als u de naam van de Azure SQL-database in de primaire regio wilt vinden, gaat u naar de pagina Netwerkstatus> van uw API Management-exemplaar in de portal.

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 wordt dit openbare IP-adres gebruikt voor beheerverkeer op poort3443.

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

    • Interne VNet-modus : er wordt ook een privé-IP-adres gemaakt in elke regio die wordt toegevoegd aan een virtueel netwerk. Gebruik deze adressen om in 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 taakverdeling naar de regionale gateways uitgevoerd. 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.

Volgende stappen