Uitgebreide informatie over het netwerk van Foundry Agent Service

Wanneer u Microsoft Foundry Agent Service uitvoert met een bring-your-own virtual network (VNet), bent u verantwoordelijk voor het aanpassen van de grootte van het gedelegeerde subnet, het plannen van IP-toewijzing en het begrijpen hoe het verkeer van agents via het platform stroomt. In dit artikel wordt de netwerkarchitectuur achter gehoste en promptagenten, het IP-toewijzingsmodel en de signalen uitgelegd die wijzen op capaciteitsproblemen. Het is bedoeld voor cloud- en netwerkarchitecten die al bring-your-own VNet voor Foundry Agent Service hebben gekozen. Zie Privénetwerken instellen voor Foundry Agent Service om het netwerk te configureren.

Als u een coderingsagent zoals GitHub Copilot gebruikt om uw VNet- en subnet- en capaciteitsmodel te plannen, kan de Microsoft Foundry Skill u helpen om de architectuur te doorlopen en foundry-netwerkrichtlijnen toe te passen in uw eigen omgeving.

Overzicht van netwerkarchitectuur

In het volgende diagram ziet u de twee zones die betrokken zijn bij een Foundry Agent Service-aanvraag: het Microsoft beheerde Foundry-platformnetwerk aan de linkerkant en uw klant-VNet aan de rechterkant.

Architectuurdiagram dat links het Foundry-platformnetwerk toont met het Foundry-endpoint, een Micro VM-hostlaag, de Tools Service en de Data Proxy-hostlaag. Aan de rechterkant bevat het klant-VNet een gedelegeerd subnet met Micro VM's en de Data Proxy op Azure Container Apps, plus een afzonderlijk subnet voor privé-eindpunten voor opslag, SQL Database en Key Vault. Pijlen tonen dat Hosted agent-verkeer via de Micro VM loopt en dat prompt agent-verkeer rechtstreeks via de Tools Service loopt. Beide paden komen samen bij de Data Proxy en gaan via privé-eindpunten uitgaand naar klantresources.

