Approfondimento sulla rete del servizio Foundry Agent

Quando si esegue il servizio agente di Microsoft Foundry con una rete virtuale (VNet) propria, si è responsabili del dimensionamento della subnet delegata, della pianificazione dell'allocazione IP e di comprendere come il traffico dell'agente fluisca attraverso la piattaforma. Questo articolo illustra l'architettura di rete che supporta agenti ospitati e agenti reattivi, il modello di allocazione IP e i segnali che indicano problemi di capacità. È destinato agli architetti cloud e di rete che hanno già scelto una rete virtuale personalizzata (bring-your-own VNet) per il servizio Foundry Agent. Per configurare la rete, vedere Configurare la rete privata per il servizio agente Foundry.

Se si usa un agente di scrittura del codice come GitHub Copilot per pianificare la rete virtuale, la subnet e il modello di capacità, la competenza Microsoft Foundry consente di ragionare tramite l'architettura e applicare linee guida per la rete Foundry nel proprio ambiente.

Panoramica dell'architettura di rete

Il diagramma seguente mostra le due zone coinvolte in qualsiasi richiesta del servizio Foundry Agent: la rete della piattaforma Foundry gestita Microsoft a sinistra e la rete virtuale del cliente a destra.

Diagramma dell'architettura che mostra, a sinistra, la rete della piattaforma Foundry con l'endpoint Foundry, un layer host delle Micro VM, il Tools Service e il layer host del Data Proxy. A destra, la VNet del cliente contiene una subnet delegata che ospita le Micro VM e il Data Proxy su App contenitore di Azure, oltre a una subnet separata per endpoint privati per Archiviazione, SQL Database e Key Vault. Le frecce mostrano il traffico dell'hosted agent che passa attraverso la Micro VM e il traffico del prompt agent che passa direttamente attraverso il Tools Service. Entrambi i percorsi convergono nel Data Proxy ed escono verso le risorse del cliente tramite endpoint privati.

La rete della piattaforma ospita l'endpoint Foundry, il livello host della micro-VM che esegue gli agenti Hosted, il Tools Service e il livello host del Data Proxy. La rete virtuale del cliente contiene una subnet delegata (in cui le micro macchine virtuali e il proxy di dati utilizzano gli indirizzi IP) e una subnet dell'endpoint privato che si connette all'archiviazione, ai database e al Key Vault.

Due flussi di richiesta attraversano questa architettura:

  • Agente ospitato: dal client a endpoint Foundry, a Micro VM (/invoke), al servizio strumenti, al Data Proxy, alle risorse del cliente tramite endpoint privati.
  • Agente di prompt: dal client a endpoint Foundry, al servizio strumenti, al proxy dati, alle risorse del cliente tramite endpoint privati. In questo percorso non è presente alcuna macchina virtuale micro.

Concetti chiave

Termine Cosa significa
Istanza di Foundry La tua risorsa Microsoft Foundry. Contenitore di primo livello che contiene progetti, agenti e configurazione di rete.
Agente ospitato Un agente che crei e distribuisci tu stesso usando un'immagine del contenitore personalizzata tramite Registro Azure Container. È possibile controllare CPU, memoria e codice.
Agente prompt Un agente in cui il calcolo e il ridimensionamento sono completamente gestiti da Microsoft. Il comportamento viene definito tramite la configurazione. Non è necessaria alcuna gestione dell'immagine del contenitore o dell'infrastruttura.
Proxy dati a tenant singolo Componente di rete gestito dalla piattaforma dedicato al progetto Foundry che gestisce la connettività in uscita per gli agenti. A ogni progetto viene assegnata un'istanza isolata di proxy di dati. Tutte le chiamate agli strumenti vengono instradate tramite il proxy dati.
Server degli strumenti Un servizio back-end registrato a livello di progetto che gli agenti possono chiamare per eseguire azioni, ad esempio l'esecuzione di query su un database o la chiamata di un'API esterna. Nelle configurazioni con propria rete virtuale il traffico del server degli strumenti viene instradato attraverso il proxy dati a tenant singolo.
Subnet delegata Subnet nella rete virtuale delegata al Servizio agenti Foundry. Tutta l'infrastruttura dell'agente (proxy dati e macchine virtuali Micro) viene distribuita in questa subnet e usa gli indirizzi IP relativi.
Micro VM Macchina virtuale leggera che esegue un agente ospitato.
Versione Modifica che influisce sul modo in cui viene eseguito l'agente, ad esempio nuovo codice, una nuova immagine del contenitore o un aggiornamento della configurazione. Solo le modifiche che influiscono sul runtime creano una nuova versione.

