Tiefer Einblick in das Netzwerk des Foundry Agent Service

Wenn Sie Microsoft Foundry Agent Service mit einem bring-your-own virtual network (VNet) ausführen, sind Sie dafür verantwortlich, das delegierte Subnetz zu skalieren, die IP-Zuordnung zu planen und zu verstehen, wie der Agentdatenverkehr über die Plattform fließt. In diesem Artikel werden die Netzwerkarchitektur hinter gehosteten und Prompt-Agents, das IP-Zuweisungsmodell und die Signale erläutert, die Kapazitätsprobleme anzeigen. Es ist für Cloud- und Netzwerkarchitekten vorgesehen, die bereits ein Bring-your-own-VNet für den Foundry Agent Service gewählt haben. Informationen zum Konfigurieren des Netzwerks finden Sie unter Einrichten privater Netzwerke für den Foundry-Agent-Dienst.

Übersicht über die Netzwerkarchitektur

Das folgende Diagramm zeigt die beiden Zonen, die an jeder Anforderung des Foundry Agent Service beteiligt sind: das netzwerk der Microsoft verwalteten Foundry-Plattform auf der linken Seite und Das VNet Ihres Kunden auf der rechten Seite.

Architekturdiagramm, das das Foundry-Plattformnetzwerk links zeigt mit dem Foundry-Endpunkt, einer Micro-VM-Hostebene, dem Tools-Dienst und der Datenproxy-Hostebene. Rechts enthält das Kunden-VNet ein delegiertes Subnetz mit Micro-VMs und dem Datenproxy auf Azure Container Apps sowie ein separates privates Endpunktsubnetz für Speicher, SQL-Datenbank und Key Vault. Pfeile zeigen den Verkehr des gehosteten Agents, der über die Micro-VM-Ebene fließt, und den Agent-Verkehr, der direkt über den Tools-Dienst verläuft. Beide Pfade werden am Datenproxy zusammengeführt und gelangen über private Endpunkte zu den Ressourcen des Kunden.

Das Plattformnetzwerk hostet den Foundry Endpunkt, die Micro VM Host-Schicht, auf der gehostete Agents, der Tools Service und die Data Proxy Host-Schicht ausgeführt werden. Ihr Kunden-VNet enthält ein delegiertes Subnetz (in dem Micro-VMs und der Datenproxy IPs nutzen) und ein privates Endpunktsubnetz, das eine Verbindung mit Ihrem Speicher, Ihren Datenbanken und Key Vault herstellt.

Zwei Anforderungsflüsse durchlaufen diese Architektur:

  • Gehosteter Agent: Client zu Foundry-Endpunkt zu Micro VM (/invoke) zu Tools-Dienst zu Data Proxy zu Kundenressourcen über private Endpunkte.
  • Prompt-Agent: Client zu Foundry-Endpunkt zu Tools-Dienst zu Daten-Proxy zu Kundenressourcen über private Endpunkte. Auf diesem Pfad gibt es keine Micro-VM.

Schlüsselkonzepte

Begriff Was dies bedeutet
Foundry-Instanz Ihre Microsoft Foundry-Ressource. Der Container der obersten Ebene, der Ihre Projekte, Agents und Netzwerkkonfiguration enthält.
Gehosteter Agent Ein Agent, den Sie selbst erstellen und bereitstellen, indem Sie Ihr eigenes Containerimage über Azure Container Registry verwenden. Sie steuern CPU, Arbeitsspeicher und Code. Wird auf Azure Container Apps ausgeführt.
Prompt-Agent Ein Agent, bei dem Die Berechnung und Skalierung von Microsoft vollständig verwaltet werden. Sie definieren das Verhalten über die Konfiguration. Es ist kein Containerimage oder keine Infrastrukturverwaltung erforderlich.
Daten-Proxy für einen einzigen Mandanten Eine plattformverwaltete Netzwerkkomponente für Ihr Foundry-Projekt, die ausgehende Konnektivität für Ihre Agents verarbeitet. Jedes Projekt erhält eine eigene isolierte Datenproxyinstanz. Alle Toolaufrufe werden über den Datenproxy geleitet.
Toolserver Ein Back-End-Dienst, der auf Projektebene registriert ist, den Ihre Agents aufrufen können, um Aktionen auszuführen, z. B. Abfragen einer Datenbank oder Aufrufen einer externen API. In Bring-Your-Own-VNet-Konfigurationen wird der Datenverkehr des Tools-Servers über den mandantenfähigen Daten-Proxy geleitet.
Delegiertes Subnetz Das Subnetz in Ihrem VNet, das Sie an den Foundry Agent Service delegieren. Die gesamte Infrastruktur der Agents (Daten-Proxys und Micro VMs) wird in diesem Subnetz bereitgestellt und verbraucht IPs davon.
Micro-VM Der einfache virtuelle Computer, auf dem ein gehosteter Agent ausgeführt wird.
Version Eine Änderung, die sich darauf auswirkt, wie Ihr Agent ausgeführt wird, z. B. neuer Code, ein neues Containerimage oder ein Konfigurationsupdate. Nur laufzeitbeeinflusste Änderungen erstellen eine neue Version.
Revision Die Bereitstellungseinheit für Ihren Agenten. Eine Überarbeitung kann versionsgeschützt (an eine Laufzeitänderung gebunden) oder nicht versionsgebunden sein (nur Metadatenänderungen wie Tags oder Skalierungseinstellungen).

