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.

Wenn Sie einen Codierungs-Agent wie GitHub Copilot verwenden, um Ihr VNet-, Subnetz- und Kapazitätsmodell zu planen, kann Ihnen das Microsoft Foundry Skill helfen, durch die Architektur zu gründen und Anleitungen für Foundry-Netzwerke in Ihrer eigenen Umgebung anzuwenden.

Ü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.

Das Architekturdiagramm zeigt das Foundry-Plattformnetzwerk auf der linken Seite mit dem Foundry-Endpunkt, einer Micro VM Host-Schicht, dem Tools Service und der Datenproxy-Host-Schicht. Auf der rechten Seite enthält das Kunden-VNet ein delegiertes Subnetz, das Micro VMs und den Data Proxy auf Azure Container Apps enthält, sowie ein separates privates Endpunkt-Subnetz für Speicher, SQL Database und Key Vault. Die Pfeile zeigen, dass der Datenverkehr der gehosteten Agents durch die Micro VM und der Datenverkehr der Prompt Agents direkt durch den Tools Service fließt. Beide Pfade laufen am Data Proxy zusammen und münden über private Endpunkte in die Ressourcen des Kunden.

Das Plattformnetzwerk beherbergt den Foundry-Endpunkt, die Micro VM-Hostebene, auf der Hosted Agents ausgeführt werden, den Tools Service und die Data Proxy-Hostebene. 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.
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.

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 als Ausgangspunkt für Produktions-Workloads und wählen Sie einen größeren Bereich, wenn Ihre erwartete Spitzenparallelität dies erfordert. Verwenden Sie kein /27-Subnetz für Produktionsworkloads. Obwohl /27 kleine Entwicklungs- oder Bereitstellungen zu Evaluierungszwecken unterstützen kann, bleibt nur 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.

Planen Sie die Subnetzkapazität in dieser Reihenfolge:

  1. Schätzen Sie den Spitzenwert der gleichzeitig gehosteten Agent-Sitzungen über alle Projekte im Konto hinweg für die Region. Projekte im Konto nutzen dieselbe Subnetzkapazität. Alle Foundry-Konten und -Projekte innerhalb desselben Abonnements und derselben Region verfügen jeweils über ein eigenes Sitzungskontingent.
  2. Überprüfen Sie das standardmäßige gleichzeitige Sitzungskontingent der Region in den Standarddienstgrenzwerten.
  3. Ordnen Sie das Subnetz so an, dass verwendbare IPs das Ziel erreichen oder überschreiten, indem Sie die Tabelle in subnetzgröße und gleichzeitigen Sitzungen verwenden. Halten Sie den geplanten Höchstwert unter 80% verwendbarer IPs, um Upgrade- und Skalierungsspitzen zu absorbieren.
  4. Wenn das Ziel den regionalen Standardwert überschreitet, fordern Sie eine Begrenzungserhöhung an. Geben Sie das Abonnement, die Region und die erwartete Parallelität an. Erhöhungen hängen von der regionalen Kapazität ab.
  5. Wenn Sie mehr Sitzungen benötigen als die verwendbaren IPs des Subnetzes zulassen und das Subnetz nicht wachsen kann, fordern Sie eine Erhöhung der IP-zu-Sitzung-Zuordnung in derselben Supportanfrage an.

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

IP-Adressen aus dem delegierten Subnetz unterstützen Sitzungen gehosteter Agents und Netzwerkkomponenten auf Projektebene. Der tatsächliche Verbrauch ändert sich mit der Anzahl gleichzeitiger Sitzungen, der Anzahl der Projekte, der Skalierung und der Plattformwartung. Dimensionieren Sie das Subnetz für die erwartete maximale Anzahl gleichzeitiger Sitzungen und halten Sie genügend ungenutzte Adressen für vorübergehende Kapazitätsanforderungen bereit. Planen Sie die Kapazität anhand der Sitzungen und nutzbaren Subnetz-IP-Adressen, nicht anhand von Infrastruktureinheiten wie Pods.

Subnetzgröße und gleichzeitige Sitzungen

Die Anzahl der pro Abonnement verfügbaren gleichzeitigen Agentsitzungen variiert je nach Region. Standardmäßig werden gleichzeitige Sitzungen und nutzbare Subnetz-IP-Adressen 1:1 zugeordnet, vorbehaltlich der für Ihre Region geltenden Obergrenze.

Subnetz Gesamte IP-Adressen Verwendbare IPs Ungefähre gleichzeitige Sitzungen
/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

Die Tabelle enthält allgemeine Subnetzgrößen und ist nicht vollständig. Sie können ein größeres unterstütztes Subnetz verwenden, wenn es ihrem privaten IP-Adressplan entspricht. Die zusätzlichen Adressen bieten zusätzliche Kapazität und betrieblichen Spielraum, erhöhen aber nicht das regionale Sitzungskontingent pro Abonnement.

In der Spalte "Ungefähre gleichzeitige Sitzungen " wird die Kapazität von verwendbaren Subnetz-IPs unter der Standardzuordnung geschätzt. Diese Werte sind keine Produktionsplanungsziele. Planen Sie eine geringere Parallelität ein, sodass Netzwerkkomponenten auf Projektebene und die empfohlene Betriebsreserve von 20 % ebenfalls in das Subnetz passen. Ihr regionales Sitzungskontingent pro Abonnement begrenzt zudem die tatsächliche Anzahl gleichzeitiger Sitzungen. Beispielsweise bietet in einer Region mit einem Kontingent von 1.000 Sitzungen ein Subnetz, das größer als /22 ist, zusätzliche IP-Reserven, erhöht jedoch nicht die Anzahl gleichzeitiger Sitzungen, es sei denn, Sie beantragen eine Kontingenterhöhung.