Modalità di flusso del traffico

Ogni richiesta del servizio Foundry Agent entra attraverso l'endpoint Foundry ed esce verso le risorse dei clienti tramite endpoint privati. Il tipo di agente determina cosa accade tra di loro.

In ingresso all'endpoint Foundry

I client inviano richieste HTTPS all'endpoint Foundry , ad esempio <your-resource>.services.ai.azure.com. Il gateway API della piattaforma autentica la richiesta e la instrada in base al tipo di agente di destinazione.

Percorso dell'agente ospitato

Per un agente ospitato, la piattaforma inoltra la richiesta a una macchina virtuale Micro nella subnet delegata tramite il /invoke protocollo. La macchina virtuale Micro ha due interfacce di rete:

Tipo di traffico Percorso
Traffico in uscita dell'agente Diretta, tramite la scheda di rete dedicata della macchina virtuale Micro nella subnet delegata.
Chiamate al server degli strumenti Tramite il proxy dati a tenant singolo, indipendentemente dal tipo di agente.

Anche se la macchina virtuale Micro ha una propria scheda di interfaccia di rete, qualsiasi chiamata dello strumento viene instradata tramite il proxy dati.

Percorso agente di prompt

Per un agente prompt, l'agente viene eseguito su risorse computazionali gestite da Microsoft. L'endpoint Foundry inoltra la richiesta direttamente al servizio strumenti, che chiama il proxy dati a tenant singolo. Gli indirizzi IP vengono allocati a livello di progetto, quindi tutti gli agenti prompt all'interno di un progetto condividono la stessa infrastruttura proxy dati.

Accesso alle risorse dei clienti

Il traffico in uscita dal proxy dati raggiunge gli account di archiviazione, i database e Key Vault tramite endpoint privati nella subnet dell'endpoint privato. Configurare le zone di DNS privato corrispondenti (ad esempio, privatelink.blob.core.windows.net, privatelink.database.windows.net e privatelink.vaultcore.azure.net) in modo che la risoluzione dei nomi rimanga all'interno della VNet.

Dimensionamento della subnet e allocazione IP

La configurazione della subnet si applica al livello dell'account Foundry. Tutti i progetti nell'account condividono la stessa configurazione della subnet e gli agenti ospitati e di prompt condividono la stessa subnet delegata. La dimensione consigliata deve coprire l'utilizzo combinato degli indirizzi IP dagli agenti in ogni progetto, aggiornamenti della piattaforma ed eventi di ridimensionamento.

Usare un intervallo CIDR /24 come punto di partenza per i carichi di lavoro di produzione e scegliere un intervallo più ampio quando è richiesta la concorrenza massima prevista. Non usare una subnet /27 per i carichi di lavoro di produzione. Sebbene /27 possa supportare piccole installazioni di sviluppo o di valutazione, lascia un margine molto ridotto. Gli aggiornamenti della piattaforma, le implementazioni e gli eventi di ridimensionamento richiedono tutti indirizzi IP aggiuntivi temporanei e una piccola subnet può essere esaurita durante queste operazioni.

