Djupdykning i Foundry Agent Service-nätverk

När du kör Microsoft Foundry Agent Service med ett eget virtuellt nätverk (VNet) ansvarar du för att storleksanpassa det delegerade undernätet, planera IP-allokering och förstå hur agenttrafiken flödar genom plattformen. I den här artikeln beskrivs nätverksarkitekturen bakom värdbaserade agenter och promptagenter, IP-allokeringsmodellen och de signaler som indikerar kapacitetsproblem. Det är avsett för moln- och nätverksarkitekter som redan har valt bring-your-own VNet för Foundry Agent Service. Information om hur du konfigurerar nätverket finns i Konfigurera privata nätverk för Foundry Agent Service.

Översikt över nätverksarkitektur

Följande diagram visar de två zoner som ingår i en Foundry Agent Service-begäran: det Microsoft hanterade Foundry-plattformsnätverket till vänster och ditt kund-VNet till höger.

Plattformsnätverket är värd för Foundry-slutpunkten, värdlagret för den virtuella mikrodatorn som kör värdbaserade agenter, verktygstjänsten och värdlagret dataproxy. Ditt virtuella kundnät innehåller ett delegerat undernät (där virtuella mikrodatorer och dataproxyn använder IP-adresser) och ett privat slutpunktsundernät som ansluter till din lagring, dina databaser och Key Vault.

Två begärandeflöden passerar den här arkitekturen:

• Värdbaserad agent: Klient till Foundry-slutpunkt till mikro-VM (/invoke) till Verktygstjänst till dataproxy till kundresurser via privata slutpunkter.
• Fråga agent: Klient till Foundry-slutpunkt till verktygstjänst till dataproxy till kundresurser via privata slutpunkter. Det finns ingen mikrovirtuell maskin på den här sökvägen.

Viktiga begrepp

Benämna	Vad det betyder
Foundry-instans	Din Foundry-resurs från Microsoft. Den översta containern som innehåller dina projekt, agenter och nätverkskonfiguration.
Hostad agent	En agent som du skapar och distribuerar själv med hjälp av din egen containeravbildning via Azure Container Registry. Du styr CPU, minne och kod. Körs på Azure Container Apps.
Uppmana agenten	En agent där beräkning och skalning hanteras helt av Microsoft. Du definierar beteendet via konfigurationen. Ingen containeravbildning eller infrastrukturhantering krävs.
Dataproxy för en klientorganisation	En plattformshanterad nätverkskomponent som är dedikerad till ditt Foundry-projekt som hanterar utgående anslutning för dina agenter. Varje projekt får en egen isolerad dataproxyinstans. Alla anrop från verktyg dirigeras genom dataproxyn.
Verktygsserver	En serverdelstjänst som är registrerad på projektnivå som dina agenter kan anropa för att utföra åtgärder, till exempel köra frågor mot en databas eller anropa ett externt API. I bring-your-own VNet-konfigurationer dirigeras verktygsservertrafiken genom en single-tenant-data-proxy.
Delegerat undernät	Undernätet i ditt virtuella nätverk som du delegerar till Foundry Agent Service. All agentinfrastruktur (dataproxy och mikro-VMs) distribueras till detta undernät och förbrukar IP-adresser därifrån.
Virtuell mikrodator	Den lätta virtuella datorn som kör en värdbaserad agent.
Version	En ändring som påverkar hur din agent körs, till exempel ny kod, en ny containeravbildning eller en konfigurationsuppdatering. Endast ändringar som påverkar körningen skapar en ny version.
Översyn	Implementeringsenheten för din agent. En revision kan vara versionerad (kopplad till en körningsändring) eller icke-versionerad (endast metadataändringar som taggar eller skalningsinställningar).

Så här flödar trafik

Varje Foundry Agent Service-begäran går in vid Foundry-slutpunkten och leder vidare till dina kundresurser via privata slutpunkter. Agenttypen avgör vad som händer däremellan.