Wie der Verkehr fließt

Jede Anfrage für den Foundry Agent Service geht am Foundry-Endpunkt ein und wird über private Endpunkte an die Ressourcen Ihres Kunden weitergeleitet. Der Agenttyp bestimmt, was dazwischen passiert.

Eingehend zum Foundry-Endpunkt

Clients senden HTTPS-Anforderungen an Ihren Foundry-Endpunkt (z. B <your-resource>.services.ai.azure.com. ). Das API-Gateway der Plattform authentifiziert die Anforderung und leitet sie basierend auf dem Ziel-Agent-Typ weiter.

Pfad des gehosteten Agents

Bei einem gehosteten Agent leitet die Plattform die Anforderung an eine Micro-VM in Ihrem delegierten Subnetz über das /invoke Protokoll weiter. Die Micro-VM verfügt über zwei Netzwerkschnittstellen:

Datenverkehrstyp Route
Der eigene ausgehende Datenverkehr des Agents Direkt über die dedizierte NIC der Micro-VM im delegierten Subnetz.
Toolserveraufrufe Über den Proxy für mandantenfähige Daten, unabhängig vom Agenttyp.

Obwohl die Micro-VM über eine eigene NIC verfügt, wird jeder Toolaufruf über den Datenproxy weitergeleitet.

Prompt-Agent-Pfad

Für einen Prompt-Agent wird der Agent in von Microsoft verwaltetem Compute ausgeführt. Der Foundry-Endpunkt leitet die Anfrage direkt an den Tools-Dienst weiter, der den mandantenfähigen Datenproxy aufruft. IPs werden auf Projektebene zugewiesen, sodass alle Prompt-Agents innerhalb eines Projekts dieselbe Daten-Proxy-Infrastruktur nutzen.

Ausgehender Verkehr zu Kundenressourcen

Ausgehender Datenverkehr vom Daten-Proxy erreicht Ihre Storage-Kontos, Datenbanken und Key Vault über private Endpunkte in Ihrem privaten Subnetz für Endpunkte. Konfigurieren Sie die entsprechenden privaten DNS-Zonen (z. B. privatelink.blob.core.windows.net, privatelink.database.windows.net und privatelink.vaultcore.azure.net), damit die Namensauflösung innerhalb des VNet bleibt.

Subnetzgröße und IP-Zuordnung

Die Subnetzkonfiguration gilt auf der Ebene des Foundry-Kontos. Alle Projekte im Konto teilen sich die gleiche Subnetz-Konfiguration, und gehostete und Prompt Agents teilen sich das gleiche delegierte Subnetz. Die empfohlene Größe muss die kombinierte IP-Nutzung von Agents in allen Projekten, Plattformupgrades und Skalierungsereignissen abdecken.

Verwenden Sie einen /24-CIDR-Bereich für Produktionsarbeitslasten. Ein /27-Subnetz kann für kleinere Bereitstellungen funktionieren, aber es bleibt sehr wenig Spielraum. Plattformupgrades, Rollouts und Skalierungsereignisse benötigen alle temporäre zusätzliche IPs, und ein kleines Subnetz kann während dieser Vorgänge erschöpft werden.

Unterstützte IP-Bereiche

Ihr Subnetz muss nur RFC 1918 private IPv4-Bereiche verwenden:

  • 10.0.0.0/8
  • 172.16.0.0/12 (deckt 172.16.x.x bis 172.31.x.x ab)
  • 192.168.0.0/16

Öffentliche IP-Bereiche und CGNAT-Bereiche (z. B. 100.64.0.0/10) werden nicht unterstützt und verursachen Routing-Fehler.

Wie IPs verbraucht werden

IPs sind im Verhältnis von etwa 1 IP pro 10 Pods reserviert. Jedes Foundry-Projekt erhält einen Daten-Proxy, der bei 1 Pod (1 Replik) beginnt und mit dem Datenverkehr horizontal skaliert.

Szenario Beispiel IP-Auswirkungen
Geringer Datenverkehr 10 Projekte, mit jeweils 1 Replikat ~1 IP-Adresse verteilt auf 10 Pods
Hoher Datenverkehr 10 Projekte, die jeweils auf 10 Replikate skaliert wurden 100 Pods, ~10 IPs