Pianificate la capacità della subnet in questo ordine:

  1. Stimare il picco di sessioni simultanee di agenti ospitati in tutti i progetti dell'account per la regione. I progetti nell'account condividono la capacità della subnet. Tutti gli account e i progetti Foundry nella sottoscrizione e nell'area condividono separatamente la quota di sessione.
  2. Controllare la quota di sessione simultanea predefinita dell'area nei limiti predefiniti del servizio.
  3. Dimensiona la subnet in modo che gli indirizzi IP utilizzabili soddisfino o superino il valore target, usando la tabella in Dimensioni subnet e sessioni simultanee. Mantenere il picco previsto al di sotto dell’80% degli indirizzi IP utilizzabili per assorbire i picchi di aggiornamento e di scalabilità.
  4. Se il target supera il valore predefinito regionale, richiedi un aumento del limite. Specificare la sottoscrizione, l'area e la concorrenza prevista. Gli aumenti dipendono dalla capacità a livello di area.
  5. Se hai bisogno di più sessioni di quante ne consentano gli indirizzi IP utilizzabili della subnet e la subnet non può essere ampliata, richiedi un aumento della mappatura da IP a sessione nella stessa richiesta di supporto.

Intervalli IP supportati

La subnet deve usare solo intervalli IPv4 privati RFC 1918 :

  • 10.0.0.0/8
  • 172.16.0.0/12 (copre 172.16.x.x fino a 172.31.x.x)
  • 192.168.0.0/16

Gli intervalli IP pubblici e gli intervalli CGNAT ,ad esempio , 100.64.0.0/10non sono supportati e causano errori di routing.

Modalità di utilizzo degli indirizzi IP

Gli indirizzi IP della subnet delegata supportano le sessioni dell'agente ospitato e i componenti di rete a livello di progetto. Modifiche effettive al consumo con sessioni simultanee, numero di progetti, ridimensionamento e manutenzione della piattaforma. Ridimensionare la subnet per le sessioni simultanee di picco previste e mantenere sufficienti indirizzi inutilizzati per le esigenze temporanee di capacità. Pianificate la capacità in base alle sessioni e agli indirizzi IP di sottorete utilizzabili, non in base a unità dell'infrastruttura come i pod.

Dimensioni della subnet e sessioni simultanee

Il numero di sessioni simultanee dell'agente disponibili per abbonamento varia in base alla regione. Per impostazione predefinita, le sessioni simultanee e gli indirizzi IP di subnet utilizzabili corrispondono in rapporto 1:1, nel rispetto del limite previsto per la tua regione.

Subnet Indirizzi IP totali INDIRIZZI IP utilizzabili Sessioni simultanee stimate
/27 32 ~27 ~20
/26 64 ~59 ~50
/25 128 ~123 ~100
/24 256 ~251 ~250
/23 512 ~507 ~500
/22 1,024 ~1.019 ~1.000
/21 2,048 ~2.043 ~2.000

La tabella mostra le dimensioni comuni delle subnet e non è esaustiva. È possibile utilizzare una subnet più ampia tra quelle supportate, se è compatibile con il proprio schema di indirizzamento IP privato. Gli indirizzi aggiuntivi forniscono capacità e margine operativo, ma non aumentano la quota regionale di sessioni per sottoscrizione.

La colonna Sessioni simultanee approssimative stima la capacità degli INDIRIZZI IP di subnet utilizzabili nel mapping predefinito. Questi valori non sono obiettivi di pianificazione di produzione. Prevedere un livello di concorrenza inferiore, in modo che anche i componenti di rete del progetto e il margine operativo consigliato del 20% rientrino nella subnet. La quota di sessione regionale per sottoscrizione limita ulteriormente la concorrenza effettiva. Ad esempio, in un'area con una quota di 1.000 sessioni, una subnet maggiore di /22 aggiunge il headroom IP, ma non aumenta la concorrenza a meno che non si richieda un aumento della quota.