Inkommande till Foundry-slutpunkten

Klienter skickar HTTPS-begäranden till din Foundry-slutpunkt (till exempel <your-resource>.services.ai.azure.com). Plattformens API-gateway autentiserar begäran och dirigerar den baserat på målagenttypen.

Sökväg till värdbaserad agent

För en värdbaserad agent vidarebefordrar plattformen begäran till en virtuell Mikrodator i ditt delegerade undernät via /invoke protokollet. Den virtuella Mikrodatorn har två nätverksgränssnitt:

Trafiktyp	Rutt
Agentens egen utgående trafik	Direkt via den virtuella mikrodatorns dedikerade nätverkskort i det delegerade undernätet.
Verktygsserveranrop	Genom en single-tenant dataproxy, oavsett agenttyp.

Även om den virtuella mikrodatorn har ett eget nätverkskort dirigeras alla verktygsanrop via dataproxyn.

Uppmana till agentsökväg

För en promptagent körs agenten i Microsoft-hanterad beräkning. Foundry-slutpunkten vidarebefordrar begäran direkt till verktygstjänsten, som anropar dataproxyn för en klientorganisation. IP-adresser allokeras på projektnivå, så alla promptagenter i ett projekt delar samma dataproxyinfrastruktur.

Utgående trafik mot kundresurser

Utgående trafik från dataproxyn når dina lagringskonton, databaser och Key Vault via privata slutpunkter i ditt privata slutpunktsundernät. Konfigurera motsvarande Private DNS-zoner (till exempel privatelink.blob.core.windows.net, privatelink.database.windows.net och privatelink.vaultcore.azure.net) så att namnuppslagningen stannar i VNet.

Storlek på undernät och IP-allokering

Konfigurationen av undernätet gäller på foundry-kontonivå. Alla projekt i kontot delar samma undernätskonfiguration och värdbaserade agenter och promptagenter delar samma delegerade undernät. Den rekommenderade storleken måste täcka kombinerad IP-användning från agenter i varje projekt, plattformsuppgraderingar och skalningshändelser.

Rekommenderad storlek på undernät

Använd ett /24 CIDR-intervall för produktionsarbetsbelastningar. Ett /27-undernät kan fungera för mindre distributioner, men det lämnar mycket lite utrymme. Plattformsuppgraderingar, distributioner och skalningshändelser behöver alla tillfälliga ytterligare IP-adresser, och ett litet undernät kan bli uttömt under dessa åtgärder.

IP-intervall som stöds

Ditt undernät måste endast använda privata IPv4-intervall för RFC 1918 :

• 10.0.0.0/8
• 172.16.0.0/12 (täcker 172.16.x.x genom 172.31.x.x)
• 192.168.0.0/16

Offentliga IP-intervall och CGNAT-intervall (till exempel 100.64.0.0/10) stöds inte och orsakar routningsfel.

Så här används IP-adresser

IP-adresser är reserverade med ett förhållande på cirka 1 IP per 10 poddar . Varje Foundry-projekt får en dataproxy som startar vid 1 podd (1 replik) och skalas upp med trafikvolym.

Scenario	Exempel	IP-påverkan
Låg trafik	10 projekt, var och en vid 1 replika	~1 IP delas mellan 10 poddar
Hög trafik	10 projekt, var och en skalad till 10 repliker	100 pods, ~10 IP-adresser

Projekts kapacitet är dynamisk eftersom mer trafik per projekt förbrukar fler IP-adresser.

Undernätsstorlek och samtidiga sessioner

Antalet samtidiga agentsessioner som är tillgängliga per prenumeration varierar beroende på region. Som standard motsvarar samtidiga sessioner och användbara IP-adresser i undernätet 1:1, upp till gränsen för din region.

Undernät	Totalt antal IP-adresser	Användbara IP-adresser	Ungefärliga samtidiga sessioner
/27	32	~27	~17
/26	64	~59	~50 (maximalt stöd)

