O tráfego corporativo não é só aplicações HTTP. DNS, SIP, RADIUS, NTP, serviços TCP puros, protocolos de tunelamento e fluxos de streaming de alto volume se comportam de forma diferente. Nesses serviços, baixa latência, baixo consumo de CPU, decisão rápida e caminho de retorno correto são mais críticos do que o processamento de conteúdo.
Quando o balanceamento L4 e L7 é gerenciado como produtos separados, consoles separados ou camadas de licença separadas, a operação fica complexa. Uma equipe acaba tendo de gerenciar um componente de rede à parte para DNS e serviços UDP, um ADC à parte para aplicações web e uma camada à parte para segurança. No momento do problema, até a pergunta de qual tráfego passou por qual produto faz perder tempo.
O tráfego UDP exige atenção especial. Como o estado de conexão não é tão evidente quanto no TCP, a persistência, o comportamento do IP de origem, o efeito do NAT e o caminho de resposta do serviço corporativo precisam ser bem projetados. Em protocolos como o SIP, a sessão precisa permanecer no mesmo serviço, enquanto em serviços como DNS e NTP o que se destaca é a menor latência possível.
Modos como direct return e IP tunnel trazem grande vantagem quando configurados corretamente; mas, se os requisitos de rede não forem bem entendidos, geram problema. No modo direct routing, o VIP loopback alias, o comportamento de ARP e os ajustes de caminho de retorno precisam estar corretos nos serviços corporativos. Caso contrário, em vez de ganho de desempenho surge um problema de acessibilidade.
Os modos L4 do TR7 reúnem a distribuição de tráfego de baixa latência em nível de kernel, a escolha de modo adequada a diferentes topologias de rede e a operação mista L4+L7 sob um único modelo de gestão do ADC.
TR7 processa o tráfego L4 em nível de kernel enquanto oferece a gestão de modo, algoritmo, verificação de saúde e serviços mistos de forma centralizada.
TR7 aproveita a infraestrutura LVS/IPVS do Linux para o balanceamento de carga L4. Essa abordagem reduz o custo de processamento em user space e permite decisões rápidas no tráfego TCP e UDP.
Para cada pool de serviço L4, configuram-se protocolo, algoritmo, lista de serviços corporativos, peso, limite de conexão e verificação de saúde. A camada de orquestração L4 do TR7 converte essa configuração em comportamento executável de balanceamento L4.
Os modos NAT, SNAT, direct routing, IP tunnel e encaminhamento de protocolo genérico atendem a necessidades diferentes. O operador escolhe o modo adequado conforme o caminho de retorno do tráfego, a preservação do IP de origem e a localização do serviço corporativo.
No mesmo TR7, serviços L7 baseados em HTTP/TCP e serviços L4 baseados em IPVS podem rodar lado a lado. Assim, num único VIP, portas diferentes podem ser direcionadas a motores de processamento diferentes.
Os Modos L4 do TR7 oferecem opções flexíveis de balanceamento para diferentes protocolos, topologias de rede e comportamentos de serviço.
TR7 dá suporte aos modos NAT, SNAT, direct routing, IP tunnel e encaminhamento de protocolo genérico. No modo NAT, o tráfego de retorno passa pelo balanceador de carga. No modo direct routing, o caminho de retorno flui direto do serviço corporativo ao cliente. O modo IP tunnel pode ser usado em cenários que exigem localização remota ou travessia por uma rede diferente.
O pool de serviço L4 pode ser definido com protocolo TCP ou UDP. Serviços UDP como DNS, SIP, RADIUS e NTP podem ser balanceados sem serem forçados pelo pipeline de processamento L7. Já os serviços TCP podem ser usados para distribuição de baixa latência por porta. Cada pool funciona de forma simples e previsível com a lógica de um único protocolo.
TR7 dá suporte aos algoritmos round robin, weighted round robin, least connection, weighted least connection, source hash e destination hash. Os algoritmos ponderados podem ser usados para enviar mais tráfego a serviços corporativos mais robustos. Os algoritmos baseados em hash facilitam que a mesma origem ou destino seja direcionado ao mesmo serviço. Esses algoritmos rodam nos pools L4 de forma independente dos algoritmos L7.
Para persistência baseada em IP de origem, pode-se definir um valor de timeout. A abordagem padrão garante que, por um período determinado, a mesma origem seja direcionada ao mesmo serviço corporativo. No tráfego SIP, pode-se usar o motor de persistência baseado em call-id. Essa estrutura ajuda a evitar a quebra de comportamentos de sessão baseados em UDP.
Os pools de serviço L4 podem ser gerenciados junto com a verificação de saúde. O mecanismo de verificação de saúde L4 pode tirar de distribuição os serviços corporativos indisponíveis. Por meio de verificação baseada em HTTP, pode-se monitorar a API de gestão ou um endpoint de saúde dedicado. Assim, as decisões L4 são tomadas não apenas pela definição de porta, mas pela disponibilidade real do serviço.
Para cada serviço corporativo pode-se definir um valor de weight, e nos algoritmos ponderados a proporção de tráfego é determinada por ele. Com o limite de conexão, pode-se restringir a sobrecarga de um único serviço corporativo. Esse recurso permite um uso mais equilibrado, no mesmo pool, de serviços com capacidades diferentes. A equipe de operação gerencia de forma mais controlada os processos de adição de serviço e aumento de capacidade.
O mecanismo de failover VRRP permite mover o VIP entre o par HA. Em caso de perda de um nó ADC, o VIP pode ser assumido pelo outro nó. Em serviços UDP, uma curta perda de sessão é aceitável na maioria dos cenários, enquanto em serviços TCP o comportamento de failover deve ser avaliado conforme a estrutura da aplicação e da sessão. Esse modelo permite vincular os serviços L4 à arquitetura de alta disponibilidade.
Por meio das estatísticas IPVS, podem ser monitoradas as taxas de conexão, pacote e largura de banda. Os valores instantâneos de CPS, taxa de pacotes de entrada/saída e largura de banda de entrada/saída podem ser acompanhados. TR7 pode produzir essas estatísticas de forma compatível com a estrutura de monitoramento da plataforma. A equipe de operação consegue ver como os pools L4 realmente carregam o tráfego.
O modo de protocolo genérico pode ser usado em cenários de encaminhamento L3 genérico para protocolos diferentes de TCP e UDP. Em tipos de tráfego como ESP, GRE ou ICMP, o modelo L4 clássico baseado em porta pode não ser suficiente. Nesse modo, as estatísticas de conexão detalhadas são limitadas; a visibilidade é dada por contadores básicos de bytes. Constitui uma opção de encaminhamento prática para travessias de rede especiais.
Com o ajuste de namespace L4, o pool de serviço L4 pode rodar no contexto de um network namespace separado. Essa estrutura é importante para organizações que querem distinguir entre diferentes tenants ou zonas de rede. No mesmo appliance, múltiplos contextos de rede podem ser gerenciados de forma mais controlada. O isolamento aumenta a segurança operacional em projetos de deployment misto.
Para que os modos L4 funcionem corretamente, o rastreamento de conexão, o comportamento de failover, os requisitos de direct routing, os limites das estatísticas e a gestão de serviços precisam ser claramente planejados.
O balanceamento de carga L4 baseado em IPVS é adequado para serviços que exigem baixa latência e alto throughput. No modo direct routing, como o tráfego de retorno ignora o balanceador de carga, a vantagem é especialmente sensível em serviços que produzem respostas de alto volume. A capacidade real depende da placa de rede, da CPU, da escolha de modo e da topologia do serviço corporativo.
Em serviços UDP e L4 intensivos, o tamanho da tabela conntrack do Linux torna-se crítico. Os valores padrão podem não ser suficientes para tráfego em larga escala; precisam ser planejados conforme o volume de tráfego.
O VIP pode ser movido entre o par HA com VRRP. Em caso de perda de nó, o serviço continua no outro nó. Como os serviços UDP costumam ser stateless, recuperam-se com mais facilidade, enquanto nas sessões TCP o comportamento de interrupção deve ser avaliado conforme a tolerância da aplicação.
No modo direct routing, o serviço corporativo precisa reconhecer o VIP como loopback alias. Para o comportamento de ARP, é importante configurar corretamente os parâmetros arp_ignore e arp_announce. Se esses requisitos não forem atendidos, em vez da vantagem do caminho de retorno pode surgir um problema de acesso.
No modo de encaminhamento de protocolo genérico, os detalhes por conexão são limitados. Esse modo atende mais à necessidade de encaminhamento L3 especial e é monitorado com contadores básicos de bytes. Em serviços que exigem análise profunda de conexão, os modos TCP ou UDP podem ser mais adequados.
As estatísticas dos pools L4 podem ser coletadas e tornadas compatíveis com o formato geral de monitoramento da plataforma. Os valores de conexão, pacote e largura de banda podem ser gravados em sistemas de registro histórico. Isso facilita monitorar os serviços L4 no mesmo painel de operação dos serviços L7.
No tráfego SIP UDP, o uso de NAT pode afetar o comportamento do IP de origem e do caminho de retorno. Se o serviço corporativo quiser produzir resposta direta ao cliente, a escolha de modo deve ser feita com cuidado. As opções de persistência SIP e direct routing podem proporcionar um projeto mais adequado nesse tipo de cenário.
Para cada pool L4, o serviço de orquestração L4 associado pode ser monitorado. O status do serviço, o tempo de atividade e a última mudança de estado são valiosos para a auditoria operacional. Essas informações apoiam mudanças de configuração L4 e análises de failover.
Uma telecom ou provedor de serviço pode balancear, em UDP 53, vários serviços corporativos de recursor DNS. Com a persistência desativada, garante-se uma distribuição DNS balanceada e de baixa latência.
A organização pode direcionar o tráfego UDP 1812 e 1813 ao mesmo serviço de autenticação para o mesmo cliente com o algoritmo source hash. Essa estrutura proporciona uma escolha de serviço consistente no fluxo de autenticação.
Num ambiente de telecom, o tráfego SIP em UDP 5060 pode ser balanceado com persistência baseada em call-id. Manter o mesmo fluxo de chamada no mesmo serviço corporativo ajuda a preservar o comportamento da sessão.
Num cenário de mídia ou CDN, o tráfego TCP 80/443 pode rodar no modo direct routing. Como o tráfego de retorno flui direto do serviço corporativo ao cliente, a carga de retorno sobre o balanceador de carga diminui.
Em serviços de infraestrutura, o tráfego UDP 123 de NTP pode ser distribuído de forma balanceada e de baixa latência aos serviços corporativos com round robin. Para esse tipo de tráfego, que não exige persistência, basta uma definição de pool simples.
No mesmo VIP, as portas 80 e 443 podem ser direcionadas ao motor de processamento L7 e a porta 53 ao motor L4 IPVS. Sob uma única licença e um único console, obtém-se otimização separada para diferentes tipos de tráfego misto.
Balanceamento de carga L4 baseado em modo e de baixa latência para serviços como DNS, SIP, RADIUS, NTP e streaming. Vamos percorrer uma configuração ao vivo com os seus próprios serviços.