Eine Sitzung steht für die Rechenressourcen eines gehosteten Agenten und den persistenten Dateistatus, nicht für den Konversationsverlauf. Die Sitzungskapazität bestimmt daher nicht, wie viele Unterhaltungen Ihre Anwendung verwalten kann. Mit dem Responses-Protokoll ist eine Unterhaltung einer Sitzung zugeordnet, während andere Aufrufmuster eine Sitzung ohne von der Plattform verwalteten Unterhaltungsverlauf wiederverwenden können. Ausführliche Informationen finden Sie unter "Sitzungen im Vergleich zu Unterhaltungen".

Um mehr gleichzeitige Sitzungen innerhalb desselben Subnetzes zu unterstützen, erstellen Sie eine Azure-Support Anforderung. Geben Sie in der Anforderung das Abonnement, die Region und die erwartete Anzahl gleichzeitiger Sitzungen an. Basierend auf Ihren Anforderungen und regionalen Kapazitäten kann die Unterstützung die Zuordnung auf 10 gleichzeitige Sitzungen pro verwendbarer IP (1:10) erhöhen. Informationen zum standardmäßigen gleichzeitigen Sitzungskontingent pro Region finden Sie unter Foundry Agent Service-Kontingente.

Projektkapazität

Eine Foundry-Instanz unterstützt ca. 250 Projekte mit geringem Datenverkehr. Unter hoher Last kann die effektive Grenze, wenn Agenten viele gleichzeitige Sitzungen haben, auf nur noch ~25 Projekte sinken. 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.

Ausgehende Konnektivität

Gehostete Agents werden in MicroVMs ausgeführt, die an Ihr delegiertes Subnetz angefügt sind und diese für ausgehende Kommunikation verwenden. Tool-Aufrufe werden immer über den Daten-Proxy für einen Mandanten geroutet. Für Quellcode-Agent-Bereitstellungen erfordert der Bereitstellungsschritt auch ausgehenden Zugriff auf bestimmte Endpunkte. Siehe Firewallanforderungen für private virtuelle Netzwerke.

Leistung und Skalierung

Gehostete Agents unterstützen benutzerdefinierte CPU- und Speicherkonfigurationen. Sie wählen beim Erstellen einer Agentversion aus den verfügbaren CPU- und Arbeitsspeicherpaaren aus. Das Starten oder Fortsetzen einer Sitzung kann die Bereitstellung von Rechenressourcen erfordern. Wenn das Subnetz nicht über genügend verfügbare IP-Adressen verfügt, kann die Plattform keine Rechenkapazität für zusätzliche Sitzungen provisionieren.

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.

Versionen und IP-Nutzung

Im Gegensatz zu gehosteten Agent-Sitzungen verbrauchen Prompt-Agent-Versionen keine IPs. Netzwerkkomponenten auf Projektebene belegen weiterhin Adressen aus dem delegierten Subnetz.

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 IP-Erschöpfung sind HTTP 5xx-Fehler vom Datenproxy und für gehostete Agents HTTP 429-Fehler subnet_exhausted während der Sitzungserstellung oder -fortsetzung. Wenn keine IP-Adressen mehr verfügbar sind, schlagen die Skalierung des Datenproxys und die Bereitstellung neuer Projekte fehl, und gehostete Agenten können keine Rechenressourcen für neue oder wiederaufgenommene Sitzungen bereitstellen. Überwachen Sie den Status des Datenproxys und den Erfolg von Sitzungen gehosteter 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.
  • Das Erstellen oder Fortsetzen einer gehosteten Agent-Sitzung schlägt mit HTTP 429-Fehlern subnet_exhausted fehl.
  • Neue Projektbereitstellungsfehler.

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 Verwenden Sie /24 oder größer für die Produktion. /27 ist das Minimum, aber riskant. Bei der standardmäßigen Zuordnung von 1:1 reicht die Subnetzkapazität von ca. 20 gleichzeitigen Sitzungen mit /27 bis 2.000 mit /21. Dimensionieren Sie auf weniger als 80 % Auslastung, oder beantragen Sie über den Azure-Support eine 1:10-Zuordnung (eine IP-Adresse für 10 Sitzungen).
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.
Projektkapazität ~250 Projekte bei geringem Traffic, so wenige wie ~25 bei voller Auslastung. Gesteuert von der IP-Verfügbarkeit.
IP-Verbrauch Sitzungen gehosteter Agents und Netzwerkkomponenten auf Projektebene verbrauchen IP-Adressen. Prompt-Agent-Versionen nicht.
Ausgehende Konnektivität Gehostete Agentsitzungen verwenden das delegierte Subnetz. Alle Tool-Aufrufe werden über den Daten-Proxy für einen Mandanten geroutet.
Hosted im Vergleich zu Prompt Gehostet: benutzerdefinierte CPU, Arbeitsspeicher sowie Ihr ACR. 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 Das Starten oder Fortsetzen einer Sitzung kann die Bereitstellung von Rechenressourcen erfordern. Die Erschöpfung der IP-Adressen verhindert, dass Compute für zusätzliche Sitzungen bereitgestellt werden kann.

Verwandte Inhalte

  • Zuletzt aktualisiert um