Die Kapazität von Projekten ist dynamisch, da mehr Datenverkehr pro Projekt mehr IPs verbraucht.

Subnetzgröße und gleichzeitige Sitzungen

Die Plattform unterstützt maximal 50 gleichzeitige Agentsitzungen pro Abonnement pro Region. Ihre Subnetzgröße bestimmt, ob Sie dieses Maximum erreichen können.

Subnetz Gesamte IP-Adressen Verwendbare IPs Ungefähre gleichzeitige Sitzungen
/27 32 ~27 ~17
/26 64 ~59 ~50 (maximal unterstützt)

Verwenden Sie ein /26 Subnetz oder größer, um die vollständigen 50 gleichzeitigen Sitzungen zu unterstützen.

Projektkapazität

Eine Foundry-Instanz unterstützt ca. 250 Projekte mit geringem Datenverkehr. Wenn Agents bei starkem Datenverkehr auf viele Replikate skalieren, kann die effektive Grenze auf so wenige wie ~25 Projekte fallen. Wenn IPs erschöpft sind, schlägt die neue Projektbereitstellung fehl.

Wichtig

Planen Sie nicht, mit der theoretischen Maximalkapazität zu laufen. Zielen Sie auf maximal 80% Subnetzauslastung ab, um Spitzen von Upgrades und Skalierung zu absorbieren.

Verhalten während der Plattformwartung

Plattformupgrades betreiben sowohl alte als auch neue Infrastruktur parallel, wodurch der Verbrauch von IP-Adressen vorübergehend erhöht wird. Ein /24-Subnetz bietet genügend Puffer, um diese temporären Spitzen zusammen mit Ihren normalen Workloads zu verarbeiten. Infrastrukturupgrades werden vollständig Microsoft verwaltet, einschließlich ihrer Zeitplanung.

Netzwerkverhalten gehosteter Agents

Gehostete Agents werden auf Azure Container Apps ausgeführt und ermöglichen Ihnen die Kontrolle über die CPU- und Arbeitsspeicherkonfiguration. Sie stellen sie über Ihre eigene Azure Container Registry bereit.

Überarbeitungen und IP-Nutzung

Wenn Sie ein Update (neues Image, eine neue Konfiguration oder code) bereitstellen, erstellt die Plattform eine neue Revision. Während der Einführung laufen alte und neue Ausführungen parallel, da sich der Datenverkehr auf die neue Version verlagert, und beide verbrauchen IPs aus Ihrem Subnetz.

Revisionsgrenzwerte pro gehosteten Agent:

  • 100 aktive Revisionen pro Agent.
  • 1.000 Gesamtrevisionen pro Agentname. Älteste inaktive Überarbeitungen werden automatisch gelöscht, wenn der aktive Grenzwert erreicht wird.
  • Ungefähr 200 gehostete Agents pro Foundry-Instanz (Vorschau).

Der Grenzwert von 200 gehosteten Agenten unterscheidet sich von der Projektobergrenze von ~250, die instanzweit für alle Agenttypen gilt.

Ausgehende Konnektivität

Jeder gehostete Agent wird in einer Micro-VM ausgeführt, die mit Ihrem delegierten Subnetz mit einer dedizierten Netzwerkschnittstelle verbunden ist und eine eigene IP für ausgehende Kommunikation verwendet. Tool-Aufrufe werden immer über den Daten-Proxy für einen Mandanten geroutet.

Leistung und Skalierung

Die Skalierung gehosteter Agents führt nicht zu Latenz oder Leistungsbeeinträchtigung. Das einzige Szenario, in dem die Leistung beeinträchtigt wird, ist, wenn die IP-Ausschöpfung verhindert, dass die Plattform skaliert wird, was mit der richtigen Subnetzgröße vermieden werden kann. Gehostete Agents unterstützen benutzerdefinierte CPU- und Speicherkonfigurationen. Sie wählen beim Erstellen einer Agentversion aus den verfügbaren CPU- und Arbeitsspeicherpaaren aus.

Netzwerkverhalten der Prompt Agents

Prompt-Agenten werden auch auf Azure Container Apps ausgeführt, aber die Rechenleistung und Skalierung werden vollständig von Microsoft verwaltet. Sie konfigurieren keine CPU oder keinen Arbeitsspeicher.

Überarbeitungen und IP-Nutzung

Im Gegensatz zu gehosteten Agents verbrauchen Prompt-Agent-Revisionen keine IPs. Der Daten-Proxy wird im Single-Revision-Modus ausgeführt, so dass inaktive Ausführungen keinen Einfluss auf die IP-Verfügbarkeit haben.

Ausgehende Konnektivität

