Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure API Management. is een volledig beheerde service waarmee organisaties API's kunnen publiceren, beveiligen, transformeren, onderhouden en bewaken. Als Azure-service biedt API Management een scala aan mogelijkheden ter ondersteuning van uw betrouwbaarheidsvereisten.
Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.
In dit artikel wordt beschreven hoe u API Management tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone, regiostoringen en serviceonderhoud. Ook wordt beschreven hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen, en worden enkele belangrijke punten over de service level agreement (SLA) van de API Management belicht.
Overzicht van betrouwbaarheidsarchitectuur
API Management maakt gebruik van een architectuur op basis van een schaaleenheid om ingebouwde redundantie en schaalbaarheid te bieden. Wanneer u een API Management-exemplaar implementeert, configureert u een of meer schaaleenheden of eenheden. Elke eenheid is een logische weergave van capaciteit die de benodigde rekenresources bevat voor het verwerken van API-aanvragen.
Wanneer u een exemplaar met twee of meer eenheden configureert, werken de beschikbare eenheden samen om aanvragen te verwerken en automatische taakverdeling te bieden. Als een van de eenheden niet meer beschikbaar is, blijven de resterende eenheden verkeer verwerken, maar met mogelijk verminderde capaciteit.
Api Management biedt ondersteuning voor eenheidsdistributie tussen beschikbaarheidszones binnen een regio en in meerdere regio's om meer betrouwbaarheid te krijgen.
API Management-servicelagen bieden verschillende betrouwbaarheidsniveaus:
Premium -laag (klassiek): Ondersteunt meerdere eenheden die kunnen worden gedistribueerd over beschikbaarheidszones en regio's voor maximale tolerantie. In de Premium-laag bestaat elke eenheid uit twee virtuele machines (VM's) die de rekenresources bieden voor het verwerken van API-aanvragen.
Basic v2-, Standard-, Standard v2- en Premium v2-lagen (preview): Alle ondersteunen meerdere eenheden binnen één datacenter. Ze bieden geen ondersteuning voor beschikbaarheidszones of implementaties in meerdere regio's.
Ontwikkelaarslaag: Ondersteunt slechts één eenheid en biedt geen ondersteuning voor beschikbaarheidszone of meerdere regio's. Deze laag is ontworpen voor ontwikkelings- en testscenario's. Het is niet geschikt voor productieworkloads.
Verbruikslaag: Heeft ingebouwde tolerantiemogelijkheden en is tolerant voor een reeks fouten binnen één Azure-datacenter. De verbruikslaag biedt echter geen ondersteuning voor beschikbaarheidszones of implementaties in meerdere regio's. Raadpleeg de SLA (Service Level Agreement) om inzicht te krijgen in de verwachte uptime van een API Management-exemplaar van de consumptielaag.
Eenheden binnen een exemplaar werken samen om aanvragen af te handelen en zorgen automatisch voor de verdeling van de belasting over de beschikbare eenheden. Als een eenheid niet meer beschikbaar is, blijven de resterende eenheden verkeer verwerken, maar met mogelijk verminderde capaciteit.
Opmerking
De Developer- en Premium-lagen van API Management ondersteunen zelf-hostende gateways, die u op uw eigen infrastructuur kunt uitvoeren. Wanneer u zelf-hostende gateways gebruikt, bent u verantwoordelijk voor het configureren van deze gateways om te voldoen aan uw betrouwbaarheidsvereisten. Zelf-hostende gateways vallen buiten het bereik van dit artikel.
Aanbevelingen voor productie-implementatie
Het Azure Well-Architected Framework biedt aanbevelingen voor betrouwbaarheid, prestaties, beveiliging, kosten en bewerkingen. Als u wilt weten hoe deze gebieden elkaar beïnvloeden en bijdragen aan een betrouwbare API Management-oplossing, raadpleegt u best practices voor architectuur voor API Management.
Tolerantie voor tijdelijke fouten
Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.
Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.
Wanneer u API Management vóór een API gebruikt, moet u mogelijk aanvragen die mislukken opnieuw proberen vanwege tijdelijke fouten. Om uw back-end-API te beschermen tegen te veel aanvragen, biedt API Management beleid voor opnieuw proberen, frequentielimiet en quotumbeleid. U kunt ook mogelijkheden voor taakverdeling en circuitonderbreker configureren met behulp van back-endresources.
Tolerantie voor fouten in beschikbaarheidszones
Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.
API Management biedt twee soorten ondersteuning voor beschikbaarheidszones wanneer u een Premium (klassiek) API Management-exemplaar in een ondersteunde regio implementeert:
Automatisch: API Management biedt automatische ondersteuning voor beschikbaarheidszones wanneer u niet opgeeft welke beschikbaarheidszones u wilt gebruiken.
Handmatig: API Management biedt handmatige ondersteuning voor beschikbaarheidszones wanneer u expliciet opgeeft welke beschikbaarheidszones moeten worden gebruikt.
Met ondersteuning voor beschikbaarheidszones repliceert API Management serviceonderdelen tussen zones voor hoge beschikbaarheid. In de primaire regio omvatten deze onderdelen de gateway (schaaleenheden), de beheeromgeving en het ontwikkelaarsportaal. In secundaire regio's worden alleen de gateway-eenheden gerepliceerd. Zie tolerantie voor storingen in de hele regio voor meer informatie over secundaire regio's.
Ondersteuning voor automatische beschikbaarheidszone
U kunt automatische ondersteuning voor beschikbaarheidszones gebruiken om één eenheid of configuratie van meerdere instanties te kiezen om zoneredundantie te bereiken:
Configuratie van meerdere eenheden (aanbevolen): Als uw exemplaar twee of meer eenheden heeft, probeert API Management de eenheden van uw exemplaar te verdelen over de beschikbaarheidszones van de regio. Er is geen manier om te bepalen in welke beschikbaarheidszones uw eenheden worden geplaatst. U wordt aangeraden minimaal twee eenheden te implementeren, die over twee zones kunnen worden verdeeld.
In het volgende diagram ziet u een API Management-exemplaar met drie eenheden die zijn geconfigureerd voor automatische ondersteuning voor beschikbaarheidszones:
In het diagram ziet u drie vakken met het label Eenheid 1, Eenheid 2 en Eenheid 3 die zijn geïmplementeerd in een API Management-exemplaar. Elk eenheidsvak bevat twee pictogrammen die VM's vertegenwoordigen. Drie grotere vakken hebben het label Beschikbaarheidszone 1, Beschikbaarheidszone 2 en Beschikbaarheidszone 3. Zone 1 bevat eenheid 1, zone 2 bevat eenheid 2 en zone 3 bevat eenheid 3.
Configuratie van één eenheid: Als uw exemplaar één eenheid heeft, worden de onderliggende VM's van de eenheid gedistribueerd naar twee beschikbaarheidszones. Er is geen manier om te bepalen in welke beschikbaarheidszones de VM's van de eenheid worden geplaatst.
In het diagram ziet u één vak met het label Eenheid 1 dat is geïmplementeerd in een API Management-exemplaar. Het eenheidsvak bevat twee pictogrammen die VM's vertegenwoordigen. Drie grotere vakken hebben het label Beschikbaarheidszone 1, Beschikbaarheidszone 2 en Beschikbaarheidszone 3. Het vak Unit 1 beslaat zones 1 en 2. Zone 3 is leeg.
Ondersteuning voor handmatige beschikbaarheidszone
Als u expliciet de beschikbaarheidszones wilt selecteren die u wilt gebruiken, kunt u kiezen tussen zone-redundante en zonegebonden configuraties:
Zone-redundant: Configureer zoneredundantie handmatig voor een API Management-exemplaar in een ondersteunde regio om redundantie te bieden voor serviceonderdelen. Wanneer u twee of meer beschikbaarheidszones selecteert die u wilt gebruiken, worden de serviceonderdelen automatisch gerepliceerd in de geselecteerde zones.
In het diagram ziet u drie vakken met het label Eenheid 1, Eenheid 2 en Eenheid 3 die zijn geïmplementeerd in een API Management-exemplaar. Elk eenheidsvak bevat twee pictogrammen die VM's vertegenwoordigen. Drie grotere vakken hebben het label Beschikbaarheidszone 1, Beschikbaarheidszone 2 en Beschikbaarheidszone 3. Zone 1 bevat eenheid 1, zone 2 bevat eenheid 2 en zone 3 bevat eenheid 3.
Zonaal: De API Management-serviceonderdelen worden geïmplementeerd in één zone die u selecteert in een Azure-regio. Alle eenheden worden in dezelfde beschikbaarheidszone geplaatst.
In het diagram ziet u twee vakken met het label Eenheid 1 en Eenheid 2 die zijn geïmplementeerd in een API Management-exemplaar. Elk eenheidsvak bevat twee pictogrammen die VM's vertegenwoordigen. Drie grotere vakken hebben het label Beschikbaarheidszone 1, Beschikbaarheidszone 2 en Beschikbaarheidszone 3. Zone 1 bevat de vakken Unit 1 en Unit 2. Zone 2 en Zone 3 bevatten geen eenheden.
Belangrijk
Maak alleen vast aan één beschikbaarheidszone als de latentie tussen zones te hoog is voor uw behoeften en nadat u hebt gecontroleerd of de latentie niet aan uw vereisten voldoet. Een zonegebonden instantie biedt zelf geen tolerantie voor een storing in de beschikbaarheidszone. Om de tolerantie van een zonegebonden API Management-implementatie te verbeteren, moet u expliciet afzonderlijke exemplaren implementeren in meerdere beschikbaarheidszones en verkeersroutering en failover configureren.
Behoeften
Regioondersteuning: API Management ondersteunt beschikbaarheidszones voor de Premium-laag (klassiek) in alle Azure-regio's die beschikbaarheidszones ondersteunen.
Laagvereiste: U moet de Premium-laag (klassiek) gebruiken om ondersteuning voor beschikbaarheidszones te configureren. API Management biedt momenteel geen ondersteuning voor beschikbaarheidszones in de klassieke lagen Verbruik, Developer, Basic en Standard of in de lagen Basic v2, Standard v2 en Premium v2. Zie Upgraden naar de klassieke Premium-laag om uw instantie naar de Premium-laag te upgraden.
Opmerking
De Premium v2-laag met enterprise-mogelijkheden is in preview. Als u wilt bepalen of uw ontwerp moet vertrouwen op functies voor vroege toegang of algemeen beschikbare mogelijkheden, evalueert u de tijdlijnen voor ontwerp en implementatie met betrekking tot de beschikbare informatie over de release- en migratiepaden van Premium v2.
Overwegingen
Aantal eenheden voor zone-redundante exemplaren: Als u zoneredundantie handmatig configureert voor een exemplaar, moet u ook een aantal API Management-eenheden configureren die gelijkmatig kunnen worden verdeeld over al uw geselecteerde beschikbaarheidszones. Als u bijvoorbeeld twee zones selecteert, moet u ten minste twee eenheden configureren. U kunt in plaats daarvan vier eenheden of een ander veelvoud van twee eenheden configureren. Als u drie beschikbaarheidszones selecteert, moet u drie eenheden, zes eenheden of een ander veelvoud van drie eenheden configureren.
Als u de automatische ondersteuning voor beschikbaarheidszones gebruikt, hoeft u geen specifiek aantal eenheden te gebruiken. De eenheden die u implementeert, worden op een best-effort manier verdeeld over de beschikbaarheidszones. Voor maximale zoneredundantie raden we u aan ten minste twee eenheden te gebruiken om ervoor te zorgen dat een storing in de beschikbaarheidszone geen invloed heeft op uw exemplaar.
Als u het aantal eenheden wilt bepalen dat de vereiste gatewayprestaties bieden, gebruikt u metrische capaciteitsgegevens en uw eigen tests. Zie Een API Management-exemplaar upgraden en schalen voor meer informatie over het schalen en upgraden van uw service-exemplaar.
Automatisch schalen: Als u beschikbaarheidszones handmatig configureert op een API Management-exemplaar dat is geconfigureerd met automatisch schalen, moet u mogelijk de instellingen voor automatisch schalen aanpassen na de configuratie. In dit geval moet het aantal API Management-eenheden in regels en limieten voor automatisch schalen een veelvoud van het aantal zones zijn. Als u de automatische ondersteuning voor beschikbaarheidszones gebruikt, hoeft u de instellingen voor automatische schaalaanpassing niet aan te passen.
Vereisten voor IP-adressen: Wanneer u ondersteuning voor beschikbaarheidszones inschakelt voor een API Management-exemplaar dat is geïmplementeerd in een extern of intern virtueel netwerk, moet u een openbare IP-adresresource opgeven voor het exemplaar dat moet worden gebruikt. In een intern virtueel netwerk wordt het openbare IP-adres alleen gebruikt voor beheerbewerkingen, niet voor API-aanvragen. Zie IP-adressen in API Management voor meer informatie.
Kosten
Ongeacht de configuratie van uw beschikbaarheidszone, als u meer eenheden toevoegt, worden er meer kosten in rekening gebracht. Zie prijzen voor API Management voor meer informatie.
Ondersteuning voor beschikbaarheidszones configureren
In deze sectie wordt uitgelegd hoe u ondersteuning voor beschikbaarheidszones configureert voor uw API Management-exemplaar.
Opmerking
Wanneer u selecteert welke beschikbaarheidszones u wilt gebruiken, selecteert u daadwerkelijk de logische beschikbaarheidszone. Als u andere workloadonderdelen in een ander Azure-abonnement implementeert, kunnen ze een ander nummer voor een logische beschikbaarheidszone gebruiken om toegang te krijgen tot dezelfde fysieke beschikbaarheidszone. Zie fysieke en logische beschikbaarheidszones voor meer informatie.
Maak een API Management-exemplaar dat ondersteuning biedt voor beschikbaarheidszones: Wanneer u een Premium (klassiek) API Management-exemplaar maakt in een regio die beschikbaarheidszones ondersteunt, ondersteunt het exemplaar standaard beschikbaarheidszones. U kunt automatische ondersteuning voor beschikbaarheidszones selecteren of zonale of zone-redundante ondersteuning handmatig configureren.
Ondersteuning voor beschikbaarheidszones inschakelen of opnieuw configureren: U kunt de configuratie van de beschikbaarheidszone voor een API Management-exemplaar wijzigen, inclusief het toevoegen van beschikbaarheidszones en het verplaatsen van een zonegebonden exemplaar tussen beschikbaarheidszones. Zie Ondersteuning voor beschikbaarheidszones inschakelen voor API Management-exemplaren om te leren hoe u ondersteuningen voor beschikbaarheidszones voor een API Management-exemplaar configureert. Er zijn geen downtimevereisten voor een van de configuratieopties.
Wanneer u de configuratie van de beschikbaarheidszone wijzigt, kunnen de wijzigingen 15 tot 45 minuten of langer duren. De API Management-gateway kan gedurende deze tijd API-aanvragen blijven verwerken.
Als u de configuratie van de beschikbaarheidszone wijzigt, wordt een wijziging in een openbaar en privé-IP-adres geactiveerd.
Capaciteitsplanning en -beheer
In een zone-down scenario is er geen garantie dat aanvragen voor meer capaciteit in een andere beschikbaarheidszone slagen. De backfilling van verloren eenheden vindt plaats op basis van best effort. Als u gegarandeerde capaciteit nodig hebt wanneer een beschikbaarheidszone mislukt, moet u uw API Management-exemplaar maken en configureren om rekening te houden met het verlies van een zone door alle volgende acties uit te voeren:
Overvoorzien de eenheden van uw API-beheerinstantie.
Gebruik een automatische of zone-redundante beschikbaarheidszoneconfiguratie.
Zie Capaciteit beheren met overinrichting voor meer informatie.
Gebruik metrische capaciteitsgegevens en uw eigen tests om het aantal eenheden te bepalen dat de vereiste gatewayprestaties biedt. Zie Een API Management-exemplaar upgraden en schalen voor meer informatie over het schalen en upgraden van uw service-exemplaar.
Gedrag wanneer alle zones in orde zijn
In deze sectie wordt beschreven wat u kunt verwachten wanneer API Management-exemplaren zijn geconfigureerd met ondersteuning voor beschikbaarheidszones en alle beschikbaarheidszones operationeel zijn.
Verkeersroutering tussen zones: Tijdens normale bewerkingen wordt verkeer gerouteerd tussen al uw beschikbare API Management-eenheden in alle geselecteerde beschikbaarheidszones.
Gegevensreplicatie tussen zones: API Management slaat de volgende gegevens op en repliceert deze.
Gatewayconfiguratie, zoals API's en beleidsdefinities, worden regelmatig gesynchroniseerd tussen de beschikbaarheidszones die u voor het exemplaar selecteert. Het doorgeven van updates tussen de beschikbaarheidszones duurt normaal gesproken minder dan 10 seconden.
Gegevens in de interne cache als u de interne cache gebruikt die API Management biedt. Cachevermeldingen worden verdeeld over beschikbaarheidszones. De interne cache is vluchtig en gegevens blijven niet gegarandeerd behouden. Overweeg het gebruik van een externe cache als u gegevens in de cache wilt behouden.
Frequentielimiettellers, als u de mogelijkheden voor snelheidsbeperking gebruikt die API Management biedt. Frequentielimiettellers worden asynchroon gerepliceerd tussen de beschikbaarheidszones die u voor het exemplaar selecteert.
Gedrag tijdens een zonefout
In deze sectie wordt beschreven wat u kunt verwachten wanneer API Management-exemplaren zijn geconfigureerd met ondersteuning voor beschikbaarheidszones en er een storing in de beschikbaarheidszone is.
Detectie en reactie: De verantwoordelijkheid voor detectie en reactie is afhankelijk van de configuratie van de beschikbaarheidszone die door uw exemplaar wordt gebruikt.
Automatisch en zone-redundant: Het API Management-platform is bijvoorbeeld geconfigureerd voor het gebruik van automatische ondersteuning voor beschikbaarheidszones of handmatig geconfigureerd voor het gebruik van zoneredundantie. Het API Management-platform is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone en reageert. U hoeft niets te doen om een zonefailover te starten.
Zonaal: Voor exemplaren die zijn geconfigureerd voor zonegebonden, moet u het verlies van een beschikbaarheidszone detecteren en een failover initiëren naar een secundair exemplaar dat u in een andere beschikbaarheidszone maakt.
Actieve aanvragen: Wanneer een beschikbaarheidszone niet beschikbaar is, worden alle aanvragen die worden uitgevoerd die zijn verbonden met een API Management-eenheid in de defecte beschikbaarheidszone beëindigd en moeten ze opnieuw worden geprobeerd.
Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. Echter:
U kunt Azure Resource Health gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.
U kunt Azure Service Health gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.
Verwachte gegevensverlies: API Management slaat de volgende gegevens op.
Gatewayconfiguratiewijzigingen, die binnen ongeveer 10 seconden worden gerepliceerd naar elke geselecteerde beschikbaarheidszone. Als er een storing optreedt in een beschikbaarheidszone, gaan mogelijk configuratiewijzigingen verloren die niet worden gerepliceerd.
Gegevens in de interne cache, als u de functie interne cache gebruikt. De interne cache is vluchtig en gegevens blijven niet gegarandeerd behouden. Tijdens een storing in de beschikbaarheidszone gaan sommige of alle gegevens in de cache verloren. Overweeg het gebruik van een externe cache als u gegevens in de cache wilt behouden.
Frequentielimiettellers, als u de functie frequentielimiet gebruikt. Tijdens een storing in een beschikbaarheidszone zijn limiettellers mogelijk niet up-tobijgewerkt in de overlevende zones.
Verwachte downtime: De verwachte downtime is afhankelijk van de configuratie van de beschikbaarheidszone die door uw exemplaar wordt gebruikt.
Automatisch: U kunt verwachten dat exemplaren die gebruikmaken van ondersteuning voor automatische beschikbaarheidszones geen downtime hebben tijdens een storing in de beschikbaarheidszone. Eenheden in de niet-getroffen zone of zones blijven werken.
U kunt ook exemplaren verwachten die gebruikmaken van automatische ondersteuning voor beschikbaarheidszones, maar één eenheid hebben, zodat er geen downtime is. In dit geval distribueert API Management de onderliggende VM's van de eenheid naar twee zones. De VM in de onaangetaste zone blijft werken.
Zone-redundant: U kunt verwachten dat zone-redundante exemplaren geen downtime hebben tijdens een storing in de beschikbaarheidszone.
Zonaal: Voor zonale exemplaren geldt dat wanneer een zone niet beschikbaar is, uw exemplaar niet beschikbaar is totdat de beschikbaarheidszone weer hersteld is.
Verkeer omleiden: Het gedrag voor het omleiden van verkeer is afhankelijk van de configuratie van de beschikbaarheidszone die door uw exemplaar wordt gebruikt.
Automatisch en zone-redundant: Exemplaren die zijn geconfigureerd voor het gebruik van automatische ondersteuning voor beschikbaarheidszones of die handmatig zijn geconfigureerd voor het gebruik van zoneredundantie, wanneer een zone niet beschikbaar is, zijn alle eenheden in de betrokken zone ook niet beschikbaar. U kunt ervoor kiezen om uw instantie op te schalen om extra eenheden toe te voegen.
Zonaal: Voor zonegebonden exemplaren geldt dat wanneer een zone niet beschikbaar is, uw exemplaar niet beschikbaar is. Als u een secundair exemplaar in een andere beschikbaarheidszone hebt, bent u verantwoordelijk voor het omleiden van verkeer naar dat secundaire exemplaar.
Zoneherstel
Het gedrag voor zoneherstel is afhankelijk van de configuratie van de beschikbaarheidszone die door uw exemplaar wordt gebruikt.
Automatisch en zone-redundant: Bijvoorbeeld exemplaren die zijn geconfigureerd voor het gebruik van automatische ondersteuning voor beschikbaarheidszones of die handmatig zijn geconfigureerd voor het gebruik van zoneredundantie, wanneer de beschikbaarheidszone wordt hersteld, herstelt API Management automatisch eenheden in de beschikbaarheidszone en routeert verkeer tussen uw eenheden als normaal.
Zonaal: Voor zonegebonden exemplaren bent u verantwoordelijk voor het opnieuw omleiden van verkeer naar het exemplaar in de oorspronkelijke beschikbaarheidszone nadat de beschikbaarheidszone is hersteld.
Testen op zonefouten
De opties voor het testen van zonefouten zijn afhankelijk van de configuratie van de beschikbaarheidszone die door uw exemplaar wordt gebruikt.
nl-NL: Automatisch en zone-redundant: Het API Management-platform beheert verkeersroutering, failover en failback voor exemplaren die zijn geconfigureerd om automatische beschikbaarheidszone-ondersteuning te gebruiken of handmatig zijn geconfigureerd om zoneredundantie te gebruiken. Deze functie wordt volledig beheerd, dus u hoeft geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren.
Zonaal: Voor zonegebonden exemplaren is er geen manier om een storing in de beschikbaarheidszone te simuleren die uw API Management-exemplaar bevat. U kunt echter handmatig upstream-gateways of load balancers configureren om verkeer om te leiden naar een ander exemplaar in een andere beschikbaarheidszone.
Tolerantie voor storingen in de hele regio
Met een implementatie met 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 elke latentie van aanvragen die wordt waargenomen door geografisch gedistribueerde API-consumenten. Een implementatie met meerdere regio's verbetert ook de beschikbaarheid van de service als één regio offline gaat.
Door Microsoft beheerde implementatie met meerdere regio's
API Management biedt alleen ondersteuning voor implementaties in meerdere regio's in de Premium-laag (klassiek). Het biedt geen ondersteuning voor implementaties in meerdere regio's in de lagen Consumption, Developer, Basic, Basic v2, Standard, Standard v2 en Premium v2 (preview). Zie Vereisten voor meer informatie.
Wanneer u een regio toevoegt, configureert u het volgende:
Het aantal eenheden dat door die regio wordt gehost.
Tolerantie voor storingen in beschikbaarheidszones als die regio beschikbaarheidszones biedt.
Instellingen voor virtuele netwerken in de toegevoegde regio, als netwerken zijn geconfigureerd in de bestaande regio of regio's.
Behoeften
Regioondersteuning: U kunt implementaties met meerdere regio's maken in de Premium-laag (klassiek) met elke Azure-regio die API Management ondersteunt. Zie Productbeschikbaarheid per regio om te zien welke regio's ondersteuning bieden voor implementaties in meerdere regio's.
Laagvereiste: U moet de Premium-laag (klassiek) gebruiken om ondersteuning voor meerdere regio's te configureren. Zie Upgraden naar de klassieke Premium-laag om uw instantie naar de Premium-laag te upgraden.
Opmerking
De Premium v2-laag met enterprise-mogelijkheden is in een preview-fase. Als u wilt bepalen of uw ontwerp moet vertrouwen op functies voor vroege toegang of algemeen beschikbare mogelijkheden, evalueert u de tijdlijnen voor ontwerp en implementatie met betrekking tot de beschikbare informatie over de release- en migratiepaden van Premium v2.
Overwegingen
Alleen gateway: 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 waar u de service oorspronkelijk hebt geïmplementeerd.
Netwerkvereisten: Als u een secundaire locatie wilt configureren voor uw API Management-exemplaar wanneer deze wordt geïmplementeerd (geïnjecteerd) in een virtueel netwerk, moeten het virtuele netwerk en de 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 virtuele IP-adres (VIP) van uw API Management-exemplaar gewijzigd. Zie Wijzigingen in IP-adressen 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.
DNS-namen (Domain Name System): 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.netbijvoorbeeldhttps://contoso-westus2-01.regional.azure-api.net.
Kosten
Voor het toevoegen van regio's worden kosten in rekening gebracht. Zie prijzen voor API Management voor meer informatie.
Ondersteuning voor meerdere regio's configureren
Zie Een API Management-serviceregio verwijderen als u een regio uit een API Management-exemplaar wilt verwijderen.
Capaciteitsplanning en -beheer
In een regio-down scenario is er geen garantie dat aanvragen voor meer capaciteit in een andere regio slagen. Als u gegarandeerde capaciteit nodig hebt wanneer een regio uitvalt, moet u uw API Management-exemplaar maken en configureren om rekening te houden met het verlies van een regio. U kunt dit doen door de capaciteit van uw API Management-exemplaar te over-inrichten. Zie Capaciteit beheren met overinrichting voor meer informatie over het principe van overinrichting.
Bij implementaties in meerdere regio's geldt automatisch schalen alleen voor de primaire regio. Voor secundaire regio's zijn handmatige schaalaanpassingen of aangepaste hulpprogramma's vereist die u bepaalt.
Gedrag wanneer alle regio's in orde zijn
In deze sectie wordt beschreven wat u kunt verwachten wanneer API Management-exemplaren zijn geconfigureerd met ondersteuning voor meerdere regio's en alle regio's operationeel zijn.
Verkeersroutering tussen regio's: API Management stuurt binnenkomende aanvragen automatisch naar een regionale gateway. Een aanvraag wordt gerouteerd naar de regionale gateway met de laagste latentie van de client. Als u een andere routeringsbenadering wilt gebruiken, kunt u uw eigen Traffic Manager configureren met aangepaste routeringsregels. Zie Aangepaste routering naar regionale API Management-gateways gebruiken voor meer informatie.
Wanneer een aanvraag een regionale API Management-gateway bereikt, wordt deze doorgestuurd naar de back-end-API, tenzij een beleid rechtstreeks vanuit de gateway een antwoord retourneert, zoals een antwoord in de cache of een foutcode. In een oplossing voor meerdere regio's moet u ervoor zorgen dat u routeert naar een exemplaar van de back-end-API die voldoet aan uw prestatievereisten. Zie Route-API-aanroepen naar regionale back-endservices voor meer informatie.
Gegevensreplicatie tussen regio's: Gatewayconfiguratie, 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.
Frequentielimiettellers en gegevens in de interne cache zijn regiospecifiek, zodat ze niet tussen regio's worden gerepliceerd.
Gedrag tijdens een regiofout
In deze sectie wordt beschreven wat u kunt verwachten wanneer API Management-exemplaren zijn geconfigureerd met ondersteuning voor meerdere regio's en er een storing is in een van de regio's die u gebruikt.
Detectie en reactie: API Management is verantwoordelijk voor het detecteren van een fout in een regio en het automatisch uitvoeren van een failover naar een gateway in een van de andere regio's die u configureert.
Actieve aanvragen: Actieve aanvragen die worden verwerkt in de defecte regio, kunnen worden verwijderd en moeten opnieuw worden geprobeerd door de client.
Verwachte gegevensverlies: API Management slaat geen gegevens op, met uitzondering van configuratie, een cache en frequentielimiettellers.
Configuratiewijzigingen worden binnen ongeveer 10 seconden gerepliceerd naar elke regio. Als er een storing optreedt in uw primaire regio, gaan mogelijk configuratiewijzigingen verloren die niet worden gerepliceerd.
Frequentielimiettellers en gegevens in de interne cache zijn regiospecifiek, zodat ze niet tussen regio's worden gerepliceerd.
Verwachte downtime: Er wordt geen downtime van de gateway verwacht.
Als de primaire regio offline gaat, worden het beheervlak van API Management en de ontwikkelaarsportal niet meer beschikbaar, maar secundaire regio's blijven API-aanvragen verwerken met behulp van de meest recente gatewayconfiguratie.
Verkeer omleiden: Als een regio offline gaat, worden API-aanvragen automatisch omgeleid rond de mislukte regio naar de dichtstbijzijnde gateway.
Regio herstel
Wanneer de primaire regio wordt hersteld, herstelt API Management automatisch eenheden in de regio en routeert het verkeer tussen uw eenheden.
Test voor regiofouten
Als u klaar wilt zijn voor onverwachte regio-storingen, raden we u aan om regelmatig uw reacties op regiofouten te testen. U kunt enkele aspecten van een regiofout simuleren door routering naar een regionale gateway uit te schakelen.
Backups en herstel
API Management slaat de meeste runtimegegevens niet op. U kunt echter een back-up maken van uw API Management-serviceconfiguratie. U kunt ook back-up- en herstelbewerkingen gebruiken voor het repliceren van API Management-serviceconfiguraties tussen operationele omgevingen, bijvoorbeeld ontwikkeling en fasering.
Belangrijk
In een back-upprocedure worden runtimegegevens zoals gebruikers en abonnementen opgenomen, wat mogelijk niet altijd wenselijk is.
Back-up wordt ondersteund in de lagen Developer, Basic, Standard en Premium.
Zie Herstel na noodgevallen implementeren met behulp van serviceback-up en herstel in API Management voor meer informatie.
Voor back-up of herstel van sommige serviceonderdelen of resources kunt u ook door de klant beheerde opties overwegen, zoals APIOps-hulpprogramma's en oplossingen voor infrastructuur als code (IaC).
Tolerantie voor serviceonderhoud
API Management voert reguliere service-upgrades en andere vormen van onderhoud uit.
In de lagen Basic, Standard en Premium (klassiek) kunt u aanpassen wanneer uw exemplaar in het updateproces een update ontvangt. Als u het effect van upgrades op uw workload wilt valideren, kunt u overwegen om een testexemplaren te configureren om updates vroeg in een updatecyclus te ontvangen en uw productie-exemplaar zo in te stellen dat deze te laat in de cyclus updates ontvangt. U kunt ook een onderhoudsvenster opgeven. Dit is het tijdstip waarop u wilt dat het exemplaar service-updates toepast.
Zie Instellingen voor service-updates configureren voor uw API Management-exemplaren voor meer informatie.
Diensteniveauovereenkomst
De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.
Wanneer u een API Management-exemplaar implementeert in meerdere beschikbaarheidszones of regio's, neemt het uptimepercentage dat is gedefinieerd in de SLA toe.
De service biedt een eigen SLA, maar u moet ook rekening houden met de verwachte betrouwbaarheid van andere workloadonderdelen, zoals de API-back-ends.