Freigeben über

Anforderungen an virtuelle Netzwerkressourcen für die API Management-Injektion in ein virtuelles Netzwerk

  • Artikel

GILT FÜR: Developer | Premium

Im Folgenden werden die Anforderungen an virtuelle Netzwerkressourcen für die API Management-Injektion in ein virtuelles Netzwerk aufgeführt. Einige Anforderungen unterscheiden sich je nach Version (stv2 oder stv1) der stv2, die Ihre API Management-Instanz hostet.

  • Ein virtuelles Azure Resource Manager-Netzwerk ist erforderlich.
  • Das Subnetz, das zur Verbindung mit der API Management-Instanz verwendet wird, kann möglicherweise andere Azure-Ressourcentypen enthalten.
  • Für das Subnetz, das zur Verbindung mit der API Management-Instanz verwendet wird, sollten keine Delegierungen aktiviert sein. Die Einstellung Subnetz an einen Dienst delegieren für das Subnetz sollte auf Keine festgelegt werden.
  • Eine Netzwerksicherheitsgruppe, die an das oben genannte Subnetz angefügt ist. Eine Netzwerksicherheitsgruppe (NSG) ist erforderlich, um eingehende Verbindungen explizit zuzulassen, da der von API Management intern verwendete Lastenausgleich standardmäßig gesichert ist und sämtlichen eingehenden Datenverkehr abgelehnt.
  • Je nachdem, ob Sie Ihre API-Verwaltungsinstanz im externen oder internen Modus in ein virtuelles Netzwerk einbinden, können Sie zusätzlich zur Angabe eines virtuellen Netzwerks und eines Subnetzes eine öffentliche IPv4-Adresse von Standard SKU angeben.
  • Der API Management-Dienst, das virtuelle Netzwerk und Subnetz sowie die öffentliche IP-Adressressource (wenn angegeben) müssen sich in derselben Region und im selben Abonnement befinden.
  • Konfigurieren Sie bei API Management-Bereitstellungen in mehreren Regionen die virtuellen Netzwerkressourcen für jeden Speicherort separat.

Subnetzgröße

Die Mindestgröße des Subnetzes, in dem API Management eingesetzt werden kann, ist /29, was drei nutzbare IP-Adressen ergibt. Jede zusätzliche Skalierungseinheit von API Management erfordert zwei weitere IP-Adressen. Die Mindestgröße basiert auf den folgenden Überlegungen:

  • Azure reserviert in jedem Subnetz fünf IP-Adressen, die nicht verwendet werden können. Die erste und letzte IP-Adresse der Subnetze sind aus Gründen der Protokollkonformität reserviert. Für Azure-Dienste werden drei weitere Adressen verwendet. Weitere Informationen finden Sie unter Unterliegen die in den Subnetzen verwendeten IP-Adressen bestimmten Beschränkungen?

  • Zusätzlich zu den von der Azure-VNet-Infrastruktur genutzten IP-Adressen verwendet jede API Management-Instanz im Subnetz folgende IP-Adressen:

    • Zwei IP-Adressen pro Einheit der Basic-, Standard- oder Premium-SKU oder
    • Eine IP-Adresse für die Entwickler-SKU

  • Beim Einsatz in einem internen virtuellen Netzwerk benötigt die Instanz eine zusätzliche IP-Adresse für den internen Lastenausgleich.

