Em projetos tradicionais de implantação de ADC, o maior custo geralmente não é o próprio produto — é reformatar a rede existente para se adequar ao produto. Alterar gateways padrão de backends, redesenhar planos de IP, reworkar comportamento de rotas ou abrir janelas de manutenção carregam riscos significativos em ambientes de produção.
Em ambientes com centenas ou milhares de backends, a abordagem de "mudar o gateway de cada servidor" não é viável. Alguns backends podem não ter nenhum gateway definido, outros podem depender de rotas estáticas, e outros ainda podem rodar em sistemas legados difíceis ou impossíveis de modificar. Nesses casos, inserir um ADC se torna um projeto completo de redesign de rede.
A fusão forçada de segmentos de rede é outro problema. O VIP deve ficar na DMZ, o backend deve permanecer na rede interna, as redes de tenant devem permanecer isoladas e o plano de gerenciamento deve ser mantido separado. Se o ADC não puder transportar tráfego entre esses domínios de forma controlada, a segmentação de segurança se desfaz ou as equipes de aplicação são forçadas a um trabalho desnecessário de migração de IP.
Um único modelo de reverse proxy também não atende a todas as necessidades. Algumas aplicações exigem que os backends vejam o IP real do cliente; alguns serviços L4 precisam que o tráfego de retorno contorne o ADC completamente; alguns cenários inline exigem inserir o ADC sem alterar IPs ou tocar em gateways. Um único modelo baseado em NAT não pode atender a essa gama de requisitos.
Os Modos de Topologia de Implantação do TR7 fornecem essa flexibilidade: permitem escolher o posicionamento de tráfego correto para cada serviço sem tocar em endereços IP de backends, gateways ou atribuições de Route Table.
O TR7 transforma a topologia de implantação em uma decisão arquitetural que pode ser adaptada ao tipo de serviço, posicionamento de rede e risco de migração.
No modelo clássico de reverse proxy, o cliente se conecta ao TR7 e o TR7 se conecta ao backend. Em um cenário de transparent bind, o fluxo de tráfego é preservado para que o backend veja o IP real do cliente como endereço de origem.
No modo NAT, tanto a tradução de destino quanto a de origem são gerenciadas juntas. No modo SNAT, apenas o lado da origem é ajustado. No modo DR, o tráfego de retorno vai diretamente ao cliente, fornecendo um caminho mais eficiente para cargas de trabalho L4 de alto volume.
A Route Table que hospeda o VIP e a Route Table que hospeda o backend podem ser diferentes. O TR7 transporta tráfego entre os dois domínios de rede de forma controlada, conectando segmentos de DMZ, internos, de tenant e de gerenciamento sem achatá-los.
O TR7 pode assumir a propriedade do tráfego destinado a IPs de backend específicos e operar inline. O endereço IP do backend, gateway e configuração de aplicação permanecem inalterados enquanto o ADC é inserido no caminho.
Os Modos de Topologia de Implantação cobrem posicionamentos de rede que vão desde configuração rápida de interface única até encaminhamento L4 de alto throughput.
No modo one-arm, o tráfego de cliente e backend pode ser tratado no mesmo lado da rede. O TR7 recebe tráfego de serviço por uma única interface e o encaminha para o backend relevante usando regras de roteamento. Esse modelo é adequado para implantação rápida de ADC com mudanças mínimas de rede. É um ponto de partida prático para implantações piloto, transições temporárias ou cenários de rollout de baixo risco.
No modo two-arm, o TR7 é posicionado entre dois segmentos de rede distintos. Um lado enfrenta a rede do cliente ou DMZ; o outro enfrenta a rede do backend. Isso torna o ADC não apenas um encaminhador de tráfego, mas um ponto de trânsito que aplica políticas na fronteira da rede. É adequado para arquiteturas empresariais que exigem segurança e segmentação.
No modo reverse proxy, o cliente se conecta ao VIP ou vService no TR7, e o TR7 abre uma conexão separada para o backend. Terminação TLS, WAAP, manipulação de headers, segurança de cookies, regras conscientes de conteúdo e integração com AAM são todos totalmente aplicáveis nesse modo. Esta é a topologia de entrega de aplicações mais comum para tráfego HTTP e API. Os backends nunca ficam expostos diretamente à internet ou redes externas.
Em um cenário transparent L7, o IP de origem visto pelo backend é o endereço real do cliente, e não o endereço do ADC. Esse modo é valioso para aplicações que não podem depender apenas do encaminhamento de IP de cliente baseado em header. Logs, controle de acesso e decisões baseadas em IP dentro da aplicação funcionam de forma mais natural. O caminho de retorno da rede deve ser planejado adequadamente.
O modo Bridge permite que o TR7 fique no caminho de tráfego como uma bridge de Camada 2. Nesse cenário, a necessidade de renumeração adicional de IPs ou amplas mudanças de roteamento é reduzida. O endereçamento existente pode ser preservado ao entrar no caminho de tráfego em VMs, containers ou segmentos. O modo Bridge é útil em ambientes onde as mudanças de rede devem ser mantidas ao mínimo.
No modo transparent gateway, o TR7 é posicionado no ponto de trânsito da rede do backend. O IP de origem é preservado e o NAT não é necessário. Esse modo é valioso em cenários onde os backends precisam ver o IP do cliente naturalmente. As mudanças de rota padrão devem ser planejadas com cuidado e o caminho de retorno deve ser controlado explicitamente.
O TR7 pode assumir a propriedade do tráfego para IPs de backend designados e operar inline. Esse modo é particularmente valioso quando o endereço IP, gateway padrão ou configurações de rota de um backend não podem ser alterados. Mesmo quando o backend não tem gateway configurado, o TR7 pode se posicionar como o ponto de controle no caminho de tráfego relevante. Em ambientes grandes, a inserção inline controlada substitui a necessidade de modificar centenas de backends individualmente.
O TR7 pode escutar em um VIP em uma Route Table e encaminhar tráfego para um backend em uma Route Table diferente. Isso permite que DMZ, rede interna, tenant, gerenciamento e zonas de serviço distintas sejam conectados entre si de forma controlada sem serem movidos para o mesmo plano de rede. Os operadores não precisam renumerar backends ou achatar redes. O TR7 se torna um ponto de trânsito controlado entre Route Tables onde a política de segurança pode ser aplicada.
No modo L4 NAT, tradução de destino e origem são usadas juntas para garantir o caminho de retorno pelo TR7. No modo SNAT, apenas o lado da origem é ajustado, e o design de caminho de retorno existente do backend é respeitado. Esses dois modos permitem que o tráfego L4 seja transportado de forma que se ajuste à topologia de rede. Comportamento separado pode ser selecionado para UDP, TCP ou faixas de porta específicas.
No modo DR, o tráfego de requisição é encaminhado para o backend pelo TR7, enquanto o tráfego de resposta retorna diretamente ao cliente. Esse modelo é vantajoso para streaming de alto volume, jogos, DNS ou serviços L4 sensíveis à latência. Como o ADC não transporta tráfego de retorno, o caminho de dados se torna mais eficiente. O comportamento do backend e da rede de retorno deve ser preparado corretamente para cenários DR.
A persistência L4 ajuda a garantir que o tráfego de um cliente específico permaneça no mesmo destino de backend. CONNMARK, registros recentes e uma janela de persistência configurável mantêm a continuidade do fluxo. A persistência SIP fornece comportamento especializado para protocolos sensíveis a sessão, como tráfego SIP. Isso fornece consistência de sessão no nível L4, além da distribuição básica de carga.
As permissões de ingresso necessárias para definições de L4 e vService podem ser geradas automaticamente. Regras de aceitação apropriadas são criadas para cada IP de frontend, porta e protocolo, reduzindo erros manuais de firewall. A geração automática de regras é especialmente importante em cenários inline e L4. O operador seleciona a topologia; o TR7 gera consistentemente as permissões básicas para o caminho de tráfego relevante.
Os modos de topologia são operados junto com padrões L4, comportamento do processo inline, Route Tables do TR7, papel do cluster e visibilidade de erros.
Algoritmo round-robin, modo NAT e protocolo UDP estão disponíveis como valores de início padrão para um novo pool L4. Os operadores podem mudar para TCP, UDP, qualquer protocolo, faixa de porta ou um algoritmo L4 diferente com base nos requisitos de serviço. Os padrões são para inicialização rápida; o comportamento de produção deve ser revisado explicitamente.
Algoritmos como round-robin e round-robin ponderado podem ser usados para distribuição L4. O modelo ponderado fornece distribuição de tráfego mais equilibrada entre backends com diferentes capacidades. A seleção de algoritmo deve ser planejada em conjunto com tipo de serviço, capacidade e comportamento de sessão.
O modo IP-takeover inline opera com base na interface relevante, IP do backend e informações de gateway. Se um gateway não for especificado explicitamente, o caminho apropriado pode ser derivado das informações de rede existentes. Se o processo parar inesperadamente, a reinicialização automática pode ser aplicada.
No modo inline, condições como noBackendIp, ipUsed, noZoneId, noMatchingIp, noSpoofingIp, inactiveClusterDevice e inactiveClusterIp podem ser apresentadas como razões de erro explícitas. Isso informa à equipe de operações precisamente por que algo não está funcionando, em vez de simplesmente que não está funcionando. A visibilidade de erros é crítica para operar topologias inline com segurança.
Em um ambiente de cluster, o processo de takeover inline deve rodar apenas no dispositivo que detém o papel ativo. Quando o dispositivo ativo muda, a propriedade do tráfego inline se move para o nó relevante. Esse modelo ajuda a evitar que dois nós reivindiquem simultaneamente a propriedade do mesmo IP.
O modo transparent inline reduz a dependência da configuração de gateway padrão do backend. Se o backend não tem gateway ou o gateway não pode ser alterado, o TR7 pode assumir o caminho de tráfego relevante usando o método IP-takeover. Essa capacidade permite implantação controlada de ADC sem abrir janelas de manutenção ou modificar backends.
A Route Table do TR7 na qual o VIP escuta e a Route Table do TR7 onde o backend reside podem ser diferentes. O TR7 transporta tráfego entre esses dois domínios de rede, reduzindo a necessidade de mudanças de topologia. Esse comportamento é particularmente valioso para trânsito controlado de DMZ para rede interna, de rede de tenant para rede de serviço compartilhado, ou entre domínios de rede antigos e novos durante migração.
Em grandes organizações, alterar o IP, rota ou gateway de centenas de backends é de alto risco. O modo IP-takeover inline permite que o TR7 ADC seja inserido no caminho de tráfego enquanto o endereçamento existente é preservado.
Alguns backends legados ou isolados podem não ter gateway padrão configurado. No modo transparent inline, o TR7 pode assumir o tráfego relevante sem tocar na configuração de gateway do backend.
As organizações podem escutar VIPs em uma Route Table de DMZ enquanto mantêm backends em uma Route Table interna. O TR7 fornece trânsito de tráfego controlado entre os dois domínios sem mesclar redes ou renumerar IPs de serviço.
Equipes de jogos ou streaming podem usar o modo DR para enviar tráfego de resposta diretamente ao cliente. Enquanto o TR7 toma a decisão de encaminhamento, a carga no caminho de dados de retorno é reduzida e cenários de alto throughput se tornam mais eficientes.
Do one-arm ao transparent inline, L4 DR ao encaminhamento cross-Route-Table — vamos percorrer a topologia certa em uma configuração ao vivo.