Análisis detallado del servicio de redes Foundry Agent.

Al ejecutar el servicio de agente de Microsoft Foundry con su propia red virtual (VNet), usted es responsable de dimensionar la subred delegada, planificar la asignación de IP y comprender cómo fluye el tráfico del agente a través de la plataforma. En este artículo se explica la arquitectura de red detrás de agentes hospedados y agentes bajo demanda, el modelo de asignación de IP y las señales que indican problemas de capacidad. Está destinado a arquitectos de la nube y de redes que ya hayan optado por la opción de aportación de la propia red virtual para Foundry Agent Service. Para configurar la red, consulte Configuración de redes privadas para foundry Agent Service.

Si usa un agente de codificación como GitHub Copilot para planear el modelo de red virtual, subred y capacidad, la aptitud de Microsoft Foundry puede ayudarle a razonar a través de la arquitectura y aplicar las instrucciones de red de Foundry en su propio entorno.

Introducción a la arquitectura de red

En el diagrama siguiente se muestran las dos zonas implicadas en cualquier solicitud de servicio del agente de Foundry: la red de plataforma Foundry administrada por Microsoft a la izquierda y la red virtual del cliente a la derecha.

Diagrama de arquitectura que muestra, a la izquierda, la red de la plataforma Foundry con el punto de conexión de Foundry, una capa de host de Micro VM, el servicio de herramientas y la capa de host del proxy de datos. A la derecha, la VNet del cliente contiene una subred delegada que alberga Micro VM y el proxy de datos en Azure Container Apps, además de una subred de puntos de conexión privados independiente para el almacenamiento, la base de datos SQL y Key Vault. Las flechas muestran el tráfico del agente alojado que fluye a través de la Micro VM y el tráfico del agente de solicitud que fluye directamente a través del servicio de herramientas. Ambas rutas convergen en el proxy de datos y salen hacia los recursos del cliente a través de puntos de conexión privados.

La red de la plataforma aloja el extremo de Foundry, la capa anfitriona de Micro VM que ejecuta agentes alojados, el Servicio de Herramientas y la capa anfitriona del proxy de datos. La red virtual del cliente contiene una subred delegada (donde las máquinas virtuales micro y el proxy de datos consumen direcciones IP) y una subred de punto de conexión privado que se conecta a su almacenamiento, bases de datos y Key Vault.

Dos flujos de solicitud atraviesan esta arquitectura:

  • Agente hospedado: desde el cliente al punto de conexión de Foundry, a Micro VM (/invoke), al Servicio de Herramientas, al Proxy de Datos, hasta los recursos del cliente a través de puntos de conexión privados.
  • Agente de solicitudes: del cliente al punto de conexión de Foundry, al servicio de herramientas, al proxy de datos y a los recursos del cliente a través de puntos de conexión privados. No hay ninguna micro VM en esta ruta.

Conceptos clave

Término Lo que significa
Instancia de Foundry El recurso de Microsoft Foundry. Contenedor de nivel superior que contiene los proyectos, agentes y configuración de red.
Agente hospedado Un agente que compile e implemente usted mismo mediante su propia imagen de contenedor a través de Azure Container Registry. Puede controlar la CPU, la memoria y el código. Se ejecuta en Azure Container Apps.
Agente de aviso Un agente en el que el proceso y el escalado están totalmente administrados por Microsoft. El comportamiento se define a través de la configuración. No se requiere ninguna imagen de contenedor ni administración de infraestructura.
Proxy de datos de entidad única Un componente de red administrado por la plataforma dedicado a su proyecto Foundry, que controla la conectividad saliente para los agentes. Cada proyecto obtiene su propia instancia de proxy de datos aislada. Todas las llamadas a herramientas se enrutan a través del proxy de datos.
Servidor de herramientas Un servicio back-end registrado en el nivel de proyecto al que los agentes pueden llamar para realizar acciones, como consultar una base de datos o invocar una API externa. En configuraciones de aportación de la propia red virtual, el tráfico del servidor de herramientas se enruta a través del proxy de datos de un solo inquilino.
Subred delegada La subred en la red virtual que delega al Foundry Agent Service. Toda la infraestructura del agente (servidores proxy de datos y máquinas virtuales micro) se implementa en esta subred y consume direcciones IP de ella.
Micro VM Máquina virtual ligera que ejecuta un agente hospedado.
Versión Cambio que afecta a cómo se ejecuta el agente, como código nuevo, una nueva imagen de contenedor o una actualización de configuración. Solo los cambios que afectan al entorno de ejecución crean una nueva versión.
Revisión Unidad de implementación del agente. Una revisión se puede versionar (vinculada a un cambio en tiempo de ejecución) o no versionada (cambios de solo metadatos, como etiquetas o configuración de escalado).