Med standardmappningen 1:1 använder du ett /26-undernät eller större för att stödja 50 samtidiga sessioner.

Om du vill ha stöd för fler samtidiga sessioner med samma undernät skapar du en Azure support begäran. I begäran anger du prenumeration, region och förväntat antal samtidiga sessioner. Baserat på dina krav och regionala kapacitet kan stödet öka mappningen till 10 samtidiga sessioner per användbar IP-adress (1:10).

Projektkapacitet

En Foundry-instans stöder cirka 250 projekt med låg trafik. När agenter skalas till många repliker under tung trafik kan den effektiva gränsen sjunka ner till så lite som ~25 projekt. När IP-adresserna är slut misslyckas nya projektinrättanden.

Viktigt

Planera inte att köras med teoretisk maximal kapacitet. Rikta in dig på högst 80% undernätsanvändning för att absorbera toppar från uppgraderingar och skalning.

Beteende under plattformsunderhåll

Plattformsuppgraderingar kör gammal och ny infrastruktur parallellt, vilket tillfälligt ökar IP-förbrukningen. Ett /24-undernät ger tillräckligt med buffert för att hantera dessa tillfälliga toppar tillsammans med dina normala arbetsbelastningar. Infrastrukturuppgraderingar är helt Microsoft hanterade, inklusive tidpunkten för dem.

Nätverksbeteende för värdbaserade agenter

Värdbaserade agenter körs på Azure Container Apps och ger dig kontroll över processor- och minneskonfigurationen. Du distribuerar dem via dina egna Azure Container Registry.

Revisioner och IP-användning

När du distribuerar en uppdatering (ny avbildning, konfiguration eller kod) skapar plattformen en ny revision. Under distributionen körs gamla och nya revisioner parallellt när trafiken övergår till den nya versionen och båda använder IP-adresser från undernätet.

Revisionsgränser per värdbaserad agent:

• 100 aktiva revisioner per agent.
• 1 000 totala revisioner per agentnamn. Äldsta inaktiva revisioner rensas automatiskt när den aktiva gränsen nås.
• Cirka 200 värdbaserade agenter per Foundry-instans.

Gränsen på 200 värdbaserade agenter är separat från projekttaket ~250, som gäller hela instansen för alla agenttyper.

Utgående anslutning

Varje värdbaserad agent körs på en virtuell Mikrodator som är kopplad till ditt delegerade undernät med ett dedikerat nätverksgränssnitt och använder sin egen IP-adress för utgående kommunikation. Verktygsanrop dirigerar alltid via dataproxyn för en klientorganisation. För distributioner av källkodsagenter kräver etableringssteget även utgående åtkomst till specifika slutpunkter. Se Brandväggskrav för privata virtuella nätverk.

Prestanda och skalning

Skalning av värdbaserade agenter medför inte fördröjning eller prestandaförsämring. Det enda scenario där prestanda påverkas är när IP-överbelastning hindrar plattformen från skalning, vilket kan undvikas med rätt storlek på undernätet. Värdbaserade agenter stöder anpassade processor- och minneskonfigurationer. Du väljer från tillgängliga CPU- och minnespar när du skapar en agentversion.

Framkalla agenternas nätverksbeteende

Promptagenter körs också på Azure Container Apps, men beräkning och skalning hanteras helt av Microsoft. Du konfigurerar inte CPU eller minne.

Revisioner och IP-användning

Till skillnad från värdbaserade agenter förbrukar promptagentrevisioner inte IP-adresser. Dataproxyn körs i läget för enkel revision, så inaktiva revisioner påverkar inte IP-tillgängligheten.

Utgående anslutning

Promptagenter använder dataproxyn för single-tenant-arkitektur för alla utgående anslutningar. IP-adresser allokeras på projektnivå, så alla promptagenter i ett projekt delar samma dataproxyinfrastruktur.

Gränser och prestanda