Beispiele

  • /29-Subnetz: 8 mögliche IP-Adressen - 5 reservierte Azure IP-Adressen - 2 API Management-IP-Adressen für eine Instanz - 1 IP-Adresse für den internen Lastenausgleich bei Verwendung im internen Modus = 0 verbleibende IP-Adressen für aufskalierte Einheiten

  • /28-Subnetz: 16 mögliche IP-Adressen - 5 reservierte Azure IP-Adressen - 2 API Management-IP-Adressen für eine Instanz - 1 IP-Adresse für den internen Lastenausgleich bei Verwendung im internen Modus = 8 verbleibende IP-Adressen für aufskalierte Einheiten (2 IP-Adressen/aufskalierte Einheit) für insgesamt 5 Einheiten.

  • /27-Subnetz: 32 mögliche IP-Adressen – 5 reservierte Azure-IP-Adressen – 2 API Management-IP-Adressen für eine Instanz – 1 IP-Adresse für den internen Lastenausgleich bei Verwendung im internen Modus = 24 verbleibende IP-Adressen für 12 aufskalierte Einheiten (2 IP-Adressen/aufskalierte Einheit) für insgesamt 13 Einheiten.

  • /26-Subnetz: 64 mögliche IP-Adressen – 5 reservierte Azure-IP-Adressen – 2 API Management-IP-Adressen für eine Instanz – 1 IP-Adresse für den internen Lastenausgleich bei Verwendung im internen Modus = 56 verbleibende IP-Adressen für 28 aufskalierte Einheiten (2 IP-Adressen/aufskalierte Einheit) für insgesamt 29 Einheiten.

  • /25-Subnetz: 128 mögliche IP-Adressen – 5 reservierte Azure-IP-Adressen – 2 API Management-IP-Adressen für eine Instanz – 1 IP-Adresse für den internen Lastenausgleich bei Verwendung im internen Modus = 120 verbleibende IP-Adressen für 60 aufskalierte Einheiten (2 IP-Adressen/aufskalierte Einheit) für insgesamt 61 Einheiten. Dies ist eine große theoretische Anzahl an aufskalierten Einheiten.

Hinweis

Derzeit ist es möglich, die Premium-SKU auf 31 Einheiten zu skalieren. Wenn Sie feststellen, dass sich die Nachfrage diesem Grenzwert nähert, sollten Sie das /26-Subnetz oder /25-Subnetz verwenden.

Wichtig

Die privaten IP-Adressen des internen Lastenausgleichs und der API Management-Einheiten werden dynamisch zugewiesen. Daher ist es unmöglich, die private IP-Adresse der API Management-Instanz vor der Bereitstellung vorherzusehen. Außerdem kann der Wechsel in ein anderes Subnetz und die anschließende Rückkehr zum vorherigen Subnetz zu einer Änderung der privaten IP-Adresse führen.

Routing

Lesen Sie den Routingleitfaden, wenn Sie Ihre API Management-Instanz in einem externen virtuellen Netzwerk oder internen virtuellen Netzwerk bereitstellen.

Erfahren Sie mehr über die IP-Adressen von API Management.

Domain Name System

  • Im externen Modus ermöglicht das virtuelle Netzwerk standardmäßig die von Azure bereitgestellte Namensauflösung für Ihre API Management-Endpunkte und andere Azure-Ressourcen. Für lokale Ressourcen wird die Namensauflösung nicht unterstützt. Konfigurieren Sie optional Ihre eigene DNS-Lösung.

  • Im internen Modus müssen Sie Ihre eigene DNS-Lösung bereitstellen, um die Namensauflösung für API Management-Endpunkte und andere erforderliche Azure-Ressourcen sicherzustellen. Wir empfehlen die Konfiguration einer Azure privaten DNS-Zone.

Weitere Informationen finden Sie im DNS-Leitfaden zum Bereitstellen Ihrer API Management-Instanz in einem externen virtuellen Netzwerk oder internen virtuellen Netzwerk.

Verwandte Informationen:

Wichtig

Wenn Sie planen, eine benutzerdefinierte DNS-Lösung für das VNet zu verwenden, richten Sie diese ein, bevor Sie dort einen API Management-Dienst bereitstellen. Andernfalls müssen Sie den API Management-Dienst jedes Mal aktualisieren, wenn Sie die DNS-Server ändern, indem Sie den „Netzwerkkonfiguration anwenden“-Vorgang ausführen, oder indem Sie „Netzwerkkonfiguration anwenden“ im Netzwerkkonfigurationsfenster der Dienstinstanz im Azure-Portal auswählen.

Einschränkungen

Einige virtuelle Netzwerkeinschränkungen hängen von der Version (stv2 oder stv1) der Rechenplattform ab, die Ihre API Management-Instanz hostet.

  • Ein Teilnetz, das API Management-Instanzen enthält, kann nicht über Abonnements hinweg verschoben werden.
  • Bei API Management-Bereitstellungen in mehreren Regionen mit Konfiguration im Modus für interne virtuelle Netzwerke sind die Benutzer Besitzer des Routings und dafür verantwortlich, den Lastenausgleich regionsübergreifend zu verwalten.
  • Um eine API aus einer OpenAPI-Spezifikation in API Management zu importieren, muss die Spezifikations-URL unter einer öffentlich zugänglichen Internetadresse gehostet werden.

Zugehöriger Inhalt