Analyse approfondie de la mise en réseau du service Foundry Agent.

Lorsque vous exécutez le Service de l'agent Foundry avec un réseau virtuel (VNet), vous êtes responsable du dimensionnement du sous-réseau délégué, de la planification de l'allocation d'adresses IP, et de la compréhension du flux de trafic des agents via la plateforme. Cet article explique l’architecture réseau derrière les agents hébergés et invités, le modèle d’allocation IP et les signaux qui indiquent des problèmes de capacité. Il est destiné aux architectes cloud et réseau qui ont déjà choisi un réseau virtuel bring-your-own pour Service de l'agent Foundry. Pour configurer le réseau, consultez Configurer la mise en réseau privée pour le service Foundry Agent.

Si vous utilisez un agent de codage comme GitHub Copilot pour planifier votre réseau virtuel, votre sous-réseau et votre modèle de capacité, la compétence Microsoft Foundry peut vous aider à raisonner par le biais de l’architecture et à appliquer des conseils de mise en réseau Foundry dans votre propre environnement.

Vue d’ensemble de l’architecture réseau

Le diagramme suivant montre les deux zones impliquées dans toute demande de service de l’agent Foundry : le réseau de plateforme Foundry géré par Microsoft à gauche et votre réseau virtuel client à droite.

Le réseau de plateforme héberge le point de terminaison Foundry, la couche hôte de machine virtuelle Micro qui exécute des agents hébergés, le service Outils et la couche hôte du proxy de données. Votre réseau virtuel client contient un sous-réseau délégué (où les machines virtuelles Micro et le proxy de données consomment des adresses IP) et un sous-réseau de point de terminaison privé qui se connecte à votre stockage, bases de données et Key Vault.

Deux flux de requête parcourent cette architecture :

• Agent hébergé : du point de terminaison client au point de terminaison de Foundry à la micro-machine virtuelle (/invoke) au service d'outils, au proxy de données et aux ressources client via des points de terminaison privés.
• Agent d’invite : point de terminaison client vers le point de terminaison Foundry vers le service Outils vers le proxy de données vers les ressources des clients via des points de terminaison privés. Il n’existe aucune machine virtuelle Micro sur ce chemin.

Concepts clés

Flux de trafic

Chaque demande de Service de l'agent Foundry entre sur le point de terminaison Foundry et accède à vos ressources client via des points de terminaison privés. Le type d’agent détermine ce qui se passe entre les deux.

Entrant vers le point de terminaison Foundry

Les clients envoient des requêtes HTTPS à votre point de terminaison Foundry (par exemple). <your-resource>.services.ai.azure.com La passerelle d’API de la plateforme authentifie la requête et l’achemine en fonction du type d’agent cible.

Chemin d’accès de l’agent hébergé

Pour un agent hébergé, la plateforme transfère la requête à une machine virtuelle Micro dans votre sous-réseau délégué via le /invoke protocole. La machine virtuelle Micro a deux interfaces réseau :

Même si la machine virtuelle Micro possède sa propre carte réseau, tout appel d’outil est acheminé via le proxy de données.

Chemin de l'agent de commande

Pour un agent déclencheur, l’agent s’exécute dans un environnement de calcul géré par Microsoft. Le point de terminaison Foundry transfère la requête directement au service Outils, qui appelle le proxy de données monolocataire. Les adresses IP sont allouées au niveau du projet. Par conséquent, tous les agents d’invite d’un projet partagent la même infrastructure de proxy de données.

Accès aux ressources du client

Le trafic sortant à partir du proxy de données atteint vos comptes de stockage, bases de données et Key Vault via des points de terminaison privés dans votre sous-réseau de point de terminaison privé. Configurez les zones de DNS privé correspondantes (par exemple, privatelink.blob.core.windows.net, privatelink.database.windows.net et privatelink.vaultcore.azure.net) afin que la résolution de noms reste à l’intérieur du VNet.

Dimensionnement de sous-réseau et allocation IP

