Vereisten voor netwerkresources voor API Management-injectie in een virtueel netwerk
VAN TOEPASSING OP: Ontwikkelaar | Premie
Hier volgen de resourcevereisten voor virtuele netwerken voor API Management-injectie in een virtueel netwerk. Sommige vereisten verschillen, afhankelijk van de versie (stv2 of stv1) van het rekenplatform dat als host fungeert voor uw API Management-exemplaar.
- Er is een virtueel Azure Resource Manager-netwerk vereist.
- Het subnet dat wordt gebruikt om verbinding te maken met het API Management-exemplaar kan andere Azure-resourcetypen bevatten.
- Het subnet dat wordt gebruikt om verbinding te maken met het API Management-exemplaar, mag geen delegaties zijn ingeschakeld. Het subnet Delegeren naar een service-instelling voor het subnet moet worden ingesteld op Geen.
- Een netwerkbeveiligingsgroep die is gekoppeld aan het bovenstaande subnet. Een netwerkbeveiligingsgroep (NSG) is vereist om binnenkomende connectiviteit expliciet toe te staan, omdat de load balancer die intern door API Management wordt gebruikt, standaard beveiligd is en al het binnenkomende verkeer weigert.
- Afhankelijk van of u uw API Management-exemplaar in een virtueel netwerk in de externe modus of interne modus injecteert, kunt u een openbaar IPv4-standaard-SKU-adres opgeven naast het opgeven van een virtueel netwerk en subnet.
- De API Management-service, het virtuele netwerk en het subnet en het openbare IP-adres (indien opgegeven) moeten zich in dezelfde regio en hetzelfde abonnement bevinden.
- Configureer voor API Management-implementaties met meerdere regio's afzonderlijk resources voor virtuele netwerken voor elke locatie.
Subnetgrootte
De minimale grootte van het subnet waarin API Management kan worden geïmplementeerd, is /29, dat drie bruikbare IP-adressen biedt. Voor elke extra schaaleenheid van API Management zijn nog twee IP-adressen vereist. De minimale groottevereiste is gebaseerd op de volgende overwegingen:
Azure reserveert vijf IP-adressen binnen elk subnet dat niet kan worden gebruikt. De eerste en laatste IP-adressen van de subnetten zijn gereserveerd voor de naleving van protocollen. Er worden nog drie adressen gebruikt voor Azure-services. Zie Zijn er beperkingen voor het gebruik van IP-adressen binnen deze subnetten? voor meer informatie.
Naast de IP-adressen die worden gebruikt door de infrastructuur van het virtuele Azure-netwerk, maakt elke API Management-instantie in het subnet gebruik van:
- Twee IP-adressen per eenheid van Basic, Standard of Premium SKU, of
- Eén IP-adres voor de ontwikkelaars-SKU.
Bij de implementatie in een intern virtueel netwerk vereist het exemplaar een extra IP-adres voor de interne load balancer.
Voorbeelden
/29 subnet: 8 mogelijke IP-adressen - 5 gereserveerde Azure-IP-adressen - 2 API Management IP-adressen voor één exemplaar - 1 IP-adres voor interne load balancer, indien gebruikt in de interne modus = 0 resterende IP-adressen die overblijven voor uitschaaleenheden.
/28 subnet: 16 mogelijke IP-adressen - 5 gereserveerde Azure-IP-adressen - 2 API Management-IP-adressen voor één exemplaar- 1 IP-adres voor interne load balancer, indien gebruikt in de interne modus = 8 resterende IP-adressen voor vier uitschaaleenheden (2 IP-adressen/uitschaaleenheid) voor in totaal vijf eenheden.
/27 subnet: 32 mogelijke IP-adressen - 5 gereserveerde Azure-IP-adressen - 2 API Management IP-adressen voor één exemplaar - 1 IP-adres voor interne load balancer, indien gebruikt in de interne modus = 24 resterende IP-adressen voor 12 uitschaaleenheden (2 IP-adressen/uitschaaleenheid) voor een totaal van 13 eenheden.
/26 subnet: 64 mogelijke IP-adressen - 5 gereserveerde Azure-IP-adressen - 2 API Management-IP-adressen voor één exemplaar - 1 IP-adres voor interne load balancer, indien gebruikt in de interne modus = 56 resterende IP-adressen die overblijven voor 28 uitschaaleenheden (2 IP-adressen/uitschaaleenheid) voor een totaal van 29 eenheden.
/25 subnet: 128 mogelijke IP-adressen - 5 gereserveerde Azure IP-adressen - 2 API Management IP-adressen voor één exemplaar - 1 IP-adres voor interne load balancer, indien gebruikt in de interne modus = 120 resterende IP-adressen voor 60 uitschaaleenheden (2 IP-adressen/uitschaaleenheid) voor in totaal 61 eenheden. Dit is een groot, theoretisch aantal uitschaaleenheden.
Notitie
Het is momenteel mogelijk om de Premium-SKU te schalen naar 31 eenheden. Als u verwacht dat de vraag deze limiet nadert, kunt u het /26-subnet of /25-subnet overwegen.
Belangrijk
De privé-IP-adressen van interne load balancer- en API Management-eenheden worden dynamisch toegewezen. Daarom is het onmogelijk om te anticiperen op het privé-IP-adres van het API Management-exemplaar vóór de implementatie. Daarnaast kan het wijzigen van een ander subnet en vervolgens retourneren een wijziging in het privé-IP-adres veroorzaken.
Routering
Zie de richtlijnen voor routering bij het implementeren van uw API Management-exemplaar in een extern virtueel netwerk of intern virtueel netwerk.
Meer informatie over de IP-adressen van API Management.
DNS
In de externe modus schakelt het virtuele netwerk standaard azure-naamomzetting in voor uw API Management-eindpunten en andere Azure-resources. Het biedt geen naamomzetting voor on-premises resources. Configureer eventueel uw eigen DNS-oplossing.
In de interne modus moet u uw eigen DNS-oplossing opgeven om naamomzetting voor API Management-eindpunten en andere vereiste Azure-resources te garanderen. U wordt aangeraden een privé-DNS-zone van Azure te configureren.
Zie de DNS-richtlijnen voor het implementeren van uw API Management-exemplaar in een extern virtueel netwerk of intern virtueel netwerk voor meer informatie.
Verwante informatie:
Belangrijk
Als u van plan bent een aangepaste DNS-oplossing voor het VNet te gebruiken, stelt u deze in voordat u een API Management-service erin implementeert. Anders moet u de API Management-service bijwerken telkens wanneer u de DNS-server(s) wijzigt door de bewerking Netwerkconfiguratie toepassen uit te voeren of door netwerkconfiguratie toepassen te selecteren in het netwerkconfiguratievenster van het service-exemplaar in Azure Portal.
Beperkingen
Sommige beperkingen voor virtuele netwerken verschillen, afhankelijk van de versie (stv2 of stv1) van het rekenplatform dat als host fungeert voor uw API Management-exemplaar.
- Een subnet met API Management-exemplaren kan niet worden verplaatst tussen abonnementen.
- Voor API Management-implementaties met meerdere regio's die zijn geconfigureerd in de modus intern virtueel netwerk, zijn gebruikers eigenaar van de routering en zijn ze verantwoordelijk voor het beheren van de taakverdeling in meerdere regio's.
- Als u een API wilt importeren in API Management vanuit een OpenAPI-specificatie, moet de specificatie-URL worden gehost op een openbaar toegankelijk internetadres.