Partager via

Exigences en matière de ressources de réseau virtuel pour l’injection de Gestion des API dans un réseau virtuel

  • Article

S’APPLIQUE À : Développeur | Premium

Voici les exigences en matière de ressources de réseau virtuel pour l’injection de Gestion des API dans un réseau virtuel. Certaines conditions varient en fonction de la version (stv2 ou stv1) de la stv2 qui héberge votre instance Gestion des API.

  • Un réseau virtuel du Gestionnaire de ressource Azure est requis.
  • Le sous-réseau utilisé pour se connecter à l’instance Gestion des API pourrait contenir d’autres types de ressources Azure.
  • Le sous-réseau utilisé pour la connexion à l’instance Gestion des API ne doit avoir aucune délégation activée. Le paramètre Déléguer le sous-réseau à un service pour le sous-réseau doit être défini sur Aucun.
  • Un groupe de sécurité réseau associé au sous-réseau ci-dessus. Un groupe de sécurité réseau (NSG) est nécessaire pour autoriser explicitement la connectivité entrante, car l’équilibreur de charge utilisé en interne par Gestion des API est sécurisé par défaut et rejette tout le trafic entrant.
  • Selon que vous injectez votre instance Gestion des API dans un réseau virtuel en mode externe ou en mode interne, vous pouvez fournir une adresse IPv4 publique de référence SKU Standard en plus de spécifier un réseau virtuel et un sous-réseau.
  • Le service de Gestion des API, le réseau virtuel et le sous-réseau, ainsi que la ressource de l’adresse IP publique (si fournie) doivent se trouver dans la même région et le même abonnement.
  • Pour les déploiements de Gestion des API dans plusieurs régions, configurez les ressources de réseau virtuel séparément pour chaque emplacement.

Taille du sous-réseau

La taille minimale du sous-réseau dans lequel Gestion des API peut être déployée est de /29, ce qui fournit trois adresses IP utilisables. Chaque unité d’échelle supplémentaire de Gestion des API requiert deux adresses IP supplémentaires. La taille minimale requise est basée sur les considérations suivantes :

  • Azure réserve dans chaque sous-réseau cinq adresses IP qui ne peuvent pas être utilisées. La première et la dernière adresses IP des sous-réseaux sont réservées à des fins de conformité du protocole. Trois adresses supplémentaires sont utilisées pour les services Azure. Pour plus d’informations, consultez la section L’utilisation des adresses IP au sein de ces sous-réseaux est-elle soumise à des restrictions ?.

  • Outre les adresses IP utilisées par l’infrastructure de réseau virtuel Azure, chaque instance de Gestion des API du sous-réseau utilise :

    • deux adresses IP par unité de référence SKU De base, Standard ou Premium, ou
    • une adresse IP pour la référence SKU du développeur.

  • Lors du déploiement dans un réseau virtuel interne, l’instance requiert une adresse IP supplémentaire pour l’équilibreur de charge interne.

Exemples

  • Sous-réseau /29 : 8 adresses IP possibles - 5 adresses IP Azure réservées - 2 adresses IP Gestion des API pour une instance - 1 adresse IP pour l’équilibreur de charge interne, si elles sont utilisées en mode interne = 0 adresse IP restante laissée pour les unités de scale-out.

  • Sous-réseau /28 : 16 adresses IP possibles - 5 adresses IP Azure réservées - 2 adresses IP Gestion des API pour une instance - 1 adresse IP pour l’équilibreur de charge interne, si elles sont utilisées en mode interne = 8 adresses IP restantes laissées pour quatre unités de scale-out (2 adresses IP/unité de scale-out) pour un total de cinq unités.

  • Sous-réseau /27 : 32 adresses IP possibles - 5 adresses IP Azure réservées - 2 adresses IP Gestion des API pour une instance - 1 adresse IP pour l’équilibreur de charge interne, si elles sont utilisées en mode interne = 24 adresses IP restantes laissées pour 12 unités de scale-out (2 adresses IP/unité de scale-out) pour un total de 13 unités.

  • Sous-réseau /26 : 64 adresses IP possibles - 5 adresses IP Azure réservées - 2 adresses IP Gestion des API pour une instance - 1 adresse IP pour l’équilibreur de charge interne, si elles sont utilisées en mode interne = 56 adresses IP restantes laissées pour 28 unités de scale-out (2 adresses IP/unité de scale-out) pour un total de 29 unités.

  • Sous-réseau /25 : 128 adresses IP possibles - 5 adresses IP Azure réservées - 2 adresses IP Gestion des API pour une instance - 1 adresse IP pour l’équilibreur de charge interne, si elles sont utilisées en mode interne = 120 adresses IP restantes laissées pour 60 unités de scale-out (2 adresses IP/unité de scale-out) pour un total de 61 unités. Il s’agit d’un nombre théorique important d’unités de scale-out.

Remarque

Il est actuellement possible de mettre à l’échelle la référence SKU Premium à 31 unités. Si vous prévoyez que la demande approche de cette limite, considérez le sous-réseau /26 ou /25 envoyer.

Important

Les adresses IP privées de l’équilibreur de charge interne et des unités Gestion des API sont attribuées dynamiquement. Par conséquent, il est impossible d’anticiper l’adresse IP privée de l’instance Gestion des API avant son déploiement. En outre, le changement vers un autre sous-réseau, puis le retour pourraient entraîner une modification de l’adresse IP privée.

Routage

Consultez le Guide de routage lors du déploiement de votre instance de Gestion des API dans un réseau virtuel externe ou réseau virtuel interne.

En savoir plus sur les adresses IP de Gestion des API.

DNS

  • En mode externe, le réseau virtuel active la résolution de noms fournie par Azure par défaut pour vos points de terminaison de la Gestion des API et autres ressources Azure. Il ne fournit pas de résolution de noms pour les ressources locales. Éventuellement, configurez votre propre solution DNS.

  • En mode interne, vous devez fournir votre propre solution DNS pour garantir la résolution de noms pour les points de terminaison de la Gestion des API et autres ressources Azure requises. Nous vous recommandons de configurer une zone DNS privéeAzure.

Pour plus d’informations, consultez le Guide DNS lors du déploiement de votre instance de Gestion des API dans un réseau virtuel externe ou réseau virtuel interne.

Informations connexes :

Important

Si vous envisagez d’utiliser une solution DNS personnalisée pour le réseau virtuel VNet, configurez-la avant de déployer un service de Gestion des API dans celui-ci. Dans le cas contraire, vous allez devoir mettre à jour le service Gestion des API chaque fois que vous modifiez le ou les serveurs DNS en exécutant l’opération Appliquer la configuration du réseau, ou en sélectionnant Appliquer la configuration réseau dans la fenêtre de configuration réseau de l’instance de service dans le Portail Azure.

Limites

Certaines limitations des réseaux virtuels varient en fonction de la version (stv2 ou stv1) de la plateforme de calcul qui héberge votre instance de Gestion des API.

  • Un sous-réseau contenant des instances du service de Gestion des API ne peut pas être déplacé entre des abonnements.
  • Pour les déploiements du service Gestion des API dans plusieurs régions configurés en mode de réseau virtuel interne, les utilisateurs possèdent le routage et sont chargés de gérer leur équilibrage de charge entre les différentes régions.
  • Pour importer une API dans la Gestion des API à partir d’une spécification OpenAPI, l’URL de la spécification doit être hébergée sur une adresse Internet publiquement accessible.

Contenu connexe