La configuration du sous-réseau s’applique au niveau du compte Foundry. Tous les projets du compte partagent la même configuration de sous-réseau, et les agents hébergés et invités partagent le même sous-réseau délégué. La taille recommandée doit couvrir l’utilisation combinée d’adresses IP à partir d’agents dans tous les projets, mises à niveau de plateforme et événements de mise à l’échelle.

Taille de sous-réseau recommandée

Utilisez une plage CIDR /24 pour les charges de travail de production. Un sous-réseau /27 peut fonctionner pour des déploiements plus petits, mais il laisse très peu de place. Les mises à niveau de plateforme, les déploiements et les événements de mise à l’échelle nécessitent tous des adresses IP supplémentaires temporaires, et un petit sous-réseau peut être épuisé pendant ces opérations.

Plages d’adresses IP prises en charge

Votre sous-réseau doit utiliser des plages IPv4 privées RFC 1918 uniquement :

• 10.0.0.0/8
• 172.16.0.0/12 (couvre de 172.16.x.x à 172.31.x.x)
• 192.168.0.0/16

Les plages d’adresses IP publiques et les plages CGNAT (par exemple) 100.64.0.0/10ne sont pas prises en charge et provoquent des échecs de routage.

Comment les adresses IP sont consommées

Les adresses IP sont réservées à environ 1 IP pour 10 pods. Chaque projet Foundry dispose d'un proxy de données qui démarre avec 1 pod (1 réplique) et s'ajuste à la demande de trafic.

La capacité du projet est dynamique, car un trafic plus important par projet consomme davantage d'adresses IP.

Taille du sous-réseau et sessions simultanées

Le nombre de sessions d'agent simultanées disponibles par abonnement varie selon la région. Par défaut, les sessions simultanées et les adresses IP de sous-réseau utilisables mappent 1:1, sous réserve de la limite de votre région.

Avec le mappage par défaut 1:1, utilisez un sous-réseau /26 ou plus pour prendre en charge 50 sessions simultanées.

Pour prendre en charge des sessions simultanées avec le même sous-réseau, créez une demande de support Azure. Dans la demande, spécifiez l’abonnement, la région et le nombre attendu de sessions simultanées. En fonction de vos besoins et de votre capacité régionale, la prise en charge peut augmenter le mappage à 10 sessions simultanées par adresse IP utilisable (1:10).

capacité du projet

Une instance Foundry prend en charge environ 250 projets à faible trafic. Sous un trafic lourd, lorsque les agents sont redimensionnés en de nombreux réplicas, la limite effective peut descendre à aussi peu que ~25 projets. Lorsque les adresses IP sont épuisées, le nouvel approvisionnement de projet échoue.

Comportement pendant la maintenance de la plateforme

Les mises à niveau de plateforme exécutent l’ancienne et la nouvelle infrastructure en parallèle, ce qui augmente temporairement la consommation d’adresses IP. Un sous-réseau /24 fournit suffisamment de mémoire tampon pour gérer ces pics temporaires en même temps que vos charges de travail normales. Les mises à niveau de l’infrastructure sont entièrement gérées par Microsoft, y compris leur minutage.

Comportement réseau des agents hébergés

Les agents hébergés s’exécutent sur Azure Container Apps et vous permettent de contrôler la configuration du processeur et de la mémoire. Vous les déployez via votre propre Azure Container Registry.

Révisions et utilisation des adresses IP

Lorsque vous déployez une mise à jour (nouvelle image, configuration ou code), la plateforme crée une nouvelle révision. Pendant le déploiement, les anciennes et nouvelles révisions s’exécutent en parallèle alors que le trafic passe à la nouvelle version et consomme des adresses IP de votre sous-réseau.

Limites de révision par agent hébergé :

• 100 révisions actives par agent.
• 1 000 révisions totales par nom de l’agent. Les révisions inactives les plus anciennes sont automatiquement purgées lorsque la limite active est atteinte.
• Environ 200 agents hébergés par instance Foundry.

La limite de 200 agents hébergés est distincte de la limite d’environ 250 projets, qui s’applique à l’échelle de l’instance pour tous les types d'agents.

Connectivité sortante

