Beschikbaarheid en betrouwbaarheid van API Management garanderen

VAN TOEPASSING OP: Premium

In dit artikel worden servicemogelijkheden en overwegingen geïntroduceerd om ervoor te zorgen dat uw API Management-exemplaar API-aanvragen blijft verwerken als Azure-storingen optreden.

API Management ondersteunt de volgende belangrijke servicemogelijkheden die worden aanbevolen voor betrouwbare en tolerante Azure-oplossingen . Gebruik ze afzonderlijk of samen om de beschikbaarheid van uw API Management-oplossing te verbeteren:

• Beschikbaarheidszones om tolerantie te bieden voor storingen op datacenterniveau

• Implementatie met meerdere regio's om tolerantie te bieden voor regionale storingen

Beschikbaarheidszones

Azure-beschikbaarheidszones zijn fysiek gescheiden locaties binnen een Azure-regio die tolerant zijn voor storingen op datacenterniveau. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. Om tolerantie te garanderen, zijn er minimaal drie afzonderlijke beschikbaarheidszones aanwezig in alle regio's met beschikbaarheidszones.

Het inschakelen van zoneredundantie voor een API Management-exemplaar in een ondersteunde regio biedt redundantie voor alle serviceonderdelen: gateway, beheervlak en ontwikkelaarsportal. Azure repliceert automatisch alle serviceonderdelen in de zones die u selecteert. Zoneredundantie is alleen beschikbaar in de Premium-servicelaag.

Wanneer u zoneredundantie in een regio inschakelt, moet u rekening houden met het aantal API Management-schaaleenheden dat moet worden gedistribueerd. Configureer minimaal hetzelfde aantal eenheden als het aantal beschikbaarheidszones of een veelvoud, zodat de eenheden gelijkmatig over de zones worden verdeeld. Als u bijvoorbeeld drie beschikbaarheidszones in een regio selecteert, kunt u drie eenheden hebben, zodat elke zone één eenheid host.

Implementatie in meerdere regio's

Met implementatie in meerdere regio's kunt u regionale API-gateways 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. Implementatie met meerdere regio's is alleen beschikbaar in de Premium-servicelaag.

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

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

Beschikbaarheidszones en implementatie in meerdere regio's combineren

De combinatie van beschikbaarheidszones voor redundantie binnen een regio en implementaties in meerdere regio's om de beschikbaarheid van de gateway te verbeteren als er een regionale storing is, helpt de betrouwbaarheid en prestaties van uw API Management-exemplaar te verbeteren.

Voorbeelden:

• Beschikbaarheidszones gebruiken om de tolerantie van de primaire regio in een implementatie met meerdere regio's te verbeteren

• Schaaleenheden verdelen over beschikbaarheidszones en regio's om de prestaties van regionale gateways te verbeteren

SLA-overwegingen

API Management biedt een SLA van 99,99% wanneer u ten minste één eenheid implementeert in twee of meer beschikbaarheidszones of regio's. Ga voor meer informatie naar Prijzen.

Beschikbaarheid van back-end

Afhankelijk van waar en hoe uw back-endservices worden gehost, moet u mogelijk redundante back-ends in verschillende regio's instellen om te voldoen aan uw vereisten voor de beschikbaarheid van services. U kunt ook back-endeigenschappen configureren om de tolerantie en beschikbaarheid van uw back-endservices te verbeteren.

Regionale back-ends

U kunt regionale back-ends beheren en failover afhandelen via API Management om de beschikbaarheid te behouden. Voorbeeld:

• Gebruik in implementaties met meerdere regio's beleidsregels om aanvragen via regionale gateways te routeren naar regionale back-ends.

• Configureer beleidsregels om aanvragen voorwaardelijk naar verschillende back-ends te routeren als er een back-endfout is opgetreden in een bepaalde regio.

• Gebruik caching om mislukte aanroepen te verminderen.

Zie het blogbericht Back-end-API-redundantie met Azure API Manager voor meer informatie.

Back-endeigenschappen configureren voor beschikbaarheid

Met API Management-back-endentiteiten kunt u back-endeigenschappen beheren en toepassen om de beschikbaarheid van back-ends te verbeteren. Voorbeeld:

• Verkeer verdelen en verdelen naar een groep URL's
• Circuitonderbrekerregels configureren om het circuitonderbrekerpatroon toe te passen om de back-end te beschermen tegen te veel aanvragen

Volgende stappen

• Meer informatie over betrouwbaarheid in Azure
• Meer informatie over het ontwerpen van betrouwbare Azure-toepassingen
• API Management en betrouwbaarheid lezen in het Azure Well-Architected Framework