Cómo fluye el tráfico

Todas las solicitudes de Foundry Agent Service entran por el punto de conexión de Foundry y salen hacia los recursos de sus clientes a través de puntos de conexión privados. El tipo de agente determina lo que sucede en el intermedio.

Entrada al punto de conexión de Foundry

Los clientes envían solicitudes HTTPS al punto de conexión de Foundry (por ejemplo, <your-resource>.services.ai.azure.com). La puerta de enlace de API de la plataforma autentica la solicitud y la enruta en función del tipo de agente de destino.

Ruta de acceso del agente hospedado

Para un agente hospedado, la plataforma reenvía la solicitud a una máquina virtual micro en la subred delegada a través del /invoke protocolo. La máquina virtual micro tiene dos interfaces de red:

Tipo de tráfico Ruta
Tráfico saliente gestionado por el propio agente Directamente, a través de la NIC dedicada de la micro máquina virtual en la subred delegada.
Llamadas del servidor de herramientas A través del proxy de datos de un solo inquilino, independientemente del tipo de agente.

Aunque la máquina virtual de Micro tiene su propia NIC, cualquier invocación de herramienta se enruta a través del proxy de datos.

Ruta del agente de solicitudes

Para un agente de solicitudes, el agente se ejecuta en un proceso administrado por Microsoft. El punto de conexión de Foundry reenvía la solicitud directamente al servicio de herramientas, que llama al proxy de datos para un solo inquilino. Las direcciones IP se asignan a nivel de proyecto, por lo que todos los agentes de consulta dentro de un proyecto comparten la misma infraestructura de proxy de datos.

Salida a los recursos del cliente

El tráfico saliente del proxy de datos llega a sus cuentas de almacenamiento, bases de datos y Key Vault a través de puntos de conexión privados de su subred de puntos de conexión privados. Configure las zonas de DNS privado correspondientes (por ejemplo, privatelink.blob.core.windows.net, privatelink.database.windows.net y privatelink.vaultcore.azure.net) para que la resolución de nombres permanezca dentro de la VNet.

Ajuste de tamaño de subred y asignación de IP

La configuración de subred se aplica en el nivel de cuenta de Foundry. Todos los proyectos de la cuenta comparten una misma configuración de subred, y los agentes hospedados y de solicitudes comparten la misma subred delegada. El tamaño recomendado tiene que cubrir el uso de IP combinado de los agentes en todos los proyectos, actualizaciones de plataforma y eventos de escalado.

Utilice un rango /24 CIDR para cargas de trabajo de producción. Una subred /27 puede funcionar para implementaciones más pequeñas, pero deja muy poco margen de maniobra. Las actualizaciones de la plataforma, los lanzamientos y los eventos de escalado necesitan direcciones IP adicionales temporales y una subred pequeña puede agotarse durante estas operaciones.

Intervalos IP admitidos

La subred debe usar solo intervalos IPv4 privados de RFC 1918 :

  • 10.0.0.0/8
  • 172.16.0.0/12 (cubre desde 172.16.x.x hasta 172.31.x.x)
  • 192.168.0.0/16

Los intervalos IP públicos y los intervalos de CGNAT (por ejemplo, 100.64.0.0/10) no se admiten y provocan errores de enrutamiento.

Cómo se consumen las direcciones IP

Las direcciones IP se reservan aproximadamente con una relación de 1 IP por 10 pods . Cada proyecto de Foundry obtiene un proxy de datos que comienza con un solo pod (1 réplica) y se escala con el tráfico.

Escenario Ejemplo Impacto en IP
Tráfico bajo 10 proyectos, cada uno en 1 réplica ~1 IP compartida en 10 pods
Tráfico elevado 10 proyectos, cada uno escalado a 10 réplicas 100 pods, ~10 IP