Det finns ingen hård gräns för hur många promptagenter du kan distribuera per Foundry-instans. Eftersom beräkning och skalning är helt hanterade finns det inga förväntade svarstider eller prestandaproblem kopplade till antalet distribuerade promptagenter.

VNet-peering och IP-överlappning

Överlappande IP-intervall orsakar routningsfel, så alla peer-kopplade virtuella nätverk måste använda unika, icke-överlappande IP-intervall. Den här regeln gäller även för dubbelriktade peeringkonfigurationer. Endast privata IPv4-intervall för RFC 1918 stöds. CGNAT-adresser (till exempel 100.x.x.x) är inte det.

Om du inte kan undvika IP-överlappning använder du hanterat virtuellt nätverk i stället för bring-your-own VNet. Det hanterade virtuella nätverket automatiserar nätverkskonfigurationen och eliminerar PROBLEM med IP-överlappning.

Övervaka IP-användning och identifiera överbelastning

Den Azure portalen exponerar för närvarande inte IP-användning för delegerade undernät, så du kan inte övervaka den direkt. De primära indikatorerna för IP-överbelastning är HTTP 5xx-fel från dataproxyn och, för värdbaserade agenter, fel vid skapande av sessioner (4xx-fel). När IP-adresser är slut misslyckas dataproxyskalning och ny projektetablering, och värdbaserade agenter kan inte allokera en virtuell Mikrodator för nya sessioner. Övervaka dataproxyns status och hur framgångsrikt sessioner för värdbaserade agenter skapas som tidiga indikatorer på kapacitetsproblem.

Överväg att distribuera en ny Foundry-instans med ett nytt undernät när du observerar:

• Dataproxyn returnerar 5xx-fel.
• Skapande av värdbaserad agentsession misslyckas med 4xx-fel.
• Nya projektetableringsfel.

Viktigt

Plattformen varnar dig inte proaktivt när IP-kapaciteten börjar ta slut. Övervaka de signaler som angavs tidigare för att undvika oväntade implementeringsfel.

Snabbreferens

Ämne	Rekommendation
Storlek på undernät	Använd /24 för produktion. /27 är det minsta men riskfyllda. Med standardmappningen 1:1 behöver du /26 för 50 samtidiga sessioner. Begär fler sessioner (upp till en 1:10-mappning eller en IP-adress för 10 sessioner) via Azure support.
Användningsmål	Håll dig under 80% subnätanvändning för att hantera uppgraderings- och skalningstoppar.
IP-intervall som stöds	ENDAST RFC 1918: 10.x, 172.16 till och med 172.31.x, och 192.168.x. Inga offentliga intervall eller CGNAT-intervall.
Projektkapacitet	~250 projekt med låg trafik, så få som ~25 i full skala. Drivs av IP-tillgänglighet.
Gränser för värdbaserad agent	100 aktiva revisioner och 1 000 totala revisioner per agent. ~200 värdbaserade agenter per instans.
IP-förbrukning	Värdbaserade agentrevisioner använder IP-adresser. Uppmana till snabba agentrevisioner, inte att fördröja dem.
Utgående anslutning	Värdbaserade agenter använder ett dedikerat nätverkskort. Alla verktygsanrop dirigeras genom single-tenant dataproxy.
Värdbaserad jämfört med prompt	Värdbaserad: anpassad processor och minne, din ACR, dedikerade nätverkskort. Fråga: fullständigt hanterad skalning.
VNet-peering	Peerkopplade virtuella nätverk måste ha ip-intervall som inte överlappar varandra. Använd hanterat virtuellt nätverk om överlappning finns.
Övervakning	Ingen direkt IP-övervakning i portalen. Håll utkik efter dataproxy 500-fel.
Prestanda	Ingen försämring från skalning av någon av agenttyperna, med rätt storlek på undernätet.

Relaterat innehåll

• Konfigurera privata nätverk för Foundry Agent Service
• Värdbaserade agenter i Foundry Agent Service
• Hanterat virtuellt nätverk
• Konfigurera privat länk