Chaque agent hébergé s’exécute dans une machine virtuelle Micro attachée à votre sous-réseau délégué avec une interface réseau dédiée et utilise sa propre adresse IP pour la communication sortante. Les appels d’outils passent toujours par le proxy de données monolocataire. Pour les déploiements de l’agent de code source, l’étape d’approvisionnement nécessite également un accès sortant à des points de terminaison spécifiques. Consultez la configuration requise pour le pare-feu pour les réseaux virtuels privés.

Performances et mise à l’échelle

La mise à l’échelle des agents hébergés n’introduit pas de latence ni de dégradation des performances. Le seul scénario où les performances sont affectées est lorsque l’épuisement des adresses IP empêche la mise à l’échelle de la plateforme, ce qui est évité avec le dimensionnement de sous-réseau approprié. Les agents hébergés prennent en charge les configurations de processeur et de mémoire personnalisées. Vous sélectionnez parmi les paires processeur et mémoire disponibles lorsque vous créez une version de l’agent.

Comportement réseau des agents rapides

Les agents de traitement s'exécutent également sur Azure Container Apps, mais Microsoft gère entièrement le calcul et la mise à l'échelle. Vous ne configurez pas le processeur ou la mémoire.

Révisions et utilisation des adresses IP

Contrairement aux agents hébergés, les révisions des agents de prompt ne consomment pas d’adresses IP. Le proxy de données s’exécute en mode révision unique, de sorte que les révisions inactives n’ont aucun impact sur la disponibilité ip.

Connectivité sortante

Les agents prompts utilisent le proxy de données monolocataire pour toute connectivité sortante. Les adresses IP sont allouées au niveau du projet. Par conséquent, tous les agents d’invite d’un projet partagent la même infrastructure de proxy de données.

Limites et performances

Il n’existe aucune limite stricte sur le nombre d’agents d’invite que vous pouvez déployer par instance Foundry. Étant donné que le calcul et la mise à l’échelle sont entièrement gérés, il n’existe aucun problème de latence ou de performances attendu lié au nombre d’agents d’invite déployés.

Peering de VNet et chevauchement d'IP

Les plages d’adresses IP qui se chevauchent provoquent des échecs de routage. Par conséquent, tous les réseaux virtuels appairés doivent utiliser des plages d’adresses IP uniques et qui ne se chevauchent pas. Cette règle s’applique également aux configurations de peering bidirectionnel. Seules les plages IPv4 privées RFC 1918 sont prises en charge. Les adresses CGNAT (par exemple, 100.x.x.x) ne le sont pas.

Si vous ne pouvez pas éviter le chevauchement d’adresses IP, utilisez un réseau virtuel managé au lieu d’apporter votre propre réseau virtuel. Le réseau virtuel managé automatise la configuration du réseau et élimine les problèmes de chevauchement d’adresses IP.

Surveiller l’utilisation de l’adresse IP et détecter l’épuisement

Le portail Azure n'expose actuellement pas l'utilisation ip pour les sous-réseaux délégués. Vous ne pouvez donc pas le surveiller directement. Les principaux indicateurs d’épuisement des adresses IP sont des erreurs HTTP 5xx provenant du proxy de données et, pour les agents hébergés, les échecs de création de session (erreurs 4xx). Lorsque les adresses IP sont épuisées, la mise à l’échelle du proxy de données et le nouvel approvisionnement de projet échouent, et les agents hébergés ne peuvent pas allouer de machine virtuelle Micro pour les nouvelles sessions. Surveillez l’état du proxy de données et la réussite de la création de sessions de l’Agent hébergé comme indicateurs avancés de problèmes de capacité.

Envisagez de déployer une nouvelle instance Foundry avec un nouveau sous-réseau lorsque vous observez :

• Le proxy de données retourne des erreurs 5xx.
• Échec de la création de session de l’agent hébergé avec des erreurs 4xx.
• Nouveaux échecs d’approvisionnement de projet.

Informations de référence rapides

Contenu connexe

• Configurer la mise en réseau privée pour le service Foundry Agent
• Agents hébergés dans le service Agent Foundry
• Réseau virtuel managé
• Configurer une liaison privée