Prompt Agents verwenden den Single-Tenant-Daten-Proxy für alle ausgehenden Verbindungen. IPs werden auf Projektebene zugewiesen, sodass alle Eingabeaufforderungs-Agents innerhalb eines Projekts dieselbe Datenproxyinfrastruktur nutzen.

Grenzwerte und Leistung

Die Anzahl der Prompt-Agents, die Sie pro Foundry-Instanz bereitstellen können, ist nicht begrenzt. da die Berechnung und Skalierung vollständig verwaltet werden, sind keine Latenz- oder Leistungsprobleme zu erwarten, die an die Anzahl der bereitgestellten Prompt-Agenten gebunden sind.

VNet-Peering und IP-Überlappung

Überlappende IP-Bereiche verursachen Routingfehler, sodass alle peered-VNets eindeutige, nicht überlappende IP-Bereiche verwenden müssen. Diese Regel gilt auch für bidirektionale Peeringkonfigurationen. Nur private IPv4-Bereiche von RFC 1918 werden unterstützt. CGNAT-Adressen (z. B. 100.x.x.x) sind es nicht.

Wenn Sie keine IP-Überlappung vermeiden können, verwenden Sie verwaltetes virtuelles Netzwerk anstelle von bring-your-own VNet. Das verwaltete VNet automatisiert die Netzwerkeinrichtung und beseitigt Bedenken hinsichtlich IP-Überschneidungen.

Überwachen der IP-Nutzung und Erkennen der Erschöpfung

Das Azure-Portal macht derzeit keine IP-Auslastung für delegierte Subnetze verfügbar, sodass Sie sie nicht direkt überwachen können. Die primären Indikatoren für die Erschöpfung der IPs sind HTTP 5xx-Fehler vom Datenproxy und, für gehostete Agents, Fehler bei der Sitzungserstellung (4xx-Fehler). Wenn die IPs erschöpft sind, schlagen die Skalierung des Daten-Proxys und die Bereitstellung neuer Projekte fehl, und gehostete Agents können keine Micro VM für neue Sitzungen zuweisen. Überwachen Sie den Zustand des Daten-Proxys und die erfolgreiche Erstellung von Sitzungen durch gehostete Agents als Frühindikatoren für Kapazitätsprobleme.

Erwägen Sie die Bereitstellung einer neuen Foundry-Instanz mit einem neuen Subnetz, wenn Sie Folgendes beobachten:

  • Der Datenproxy gibt einen 5xx-Fehler zurück.
  • Die Erstellung von gehosteten Agentsitzungen schlägt mit 4xx-Fehlern fehl.
  • Neue Projektbereitstellungsfehler.
  • Ungefähr 80% Ihrer geschätzten nutzbaren IP-Kapazität sind im Einsatz.

Wichtig

Die Plattform warnt Sie nicht proaktiv, wenn die IP-Kapazität niedrig ist. Überwachen Sie die zuvor aufgeführten Signale, um unerwartete Bereitstellungsfehler zu vermeiden.

Kurzübersicht

Thema Empfehlung
Subnetzgröße /24 für die Produktion. /27 ist das Minimum, aber riskant. /26 ist für 50 gleichzeitige Sitzungen erforderlich.
Auslastungsziel Bleiben Sie unter 80% Subnetznutzung, um Upgrade- und Skalierungsspitzen zu absorbieren.
Unterstützte IP-Bereiche NUR RFC 1918: 10.x, 172.16 bis 172.31.x, und 192.168.x. Keine öffentlichen oder CGNAT-Bereiche.
Projekt-Kapazität ~250 Projekte bei geringem Traffic, so wenige wie ~25 bei voller Auslastung. Gesteuert von der IP-Verfügbarkeit.
Grenzwerte für gehostete Agenten 100 aktive Überarbeitungen und 1.000 Gesamtrevisionen pro Agent. ~200 gehostete Agenten pro Instanz.
IP-Verbrauch Gehostete Agent-Revisionen verbrauchen IPs. Prompt-Agent-Überarbeitungen erfolgen nicht.
Ausgehende Konnektivität Gehostete Agents verwenden eine dedizierte NIC. Alle Tool-Aufrufe werden über den Daten-Proxy für einen Mandanten geroutet.
Hosted im Vergleich zu Prompt Gehostet: benutzerdefinierte CPU und Arbeitsspeicher, Ihr ACR, dedizierte NIC. Prompt: Vollständig verwaltete Skalierung.
VNet-Peering Peered VNets dürfen sich nicht überschneidende IP-Bereiche haben. Verwenden Sie verwaltetes VNet, wenn Überlappungen vorhanden sind.
Überwachung Keine direkte IP-Überwachung im Portal. Achten Sie auf Datenproxy 500-Fehler.
Leistung Keine Beeinträchtigung der Skalierung für beide Agententypen bei korrekter Subnetzgröße.

Verwandte Inhalte

  • Last updated on