Het platformnetwerk biedt onderdak aan het Foundry-eindpunt, de Micro VM-hostlaag waarop Hosted-agents worden uitgevoerd, de Tools Service en de Data Proxy-hostlaag. Uw klant-VNet bevat een gedelegeerd subnet (waarbij micro-VM's en de gegevensproxy IP-adressen verbruiken) en een privé-eindpuntsubnet dat verbinding maakt met uw opslag, databases en Key Vault.

Twee aanvraagstromen doorlopen deze architectuur:

  • Gehoste agent: Client naar Foundry-eindpunt naar Micro-VM (/invoke) naar Tools Service to Data Proxy naar klantbronnen via privé-eindpunten.
  • Promptagent: Client naar Foundry-eindpunt naar Tools Service naar Data Proxy naar klantbronnen via privé-eindpunten. Er is geen Micro-VM op dit pad.

Sleutelbegrippen

Termijn Wat betekent het?
Foundry-exemplaar Uw Microsoft Foundry-resource. De container op het hoogste niveau met uw projecten, agents en netwerkconfiguratie.
Gehoste agent Een agent die u zelf bouwt en implementeert met behulp van uw eigen containerinstallatiekopieën via Azure Container Registry. U bepaalt de CPU, het geheugen en de code. Wordt uitgevoerd op Azure Container Apps.
Promptagent Een agent waarbij berekeningen en schalen volledig worden beheerd door Microsoft. U definieert gedrag via configuratie. Er zijn geen containerafbeeldingen of beheer van infrastructuur vereist.
Gegevensproxy met één tenant Een platformbeheerd netwerkonderdeel dat is toegewezen aan uw Foundry-project dat uitgaande connectiviteit voor uw agents afhandelt. Elk project krijgt een eigen exemplaar van een geïsoleerde gegevensproxy. Alle oproepen van hulpprogramma's worden via de proxy voor gegevens geleid.
Hulpprogrammaserver Een back-endservice die is geregistreerd op projectniveau die uw agents kunnen aanroepen om acties uit te voeren, zoals het uitvoeren van query's op een database of het aanroepen van een externe API. In bring-your-own VNet-configuraties wordt het verkeer van de server geleid via de enkele-tenant dataproxy.
Gedelegeerd subnet Het subnet in uw VNet dat u delegeert aan Foundry Agent Service. Alle agent-infrastructuur (gegevensproxy's en micro-VM's) wordt geïmplementeerd in dit subnet en maakt gebruik van IP-adressen ervan.
Micro-VM De lichtgewicht virtuele machine waarop een gehoste agent wordt uitgevoerd.
Versie Een wijziging die van invloed is op de uitvoering van uw agent, zoals nieuwe code, een nieuwe containerinstallatiekopieën of een configuratie-update. Alleen wijzigingen die invloed hebben op runtime, maken een nieuwe versie.
Herziening De uitrol-eenheid voor uw agent. Een revisie kan worden geverversioneerd (gekoppeld aan een runtimewijziging) of niet-geverversioneerd (wijzigingen in alleen metagegevens, zoals tags of schaalinstellingen).

Hoe verkeer stroomt

Elke Agentverzoek voor de Foundry-service komt binnen bij het Foundry-eindpunt en wordt naar uw klantbronnen geleid via privé-eindpunten. Het agenttype bepaalt wat er tussendoor gebeurt.

Inkomend naar het Foundry-eindpunt

Clients verzenden HTTPS-aanvragen naar uw Foundry-eindpunt (bijvoorbeeld <your-resource>.services.ai.azure.com). De API-gateway van het platform verifieert de aanvraag en routeert deze op basis van het type doelagent.

Pad naar gehoste agent

Voor een gehoste agent stuurt het platform de aanvraag door naar een micro-VM in uw gedelegeerde subnet via het /invoke protocol. De micro-VM heeft twee netwerkinterfaces:

Verkeerstype Route
Het eigen uitgaande verkeer van de agent Direct, via de toegewezen NIC van de micro-VM in het gedelegeerde subnet.
Aanroepen van hulpprogrammaservers Via de gegevensproxy met één tenant, ongeacht het type agent.

Hoewel de Micro VM een eigen NIC heeft, wordt elke toolaanroep gerouteerd via de data proxy.

Pad naar promptagent

Voor een promptagent wordt de agent uitgevoerd in Microsoft beheerde compute. Het Foundry-eindpunt stuurt de aanvraag rechtstreeks door naar de Tools-service, die de gegevensproxy met één tenant aanroept. IP-adressen worden toegewezen op projectniveau, zodat alle promptagents binnen een project dezelfde gegevensproxy-infrastructuur delen.

Uitgaande toegang naar klantbronnen

Via privé-eindpunten in het subnet van uw privé-eindpunt bereikt het uitgaande verkeer van de gegevensproxy uw opslagaccounts, databases en Key Vault. Configureer de bijbehorende Privé-DNS Zones (bijvoorbeeld privatelink.blob.core.windows.net, privatelink.database.windows.net en privatelink.vaultcore.azure.net), zodat naamresolutie binnen het VNet blijft.

Grootte en IP-toewijzing van subnetten

De subnetconfiguratie is van toepassing op het niveau van het Foundry-account. Alle projecten in het account delen dezelfde subnetconfiguratie en gehoste en promptagenten delen hetzelfde gedelegeerde subnet. De aanbevolen grootte moet betrekking hebben op gecombineerd IP-gebruik van agents in elk project, platformupgrades en schaalgebeurtenissen.

Gebruik een /24 CIDR-bereik voor productieworkloads. Een /27-subnet kan voor kleinere implementaties werken, maar er blijft weinig ruimte over. Platformupgrades, implementaties en schaalgebeurtenissen hebben allemaal tijdelijke extra IP-adressen nodig en een klein subnet kan tijdens deze bewerkingen uitgeput raken.

Ondersteunde IP-bereiken

Uw subnet moet alleen RFC 1918 privé-IPv4-bereiken gebruiken:

  • 10.0.0.0/8
  • 172.16.0.0/12 (beslaat 172.16.x.x t/m 172.31.x.x)
  • 192.168.0.0/16

Openbare IP-bereiken en CGNAT-bereiken (bijvoorbeeld 100.64.0.0/10) worden niet ondersteund en veroorzaken routeringsfouten.

Hoe IP-adressen worden geconsumeerd

IP-adressen zijn gereserveerd op ongeveer 1 IP per 10 pods verhouding. Elk Foundry-project krijgt één gegevensproxy die begint bij 1 pod (1 replica) en opschaalt met toenemend verkeer.

Scenario Voorbeeld Impact van Intellectuele Eigendom
Weinig verkeer 10 projecten, elk met 1 replica ~1 IP-adres gedeeld over 10 pods
Hoog verkeer 10 projecten, elk geschaald naar 10 replica's 100 pods, ~10 IP-adressen

Project capaciteit dynamisch is omdat meer verkeer per project meer IP-adressen verbruikt.

Subnetgrootte en gelijktijdige sessies

Het aantal gelijktijdige agentsessies dat per abonnement beschikbaar is, verschilt per regio. Standaard komen gelijktijdige sessies en bruikbare IP-adressen van subnetten 1:1 overeen, met inachtneming van de limiet voor uw regio.

Subnet Totaal aantal IP-adressen Bruikbare IP-adressen Gelijktijdige sessies bij benadering
/27 32 ~27 ~17
/26 64 ~59 ~50 (maximaal ondersteund)

Gebruik met de standaardtoewijzing 1:1 een /26-subnet of groter om 50 gelijktijdige sessies te ondersteunen.

Als u meer gelijktijdige sessies met hetzelfde subnet wilt ondersteunen, maakt u een ondersteuning voor Azure aanvraag. Geef in de aanvraag het abonnement, de regio en het verwachte aantal gelijktijdige sessies op. Op basis van uw vereisten en regionale capaciteit kan ondersteuning de toewijzing verhogen naar 10 gelijktijdige sessies per bruikbaar IP-adres (1:10).

Project capaciteit

Een Foundry-exemplaar ondersteunt ongeveer 250 projecten bij weinig verkeer. Bij intensief verkeer, wanneer agents naar veel replica's worden geschaald, kan de effectieve limiet dalen tot slechts ongeveer 25 projecten. Wanneer IP-adressen zijn uitgeput, mislukt het inrichten van nieuwe projecten.

Belangrijk

Plan niet om op theoretische maximale capaciteit te draaien. Richt u op maximaal 80% subnetgebruik om pieken van upgrades en schalen te absorberen.

Gedrag tijdens platformonderhoud

Platformupgrades voeren parallel oude en nieuwe infrastructuur uit, waardoor het IP-verbruik tijdelijk wordt verhoogd. Een /24-subnet biedt voldoende buffer voor het afhandelen van deze tijdelijke pieken naast uw normale workloads. Infrastructuurupgrades worden volledig Microsoft beheerd, met inbegrip van hun timing.

Netwerkgedrag van gehoste agents

Gehoste agents worden uitgevoerd op Azure Container Apps en bieden u controle over de CPU- en geheugenconfiguratie. U implementeert ze via uw eigen Azure Container Registry.

Revisies en IP-gebruik

Wanneer u een update implementeert (nieuwe installatiekopieën, configuratie of code), maakt het platform een nieuwe revisie. Tijdens de implementatie worden oude en nieuwe revisies parallel uitgevoerd wanneer verkeer naar de nieuwe versie wordt verplaatst en beide IP-adressen van uw subnet verbruiken.

Revisielimieten per gehoste agent:

  • 100 actieve revisies per agent.
  • 1000 totale revisies per agentnaam. Oudste inactieve revisies worden automatisch verwijderd wanneer de actieve limiet is bereikt.
  • Ongeveer 200 gehoste agents per Foundry-exemplaar.

De limiet voor gehoste agenten van 200 is gescheiden van de projectlimiet van ~250, die exemplaarbreed geldig is voor alle agenttypen.

Uitgaande connectiviteit

Elke gehoste agent wordt uitgevoerd in een micro-VM die is gekoppeld aan uw gedelegeerde subnet met een toegewezen netwerkinterface en maakt gebruik van een eigen IP voor uitgaande communicatie. Tool-aanroepen worden altijd gerouteerd via de data proxy voor één tenant. Voor implementaties van broncodeagenten vereist de inrichtingsstap ook uitgaande toegang tot specifieke eindpunten. Zie firewallvereisten voor particuliere virtuele netwerken.

Prestaties en schaalvergroting

Het schalen van gehoste agents introduceert geen latentie of prestatievermindering. Het enige scenario waarin de prestaties worden beïnvloed, is wanneer IP-uitputting voorkomt dat het platform kan worden geschaald. Dit is vermijdbaar met de juiste grootte van het subnet. Gehoste agents ondersteunen aangepaste CPU- en geheugenconfiguraties. U selecteert uit beschikbare CPU- en geheugenparen wanneer u een agentversie maakt.

Het netwerkgedrag van agents stimuleren

Promptagents worden ook uitgevoerd op Azure Container Apps, maar berekeningen en schalen worden volledig beheerd door Microsoft. U configureert geen CPU of geheugen.

Revisies en IP-gebruik

In tegenstelling tot gehoste agents verbruiken revisies van promptagents geen IP-adressen. De gegevensproxy draait in enkel-revisie modus, zodat inactieve revisies geen invloed hebben op de beschikbaarheid van IP.

Uitgaande connectiviteit

Prompt-agents gebruiken de gegevensproxy met één tenant voor alle uitgaande connectiviteit. IP-adressen worden toegewezen op projectniveau, zodat alle promptagents binnen een project dezelfde gegevensproxy-infrastructuur delen.

Limieten en prestaties

Er is geen vaste limiet voor het aantal promptagenten dat u per Foundry-exemplaar kunt implementeren. Omdat berekeningen en schalen volledig worden beheerd, zijn er geen verwachte latentie- of prestatieproblemen gekoppeld aan het aantal promptagents dat is geïmplementeerd.

VNet-peering en IP-overlap

Overlappende IP-bereiken veroorzaken routeringsfouten, zodat alle gekoppelde VNets unieke, niet-overlappende IP-bereiken moeten gebruiken. Deze regel is ook van toepassing op configuraties voor bidirectionele peering. Alleen RFC 1918 privé-IPv4-bereiken worden ondersteund. CGNAT-adressen (bijvoorbeeld 100.x.x.x) zijn dat niet.

Als u ip-overlapping niet kunt voorkomen, gebruikt u beheerd virtueel netwerk in plaats van bring-your-own VNet. Beheerde VNet automatiseert de netwerkinstallatie en elimineert problemen met IP-overlappingen.

IP-gebruik bewaken en uitputting detecteren

De Azure-portal maakt momenteel geen IP-gebruik beschikbaar voor gedelegeerde subnetten, zodat u het niet rechtstreeks kunt bewaken. De primaire indicatoren van IP-uitputting zijn HTTP 5xx-fouten uit de gegevensproxy en, voor gehoste agents, fouten bij het maken van sessies (4xx-fouten). Wanneer IP-adressen zijn uitgeput, mislukt het schalen van de gegevensproxy en het inrichten van nieuwe projecten en kunnen gehoste agents geen Micro-VM toewijzen voor nieuwe sessies. Bewaak de status van de dataproxy en het succes van het maken van sessies met gehoste agents als vroege indicatoren van capaciteitsproblemen.

Overweeg om een nieuwe Foundry-instantie te implementeren met een nieuw subnet wanneer u het volgende waarneemt:

  • De gegevensproxy retourneert 5xx-codefouten.
  • Het maken van een gehoste agentsessie mislukt met 4xx-fouten.
  • Nieuwe projectinrichtingsfouten.

Belangrijk

Het platform waarschuwt u niet proactief wanneer de IP-capaciteit laag is. Bewaak de eerder vermelde signalen om onverwachte provisioning-mislukkingen te voorkomen.

Snelzoekgids

Onderwerp Aanbeveling
Subnetgrootte Gebruik /24 voor productie. /27 is het minimum maar risicovol. Met de standaardtoewijzing 1:1 hebt u /26 nodig voor 50 gelijktijdige sessies. Vraag meer sessies aan (maximaal 1:10 toewijzing, of één IP-adres voor 10 sessies) via ondersteuning voor Azure.
Doel van gebruik Blijf onder de 80% subnetgebruik om upgrade- en schaalpieken te absorberen.
Ondersteunde IP-bereiken Alleen RFC 1918: 10.x, 172.16 tot 172.31.x en met 192.168.x. Geen openbare IP-bereiken of CGNAT-bereiken.
Project capaciteit ~250 projecten met weinig verkeer, slechts ongeveer 25 op volledige schaal. Op basis van beschikbaarheid via IP.
Limieten voor gehoste agents 100 actieve revisies en 1000 totale revisies per agent. ~200 gehoste agents per instantie.
IP-verbruik Gehoste agentupdates verbruiken IP-adressen. Agentrevisies zijn niet nodig.
Uitgaande connectiviteit Gehoste agents gebruiken een toegewezen NIC. Alle tool-aanroepen worden gerouteerd via de data-proxy met een enkele tenant.
Gehost in vergelijking met prompt Gehost: aangepaste CPU en geheugen, uw ACR, toegewezen NIC. Prompt: volledig beheerde schaalaanpassing.
VNet-peering Gekoppelde VNets moeten niet-overlappende IP-bereiken hebben. Gebruik beheerd VNet als overlapping bestaat.
Monitoring Geen directe IP-monitoring in het portaal. Let op fouten in gegevensproxy 500.
Prestaties Geen degradatie bij het schalen van beide agenttypen, met de juiste afmeting van het subnet.

Verwante inhoud

  • Last updated on