Share via


Vereisten voor netwerkresources voor API Management-injectie in een virtueel netwerk

VAN TOEPASSING OP: Ontwikkelaar | Premie

Hier volgen de resourcevereisten voor virtuele netwerken voor het injecteren van een API Management Developer- of Premium-exemplaar in een virtueel netwerk.

Notitie

Als u een Premium v2-exemplaar in een virtueel netwerk wilt injecteren, zijn de vereisten en configuratie anders. Meer informatie

  • 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 delegatie hebben ingeschakeld. De instelling 'Subnet delegeren aan een service' 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.

Notitie

Bij het overwegen van een subnetgrootte is het raadzaam om voorzichtig te zijn vanwege de integrale rol die API Management doorgaans bevat. Overweeg groei en schaalvergroting bij het bepalen van de grootte.

Voorbeelden

In de volgende tabel ziet u voorbeelden van subnetgrootten voor injectie van virtuele API Management-netwerken, waarin wordt aangegeven hoe verschillende CIDR-blokken van invloed zijn op het aantal schaaleenheden dat mogelijk is:

Subnet CIDR Totaal aantal IP-adressen Gereserveerde IP-adressen van Azure IP-adressen van API Management-exemplaren IP van interne load balancer Resterende IP-adressen voor uitschalen Maximum aantal uitschaaleenheden Maximale totaal aantal eenheden
/29 8 5 2 1 0 0 1
/28 16 5 2 1 8 4 5
/27 32 5 2 1 24 12 13
/26 64 5 2 1 56 28 29
/25 128 5 2 1 120 60* 61*

Belangrijkste punten

  • Minimale subnetgrootte: /29 (biedt 3 bruikbare IP-adressen voor API Management)
  • Gereserveerde IP-adressen van Azure: 5 adressen per subnet (eerste en laatste voor protocolconformance, plus 3 voor Azure-services)
  • Uitschaalvereiste: Voor elke uitschaaleenheid zijn 2 IP-adressen vereist
  • Interne load balancer: alleen vereist wanneer API Management wordt geïmplementeerd in de modus intern virtueel netwerk
  • Premium-SKU-limiet: * Ondersteunt momenteel maximaal 31 eenheden maximum
  • Aanbevolen grootte: voor grootschalige scenario's die de Limiet van de Premium-SKU naderen, kunt u overwegen /26 of /25-subnetten

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 (Domeinnaamsysteem)

  • In de externe modus biedt het virtuele netwerk standaard Azure-naamomzetting voor uw API Management-onderdelen en andere Azure-resources. Het biedt geen naamresolutie voor on-premises middelen. 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

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