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.

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. Viene eseguito in App contenitore di Azure.
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.
Revisione Unità di distribuzione per l'agente. Una revisione può essere con controllo delle versioni (associata a una modifica di runtime) o non con controllo delle versioni (modifiche di sola metadati, ad esempio tag o impostazioni di ridimensionamento).

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 per i carichi di lavoro di produzione. Una subnet /27 può funzionare per distribuzioni più piccole, ma lascia molto poco spazio. 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.

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

Indirizzi IP sono riservati in un rapporto di circa 1 IP per 10 pod. Ogni progetto Foundry ottiene un proxy di dati che parte da 1 pod (1 replica) e scala in base al traffico.

Scenario Esempio Impatto IP
Traffico basso 10 progetti, ognuno in 1 replica Circa 1 indirizzo IP condiviso tra 10 pod
Traffico elevato 10 progetti, ognuno con scalabilità fino a 10 repliche 100 pod, ~10 IP

La capacità del progetto è dinamica perché più traffico per progetto utilizza più indirizzi IP.

Dimensioni della subnet e sessioni simultanee

La piattaforma supporta un massimo di 50 sessioni di agenti simultanee per sottoscrizione per area. Le dimensioni della subnet determinano se è possibile raggiungere tale valore massimo.

Subnet Indirizzi IP totali INDIRIZZI IP utilizzabili Sessioni simultanee stimate
/27 32 ~27 ~17
/26 64 ~59 ~50 (massimo supportato)

Per supportare le 50 sessioni simultanee complete, usare una subnet /26 o superiore.

capacità del progetto

Un'istanza di Foundry supporta circa 250 progetti a traffico ridotto. In caso di traffico elevato, quando gli agenti si espandono a molte repliche, il limite effettivo può scendere a non più di 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.

Comportamento di rete degli agenti ospitati

Gli agenti ospitati vengono eseguiti in App contenitore di Azure e consentono di controllare la configurazione della CPU e della memoria. È possibile distribuirli tramite il proprio Registro Azure Container.

Revisioni e utilizzo ip

Quando si distribuisce un aggiornamento (nuova immagine, configurazione o codice), la piattaforma crea una nuova revisione. Durante l'implementazione, le vecchie e nuove revisioni vengono eseguite in parallelo mentre il traffico passa alla nuova versione, e entrambe utilizzano gli indirizzi IP dalla tua subnet.

Limiti di revisione per agente ospitato:

  • 100 revisioni attive per agente.
  • 1.000 revisioni totali per nome agente. Le revisioni inattive meno recenti vengono eliminate automaticamente quando viene raggiunto il limite attivo.
  • Circa 200 agenti ospitati per ogni istanza di Foundry (anteprima).

Il limite di 200 agenti ospitati è separato dal limite di circa 250 progetti, che si applica a livello di istanza per tutti i tipi di agente.

Connettività in uscita

Ogni agente ospitato viene eseguito in una micro macchina virtuale collegata alla subnet delegata con un'interfaccia di rete dedicata e usa il proprio IP per la comunicazione in uscita. Le chiamate agli strumenti sono sempre instradate attraverso un proxy di dati a tenant singolo.

Prestazioni e scalabilità

Il ridimensionamento degli agenti ospitati non comporta una latenza o una riduzione delle prestazioni. L'unico scenario in cui le prestazioni sono interessate è quando l'esaurimento IP impedisce la scalabilità della piattaforma, che è evitabile con il dimensionamento corretto della subnet. 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.

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.

Revisioni e utilizzo ip

A differenza degli agenti ospitati, le revisioni dell'agente prompt non usano indirizzi IP. Il proxy dati viene eseguito in modalità a revisione singola, quindi le revisioni inattive non hanno alcun impatto sulla disponibilità IP.

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 provenienti dal proxy dei dati e, per gli agenti ospitati, errori di creazione delle sessioni (errori 4xx). 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 possono allocare una macchina virtuale Micro per le nuove sessioni. Monitorare l'integrità del proxy dati e il completamento della creazione della sessione dell'agente ospitato come indicatori principali 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.
  • La creazione della sessione dell'agente ospitato ha esito negativo con errori 4xx.
  • 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 /24 per la produzione. /27 è il minimo ma rischioso. /26 è necessario per 50 sessioni simultanee.
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
Limiti dell'agente ospitato 100 revisioni attive e 1.000 revisioni totali per agente. Circa 200 agenti ospitati per istanza.
Consumo IP Le revisioni dell'agente ospitato consumano indirizzi IP. Nessuna revisione di agente di prompt.
Connettività in uscita Gli agenti ospitati usano una scheda di interfaccia di rete dedicata. Tutte le chiamate agli strumenti vengono instradate tramite il proxy dati a tenant singolo.
Ospitato rispetto a prompt Ospitato: CPU e memoria personalizzate, il Registro Azure Container dell'utente e scheda di interfaccia di rete dedicata. 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 Nessuna riduzione delle prestazioni dal ridimensionamento di uno dei due tipi di agente, con il ridimensionamento corretto della subnet.

Contenuto correlato

  • Last updated on