Una sessione rappresenta il calcolo dell'agente ospitato e lo stato del file persistente, non la cronologia delle conversazioni. La capacità della sessione non determina quindi il numero di conversazioni che l'applicazione può gestire. Con il protocollo Risposte, una conversazione è associata a una sessione, mentre altri modelli di chiamata possono riutilizzare una sessione senza cronologia di conversazione gestita dalla piattaforma. Per informazioni dettagliate, vedere Sessioni e conversazioni.

Per supportare più sessioni simultanee all'interno della stessa subnet, creare una richiesta di supporto tecnico di Azure. Nella richiesta specificare la sottoscrizione, l'area e il numero previsto di sessioni simultanee. In base ai vostri requisiti e alla capacità regionale, il supporto può aumentare la mappatura fino a 10 sessioni concorrenti per IP utilizzabile (1:10). Per la quota predefinita di sessioni simultanee disponibile per regione, consulta Quote di Foundry Agent Service.

capacità del progetto

Un'istanza di Foundry supporta circa 250 progetti a traffico ridotto. In caso di traffico elevato, quando gli agenti eseguono molte sessioni simultanee, il limite effettivo può scendere fino a circa 25 progetti. Quando gli indirizzi IP sono esauriti, il provisioning del nuovo progetto fallisce.

Importante

Non pianificare di lavorare in base alla capacità massima teorica. Puntare a un massimo di 80% di utilizzo della subnet per assorbire i picchi derivanti da aggiornamenti e operazioni di scalabilità.

Comportamento durante la manutenzione della piattaforma

Gli aggiornamenti della piattaforma eseguono l'infrastruttura precedente e nuova in parallelo, aumentando temporaneamente il consumo di indirizzi IP. Una subnet /24 fornisce un buffer sufficiente per gestire questi picchi temporanei insieme ai normali carichi di lavoro. Gli aggiornamenti dell'infrastruttura sono completamente gestiti Microsoft, inclusi i tempi.

Connettività in uscita

Gli agenti ospitati vengono eseguiti in microVM collegati alla subnet delegata e lo usano per la comunicazione in uscita. Le chiamate agli strumenti sono sempre instradate attraverso un proxy di dati a tenant singolo. Per le distribuzioni degli agenti del codice sorgente, la fase di provisioning richiede anche l'accesso in uscita verso endpoint specifici. Vedere Requisiti del firewall per le reti virtuali private.

Prestazioni e scalabilità

Gli agenti ospitati supportano configurazioni di CPU e memoria personalizzate. Quando si crea una versione dell'agente, è possibile selezionare le coppie di CPU e memoria disponibili. L'avvio o la ripresa di una sessione possono richiedere il provisioning delle risorse di calcolo. Se la subnet non dispone di un numero sufficiente di indirizzi IP disponibili, la piattaforma non può effettuare il provisioning del calcolo per sessioni aggiuntive.

Comportamento di rete degli agenti di prompt

Gli agenti prompt vengono eseguiti anche in App contenitore di Azure, ma il calcolo e il ridimensionamento sono completamente gestiti da Microsoft. Non si configura cpu o memoria.

Versioni e utilizzo ip

A differenza delle sessioni dell'agente ospitato, le versioni dell'agente prompt non usano indirizzi IP. I componenti di rete a livello di progetto continuano a utilizzare gli indirizzi della subnet delegata.

Connettività in uscita

Gli agenti di prompt usano il proxy dati a tenant singolo per tutta la connettività in uscita. Gli indirizzi IP vengono allocati a livello di progetto, quindi tutti gli agenti prompt all'interno di un progetto condividono la stessa infrastruttura proxy dati.

Limiti e prestazioni

Non esiste un limite rigido per il numero di agenti prompt che è possibile distribuire per ogni istanza di Foundry. Poiché il calcolo e il ridimensionamento sono completamente gestiti, non sono previsti problemi di latenza o prestazioni legati al numero di agenti prompt distribuiti.

Peering reti virtuali e sovrapposizione IP