La capacidad del proyecto es dinámica porque más tráfico por proyecto consume más direcciones IP.

Tamaño de subred y sesiones simultáneas

El número de sesiones de agente simultáneas disponibles por suscripción varía según la región. De forma predeterminada, las sesiones simultáneas y las direcciones IP de subred utilizables se corresponden en una proporción de 1:1, según el límite de su región.

Subred Número total de direcciones IP Direcciones IP utilizables Sesiones simultáneas aproximadas
/27 32 ~27 ~17
/26 64 ~59 ~50 (máximo admitido)

Con la asignación predeterminada de 1:1, utiliza una subred /26 o mayor para admitir 50 sesiones simultáneas.

Para admitir más sesiones simultáneas con la misma subred, cree una solicitud de Soporte técnico de Azure. En la solicitud, especifique la suscripción, la región y el número esperado de sesiones simultáneas. En función de sus requisitos y de la capacidad regional, el equipo de soporte puede aumentar la proporción hasta 10 sesiones simultáneas por cada IP utilizable (1:10).

Capacidad del proyecto

Una instancia de Foundry admite aproximadamente 250 proyectos con poco tráfico. Con tráfico pesado, cuando los agentes se escalan a muchas réplicas, el límite efectivo puede reducirse a tan solo ~25 proyectos. Cuando se agotan las direcciones IP, se produce un error en el aprovisionamiento de nuevos proyectos.

Importante

No planee funcionar a una capacidad máxima teórica. Tenga como objetivo un máximo de 80% de utilización de la subred para absorber picos de actualizaciones y escalamiento.

Comportamiento durante el mantenimiento de la plataforma

Las actualizaciones de la plataforma ejecutan una infraestructura antigua y nueva en paralelo, lo que aumenta temporalmente el consumo de IP. Una subred /24 proporciona suficiente búfer para controlar estos picos temporales junto con las cargas de trabajo normales. Las actualizaciones de infraestructura se administran completamente por Microsoft, incluido su tiempo.

Comportamiento de redes de agentes hospedados

Los agentes hospedados se ejecutan en Azure Container Apps y le proporcionan control sobre la configuración de CPU y memoria. Puede desplegarlos mediante su propio Azure Container Registry.

Revisiones y uso de IP

Al implementar una actualización (nueva imagen, configuración o código), la plataforma crea una nueva revisión. Durante el despliegue, las revisiones antiguas y nuevas se ejecutan en paralelo a medida que el tráfico cambia a la nueva versión, y ambas consumen direcciones IP de la subred.

Límites de revisión por agente hospedado:

  • 100 revisiones activas por agente.
  • 1000 revisiones totales por nombre de agente. Las revisiones inactivas más antiguas se purgan automáticamente cuando se alcanza el límite activo.
  • Aproximadamente 200 agentes hospedados por instancia de Foundry.

El límite de 200 agentes alojados es independiente del límite de ~250 proyectos, que se aplica a toda la instancia, independientemente del tipo de agente.

Conectividad saliente

Cada agente hospedado se ejecuta en una máquina virtual micro conectada a la subred delegada con una interfaz de red dedicada y usa su propia dirección IP para la comunicación saliente. Las llamadas de la herramienta siempre se enrutan a través del proxy de datos de un solo inquilino. En el caso de las implementaciones del agente de código fuente, el paso de aprovisionamiento también requiere acceso saliente a puntos de conexión específicos. Consulte Requisitos de firewall para redes virtuales privadas.

Rendimiento y escalado

El escalado de agentes hospedados no presenta latencia ni degradación del rendimiento. El único escenario en el que se ve afectado el rendimiento es cuando el agotamiento de IP impide que la plataforma se ecale, lo que es evitable con el ajuste de tamaño de subred adecuado. Los agentes hospedados admiten configuraciones personalizadas de CPU y memoria. Seleccione entre pares de CPU y memoria disponibles al crear una versión del agente.

Incitar el comportamiento de redes de los agentes

Los agentes de solicitudes también se ejecutan en Azure Container Apps, pero el procesamiento y el escalado están totalmente administrados por Microsoft. No configura la CPU ni la memoria.

Revisiones y uso de IP

A diferencia de los agentes alojados, las revisiones del agente de solicitudes no consumen IP. El proxy de datos se ejecuta en modo de revisión única, por lo que las revisiones inactivas no tienen ningún impacto en la disponibilidad de IP.

Conectividad saliente

Los agentes de solicitudes utilizan el proxy de datos de un solo inquilino para toda la conectividad de salida. Las direcciones IP se asignan en el nivel de proyecto, por lo que todos los agentes de prompt dentro de un proyecto comparten la misma infraestructura de proxy para datos.

Límites y rendimiento

No hay un límite estricto en cuanto al número de agentes de solicitudes que se pueden implementar por cada instancia de Foundry. Dado que la computación y el escalado están totalmente gestionados, no se esperan problemas de latencia o rendimiento vinculados al número de agentes de solicitud implementados.

Emparejamiento de VNet y superposición de direcciones IP

Los intervalos IP superpuestos provocan errores de enrutamiento, por lo que todas las redes virtuales emparejadas deben usar intervalos IP únicos y no superpuestos. Esta regla también se aplica a las configuraciones de emparejamiento bidireccional. Solo se admiten intervalos IPv4 privados de RFC 1918. Las direcciones CGNAT (por ejemplo, 100.x.x.x) no lo son.

Si no puede evitar la superposición de IP, utilice la red virtual administrada en lugar de la aportación de la propia red virtual. La red virtual administrada automatiza la configuración de red y elimina los problemas de superposición de IP.

Supervisión del uso de IP y detección de agotamiento

El portal de Azure no expone actualmente el uso de IP para subredes delegadas, por lo que no puede supervisarla directamente. Los indicadores principales de agotamiento de IP son errores HTTP 5xx del proxy de datos y, para agentes hospedados, errores de creación de sesión (errores 4xx). Cuando se agotan las direcciones IP, se produce un error en el escalado de proxy de datos y en el aprovisionamiento de nuevos proyectos, y los agentes alojados no pueden asignar una Micro VM para las nuevas sesiones. Supervise el estado de los proxy de datos y el éxito en la creación de sesiones de los agentes alojados como principales indicadores de problemas de capacidad.

Considere la posibilidad de implementar una nueva instancia de Foundry con una subred nueva al observar:

  • El proxy de datos devuelve errores 5xx.
  • Falló la creación de la sesión del agente hospedado debido a errores 4xx.
  • Fallos en la provisión de nuevos proyectos.

Importante

La plataforma no le advierte proactivamente cuando la capacidad de IP está baja. Supervise las señales enumeradas anteriormente para evitar errores de aprovisionamiento inesperados.

Referencia rápida

Tema Recomendación
Tamaño de subred Utilice /24 en producción. /27 es el mínimo pero arriesgado. Con la asignación predeterminada de 1:1, necesitas una subred /26 para 50 sesiones simultáneas. Solicite más sesiones (hasta una asignación de 1:10 o una dirección IP para 10 sesiones) a través de Soporte técnico de Azure.
Destino de uso Permanezca por debajo del 80% de utilización de subred para poder absorber los picos de actualización y escalado.
Intervalos IP admitidos RFC 1918 solo: 10.x, 172.16 hasta 172.31.xy 192.168.x. No hay rangos públicos ni CGNAT.
Capacidad del proyecto ~250 proyectos en tráfico bajo, tan solo unos 25 a gran escala. Controlada por la disponibilidad de IP.
Límites del agente hospedado 100 revisiones activas y 1000 revisiones totales por agente. ~200 agentes alojados por instancia.
Consumo de IP Las revisiones del agente hospedado consumen direcciones IP. Las revisiones rápidas de los agentes de solicitudes no lo hacen.
Conectividad saliente Los agentes hospedados usan una NIC dedicada. Todas las llamadas de la herramienta se enrutan a través del proxy de datos de un solo inquilino.
Alojado en comparación con la solicitud Alojado: CPU y memoria personalizadas, su ACR, NIC dedicada. Solicitud: escalado totalmente administrado.
Emparejamiento de VNet Las redes virtuales emparejadas deben tener rangos IP que no se superpongan. Use la red virtual administrada si existe superposición.
Supervisión No hay supervisión directa de IP en el portal. Observe si se producen errores 500 de proxy de datos.
Rendimiento No hay degradación al escalar cualquier tipo de agente, con un dimensionamiento de subred adecuado.

Contenido relacionado

  • Last updated on