Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Ao executar o Serviço Microsoft Foundry Agent com uma rede virtual (VNet) própria, você é responsável por dimensionar uma sub-rede delegada, planejar a alocação de IP e entender como o tráfego do agente flui pela plataforma. Este artigo explica a arquitetura de rede por trás de agentes hospedados e prompt, o modelo de alocação de IP e os sinais que indicam problemas de capacidade. Ele destina-se a arquitetos de nuvem e de rede que já escolheram trazer sua própria VNet para o Serviço do Foundry Agent. Para configurar a rede, consulte Configurar a rede privada para o Serviço do Foundry Agent.
Se você usar um agente de codificação como GitHub Copilot para planejar sua VNet, sub-rede e modelo de capacidade, o Microsoft Foundry Skill poderá ajudá-lo a raciocinar por meio da arquitetura e aplicar as diretrizes de rede do Foundry em seu próprio ambiente.
Visão geral da arquitetura de rede
O diagrama a seguir mostra as duas zonas envolvidas em qualquer solicitação do Serviço do Foundry Agent: a rede da plataforma Foundry gerenciada por Microsoft à esquerda e a VNet do cliente à direita.
A rede da plataforma hospeda o endpoint Foundry, a camada de host da Micro VM que executa agentes hospedados, o Serviço de Ferramentas e a camada de host do Data Proxy. A VNet do cliente contém uma sub-rede delegada (em que as Micro VMs e o Data Proxy consomem IPs) e uma sub-rede de endpoint privado que se conecta ao Armazenamento, Bancos de Dados e Key Vault.
Dois fluxos de solicitação atravessam essa arquitetura:
-
Agente hospedado: cliente para ponto de extremidade do Foundry para Micro VM (
/invoke) para Serviço de Ferramentas para Proxy de Dados para recursos do cliente por meio de pontos de extremidade privados. - Agente de prompt: cliente para o ponto de extremidade do Foundry para o Serviço de Ferramentas para Proxy de Dados para recursos do cliente por meio de pontos de extremidade privados. Não há nenhuma Micro VM neste caminho.
Principais conceitos
| Termo | O que significa |
|---|---|
| Instância do Foundry | Seu recurso Microsoft Foundry. O contêiner de nível superior que contém seus projetos, agentes e configuração de rede. |
| Agente hospedado | Um agente que você cria e implanta usando sua própria imagem de contêiner por meio de Registro de Contêiner do Azure. Você controla a CPU, a memória e o código. É executado no Aplicativos de Contêiner do Azure. |
| Agente de prompt | Um agente em que a computação e o dimensionamento são totalmente gerenciados por Microsoft. Você define o comportamento por meio da configuração. Nenhuma imagem de contêiner ou gerenciamento de infraestrutura é necessário. |
| Proxy de dados de locatário único | Um componente de rede gerenciado pela plataforma dedicado ao projeto Foundry que gerencia a conectividade de saída para seus agentes. Cada projeto obtém sua própria instância de proxy de dados isolada. Todas as chamadas de ferramenta roteiam por meio do proxy de dados. |
| Servidor de ferramentas | Um serviço de back-end registrado no nível do projeto que seus agentes podem chamar para executar ações, como consultar um banco de dados ou invocar uma API externa. Em configurações do modo Traga sua própria VNet, o tráfego do servidor de ferramentas é roteado por meio do proxy de dados de locatário único. |
| Sub-rede (delegada) | A sub-rede na sua VNet que você delega ao Foundry Agent Service. Toda a infraestrutura do agente (proxies de dados e Micro VMs) é implantada nessa sub-rede e consome IPs dela. |
| Micro VM | A máquina virtual leve que executa um agente hospedado. |
| Versão | Uma alteração que afeta a forma como o agente é executado, como um novo código, uma nova imagem de contêiner ou uma atualização de configuração. Somente alterações que afetam o runtime criam uma nova versão. |
| Revisão | A unidade de implantação para seu agente. Uma revisão pode ser com versão (vinculada a uma alteração de tempo de execução) ou sem versão (alterações somente de metadados, como tags ou configurações de dimensionamento). |
Como o tráfego flui
Cada solicitação do Serviço de Agente do Foundry entra no ponto de extremidade do Foundry e sai para os recursos do cliente por meio de pontos de extremidade privados. O tipo de agente determina o que acontece no meio.
Entrada para o ponto de extremidade do Foundry
Os clientes enviam solicitações HTTPS para o endpoint do Foundry (por exemplo, <your-resource>.services.ai.azure.com). O gateway de API da plataforma autentica a solicitação e a roteia com base no tipo de agente de destino.
Caminho do agente hospedado
Para um agente hospedado, a plataforma encaminha a solicitação para uma Micro VM em sua sub-rede delegada pelo /invoke protocolo. A Micro VM tem duas interfaces de rede.
| Tipo de tráfego | Rota |
|---|---|
| Tráfego de saída do próprio agente | Direto, por meio da NIC dedicada da Micro VM na sub-rede delegada. |
| Chamadas do servidor de ferramentas | Por meio do proxy de dados de locatário único, independentemente do tipo de agente. |
Embora a Micro VM tenha sua própria NIC, qualquer invocação de ferramenta é roteada por meio do proxy de dados.
Caminho do agente de prompt
Para um agente de prompt, o agente é executado na computação gerenciada por Microsoft. O ponto de extremidade do Foundry encaminha a solicitação diretamente para o Serviço de Ferramentas, que chama o proxy de dados de locatário único. Os IPs são alocados no nível do projeto, portanto, todos os agentes de prompt em um projeto compartilham a mesma infraestrutura de proxy de dados.
Saída para recursos do cliente
O tráfego de saída do proxy de dados alcança suas contas de armazenamento, bancos de dados e Key Vault por meio de pontos de extremidade privados na sub-rede privada de pontos de extremidade. Configure as zonas correspondentes de DNS privado (por exemplo, privatelink.blob.core.windows.net, privatelink.database.windows.net e privatelink.vaultcore.azure.net) para que a resolução de nomes permaneça restrita à VNet.
Dimensionamento de sub-rede e alocação de IP
A configuração da sub-rede se aplica no nível da conta do Foundry. Todos os projetos na conta compartilham a mesma configuração de sub-rede, e os agentes hospedados e de prompt compartilham a mesma sub-rede delegada. O tamanho recomendado deve abranger o uso combinado de IP de agentes em todos os projetos, atualizações de plataforma e eventos de dimensionamento.
Tamanho recomendado da sub-rede
Use um intervalo CIDR /24 para workloads de produção. Uma sub-rede /27 pode funcionar para implantações menores, mas deixa muito pouca margem de manobra. Atualizações de plataforma, distribuições e eventos de dimensionamento precisam de IPs adicionais temporários, e uma pequena sub-rede pode se esgotar durante essas operações.
Intervalos de IP com suporte
Sua sub-rede deve usar somente intervalos IPv4 privados RFC 1918
10.0.0.0/8-
172.16.0.0/12(abrange172.16.x.xaté172.31.x.x) 192.168.0.0/16
Intervalos de IP públicos e intervalos CGNAT (por exemplo, 100.64.0.0/10) não têm suporte e causam falhas de roteamento.
Como os IPs são consumidos
Os IPs são reservados a uma taxa aproximada de 1 IP por 10 pods. Cada projeto do Foundry recebe um proxy de dados que começa em 1 pod (1 réplica) e escala horizontalmente com o tráfego.
| Cenário | Exemplo | Impacto do IP |
|---|---|---|
| Tráfego baixo | 10 projetos, cada um com 1 réplica | ~1 IP compartilhado em 10 pods |
| Tráfego alto | 10 projetos, cada um escalado para 10 réplicas | 100 pods, aproximadamente 10 IPs |
A capacidade do projeto é dinâmica porque mais tráfego por projeto consome mais IPs.
Tamanho da sub-rede e sessões simultâneas
O número de sessões de agente simultâneas disponíveis por assinatura varia de acordo com a região. Por padrão, sessões simultâneas e IPs de sub-rede utilizáveis correspondem na proporção de 1:1, respeitando o limite da sua região.
| Sub-rede | Total de IPs | IPs utilizáveis | Sessões simultâneas aproximadas |
|---|---|---|---|
| /27 | 32 | ~27 | ~17 |
| /26 | 64 | ~59 | ~50 (máximo suportado) |
Com o mapeamento padrão 1:1, use uma sub-rede /26 ou maior para dar suporte a 50 sessões simultâneas.
Para dar suporte a sessões mais simultâneas com a mesma sub-rede, crie uma solicitação Suporte do Azure. Na solicitação, especifique a assinatura, a região e o número esperado de sessões simultâneas. Com base em seus requisitos e capacidade regional, o suporte pode aumentar o mapeamento para 10 sessões simultâneas por IP utilizável (1:10).
Capacidade do projeto
Uma instância do Foundry dá suporte a aproximadamente 250 projetos em tráfego baixo. Em tráfego pesado, quando os agentes escalam para muitas réplicas, o limite efetivo pode cair para apenas ~25 projetos. Quando os IPs estão esgotados, o provisionamento de novo projeto falha.
Importante
Não planeje operar com capacidade máxima teórica. Procure manter a utilização da sub-rede em no máximo 80% para absorver os picos decorrentes de atualizações e ampliações.
Comportamento durante a manutenção da plataforma
As atualizações de plataforma executam uma infraestrutura antiga e nova em paralelo, o que aumenta temporariamente o consumo de IP. Uma sub-rede /24 fornece buffer suficiente para lidar com esses picos temporários junto com suas cargas de trabalho normais. As atualizações de infraestrutura são totalmente gerenciadas por Microsoft, incluindo a programação.
Comportamento de rede de agentes hospedados
Os agentes hospedados são executados em Aplicativos de Contêiner do Azure e fornecem controle sobre a CPU e a configuração de memória. Você os implanta por meio de sua própria Registro de Contêiner do Azure.
Revisões e uso de IP
Quando você implanta uma atualização (nova imagem, configuração ou código), a plataforma cria uma nova revisão. Durante a distribuição, as revisões antigas e novas são executadas em paralelo à medida que o tráfego muda para a nova versão e ambas consomem IPs da sua sub-rede.
Limites de revisão por agente hospedado:
- 100 revisões ativas por agente.
- 1.000 revisões totais por nome de agente. As revisões inativas mais antigas são limpas automaticamente quando o limite ativo é atingido.
- Aproximadamente 200 agentes hospedados por instância do Foundry.
O limite de 200 agentes hospedados é separado do limite de ~250 projetos, que se aplica a toda a instância em todos os tipos de agentes.
Conectividade externa
Cada agente hospedado é executado em uma Micro VM anexada à sua sub-rede delegada com uma interface de rede dedicada e usa seu próprio IP para comunicação de saída. As chamadas de ferramenta são roteadas por meio do proxy de dados de locatário único. Para implantações de agentes de código-fonte, a etapa de provisionamento também requer acesso de saída para endpoints específicos. Consulte os requisitos de firewall para redes virtuais privadas.
Desempenho e dimensionamento
O dimensionamento de agentes hospedados não introduz latência ou degradação de desempenho. O único cenário em que o desempenho é afetado é quando o esgotamento de IP impede que a plataforma seja dimensionada, o que é evitável com o dimensionamento adequado da sub-rede. Os agentes hospedados dão suporte a configurações personalizadas de CPU e memória. Você seleciona entre os pares de CPU e memória disponíveis ao criar uma versão do agente.
Comportamento de rede dos agentes de prompt
Os agentes de prompt também são executados em Aplicativos de Contêiner do Azure, mas a computação e o dimensionamento são totalmente gerenciados por Microsoft. Você não configura a CPU ou a memória.
Revisões e uso de IP
Ao contrário dos agentes hospedados, as revisões do agente de prompt não consomem IPs. O proxy de dados é executado no modo de revisão única, portanto, revisões inativas não afetam a disponibilidade de IP.
Conectividade externa
Os agentes de prompt usam o proxy de dados de locatário único para toda a conectividade de saída. Os IPs são alocados no nível do projeto, portanto, todos os agentes de prompt em um projeto compartilham a mesma infraestrutura de proxy de dados.
Limites e desempenho
Não há um limite estrito para o número de agentes de prompt que você pode implantar por instância do Foundry. Como a computação e o dimensionamento são totalmente gerenciados, não há problemas de latência ou desempenho esperados vinculados ao número de agentes de prompt implantados.
Emparelhamento de VNet e sobreposição de IP
Intervalos de IP sobrepostos causam falhas de roteamento, portanto, todas as VNets emparelhadas devem usar intervalos de IP exclusivos e não sobrepostos. Essa regra também se aplica a configurações de emparelhamento bidirecional. Há suporte apenas para intervalos IPv4 privados RFC 1918. Endereços CGNAT (por exemplo, 100.x.x.x) não são.
Se você não puder evitar a sobreposição de IP, use a rede virtual gerenciada em vez do modo Traga sua própria VNet. A VNet gerenciada automatiza a configuração de rede e elimina preocupações de sobreposição de IP.
Monitorar o uso de IP e detectar esgotamento
O portal Azure atualmente não expõe a utilização de IP para sub-redes delegadas, portanto, você não pode monitorá-lo diretamente. Os principais indicadores de esgotamento de IP são erros HTTP 5xx do proxy de dados e, para agentes hospedados, falhas de criação de sessão (erros 4xx). Quando os IPs estão esgotados, o dimensionamento de proxy de dados e o novo provisionamento de projeto falham e os agentes hospedados não podem alocar uma Micro VM para novas sessões. Monitore a integridade do proxy de dados e o sucesso da criação da sessão do agente hospedado como principais indicadores de problemas de capacidade.
Considere implantar uma nova instância do Foundry com uma sub-rede nova quando observar:
- O proxy de dados está retornando erros 5xx.
- Falha na criação da sessão do agente hospedado com erros 4xx.
- Novas falhas de provisionamento de projeto.
Importante
A plataforma não alerta proativamente quando a capacidade de IP está baixando. Monitore os sinais listados anteriormente para evitar falhas inesperadas de provisionamento.
Referência rápida
| Tópico | Recomendação |
|---|---|
| Tamanho da sub-rede | Use /24 para produção. /27 é o mínimo, mas arriscado. Com o mapeamento padrão 1:1, você precisa de /26 para 50 sessões simultâneas. Solicite mais sessões (até um mapeamento de 1:10, ou um endereço IP para 10 sessões) por meio do suporte do Azure. |
| Destino de utilização | Mantenha a utilização da sub-rede abaixo de 80% para absorver picos de atualização e dimensionamento. |
| Intervalos de IP com suporte | SOMENTE RFC 1918: 10.x, 172.16 por meio de 172.31.x e 192.168.x. Sem intervalos públicos ou CGNAT. |
| Capacidade do projeto | Cerca de 250 projetos em tráfego baixo, apenas cerca de 25 em grande escala. Impulsionado pela disponibilidade de IP. |
| Limites do agente hospedado | 100 revisões ativas e 1.000 revisões totais por agente. Cerca de 200 agentes hospedados por instância. |
| Consumo de IP | As revisões do agente hospedado consomem IPs. As revisões de agentes de prompt não. |
| Conectividade externa | Os agentes hospedados usam uma NIC dedicada. Todas as chamadas de ferramenta são roteadas por meio do proxy de dados de locatário único. |
| Hospedado em comparação com o prompt | Hospedado: CPU e memória personalizadas, seu ACR, NIC dedicada. Prompt: dimensionamento totalmente gerenciado. |
| Emparelhamento de VNet | As VNets emparelhadas devem ter intervalos de IP não sobrepostos. Use uma Rede Virtual Gerenciada se houver sobreposição. |
| Monitoramento | Nenhum monitoramento de IP direto no portal. Observe os erros do proxy de dados 500. |
| Desempenho | Não há degradação na escala de qualquer um dos tipos de agente, com o dimensionamento adequado da sub-rede. |