Gli intervalli IP sovrapposti causano errori di routing, quindi tutte le reti virtuali con peering devono usare intervalli IP univoci e non sovrapposti. Questa regola si applica anche alle configurazioni di peering bidirezionale. Sono supportati solo gli intervalli IPv4 privati RFC 1918. Gli indirizzi CGNAT (ad esempio 100.x.x.x) non sono disponibili.

Se non è possibile evitare sovrapposizioni IP, utilizzare la rete virtuale gestita invece di una rete virtuale personale. La rete virtuale gestita automatizza la configurazione di rete ed elimina i problemi di sovrapposizione IP.

Monitorare l'utilizzo IP e rilevare l'esaurimento delle risorse IP

Il portale di Azure attualmente non espone l'utilizzo IP per le subnet delegate, quindi non è possibile monitorarlo direttamente. Gli indicatori principali dell'esaurimento IP sono errori HTTP 5xx dal proxy dati e, per gli agenti ospitati, gli errori HTTP 429 subnet_exhausted durante la creazione o la ripresa della sessione. Quando gli indirizzi IP sono esauriti, il ridimensionamento del proxy dati e il provisioning di nuovi progetti hanno esito negativo e gli agenti ospitati non riescono ad allocare risorse di calcolo per le sessioni nuove o ripristinate. Monitorare l'integrità del proxy dei dati e il successo della sessione dell'agente ospitato come indicatori precoci di problemi di capacità.

È consigliabile distribuire una nuova istanza di Foundry con una nuova subnet nei casi seguenti:

  • Il proxy di dati sta restituendo errori 5xx.
  • Creazione o ripresa della sessione dell'agente ospitato non riuscita con errori HTTP 429 subnet_exhausted .
  • Nuovi errori di provisioning del progetto.

Importante

La piattaforma non avvisa in modo proattivo quando la capacità IP è insufficiente. Monitorare i segnali elencati in precedenza per evitare errori di provisioning non previsti.

Riferimento rapido

Argomento Raccomandazione
Dimensioni della subnet Usare almeno /24 per la produzione. /27 è il minimo ma rischioso. Con il mapping predefinito 1:1, la capacità della subnet varia da circa 20 sessioni simultanee con /27 a 2.000 con /21. Dimensioni per un utilizzo inferiore a 80% oppure richiedere fino a un mapping di 1:10 (un indirizzo IP per 10 sessioni) tramite supporto tecnico di Azure.
Destinazione di utilizzo Mantenere l'utilizzo della subnet al di sotto dell'80% per assorbire i picchi dovuti all'aggiornamento e alla scalabilità.
Intervalli IP supportati Solo RFC 1918: 10.x, 172.16 fino a 172.31.x e 192.168.x. Nessun intervallo pubblico o CGNAT.
capacità del progetto Circa 250 progetti a basso traffico, fino a circa 25 progetti su larga scala. Guidato dalla disponibilità di IP
Consumo IP Le sessioni dell'agente ospitato e i componenti di rete a livello di progetto usano indirizzi IP. Nessuna versione dell'agente di prompt.
Connettività in uscita Le sessioni dell'agente ospitato utilizzano la subnet delegata. Tutte le chiamate agli strumenti vengono instradate tramite il proxy dati a tenant singolo.
Ospitato rispetto a prompt Ospitato: CPU e memoria personalizzate e il Registro Azure Container. Prompt: scalabilità completamente gestita.
Peering reti virtuali Le reti virtuali con peering devono avere intervalli IP non sovrapposti. Usare la rete virtuale gestita se esiste una sovrapposizione.
Monitoraggio Nessun monitoraggio IP diretto nel portale. Prestare attenzione agli errori 500 del proxy dati.
Prestazione L'avvio o la ripresa di una sessione possono richiedere il provisioning delle risorse di calcolo. L'esaurimento degli indirizzi IP impedisce l'allocazione di ulteriori risorse di calcolo per la sessione.

Contenuto correlato

  • Ultimo aggiornamento: