Balanceamento de carga (Load Balance) em detalhe: também chamado de F5, com casos reais

Quem trabalha com operação e segurança quase sempre esbarra no termo balanceamento de carga. E ao falar nele, o primeiro equipamento que vem à cabeça de muita gente é o “F5”. O curioso é que F5, na verdade, é nome de empresa (F5 Networks), mas seus produtos ficaram tão famosos que o nome virou aos poucos sinônimo de balanceador — assim como “buscar no Baidu” virou sinônimo de pesquisa.

Aqui vamos esgotar o assunto: o que é o F5 de fato, onde camada 4 e camada 7 se diferenciam e como configurar em cenários reais.

1. O que o balanceamento de carga realmente resolve

O balanceamento de carga (Load Balance) consiste, na essência, em distribuir tarefas de trabalho entre múltiplas unidades operacionais — por exemplo, servidores web, servidores FTP e servidores de aplicações críticas da empresa — para que trabalhem juntos na mesma função.

Do ponto de vista técnico, ele expõe externamente umendereço de servidor virtual. Quando o usuário conecta, ele usa NAT bidirecional para direcionar a conexão ao servidor real mais adequado. Para o usuário, a entrada é sempre a mesma; nos bastidores, um grupo de máquinas sustenta tudo.

Ele resolve três preocupações:medo de cair(ponto único de falha), medo de não aguentar(gargalo de desempenho), medo de não conseguir escalar(impossibilidade de escalar horizontalmente).

2. Camada 4 vs camada 7: a confusão mais comum

A diferença cabe em uma frase:interpretar ou não o protocolo da camada de aplicação. Esse detalhe define diretamente os limites de capacidade e o desempenho.

Balanceamento de carga na camada 4 (transporte)

• Camada de atuação: 4ª camada do modelo OSI, protocolos TCP/UDP
• Critério de encaminhamento: IP de origem, IP de destino e porta — sem tocar nos dados da aplicação
• Capacidades principais: encaminhamento de portas, reuso de conexões TCP, health check na camada 4 (handshake TCP), proteção básica contra DDoS
• Desempenho: encaminhamento extremamente eficiente, próximo ao limite do hardware, latência em microssegundos
• Cenários típicos: bancos de dados (MySQL/Redis), serviços TCP (servidores de jogos, serviços Netty), balanceamento de enlaces entre datacenters
• Produtos representativos: LVS, F5 (modo camada 4), HAProxy (modo camada 4), Nginx (módulo stream)

Balanceamento de carga na camada 7 (aplicação)

• Camada de atuação: 7ª camada do modelo OSI, protocolos de aplicação como HTTP/HTTPS, DNS, FTP
• Critério de encaminhamento: URL, Cookie, cabeçalhos HTTP, parâmetros de requisição, conteúdo JSON
• Capacidades principais: roteamento por conteúdo, offload de SSL, cache, limitação de taxa e circuit breaking, integração com WAF, persistência de sessão, deploy canário
• Desempenho: funções ricas, mas precisa interpretar o protocolo da aplicação, com latência um pouco maior (milissegundos), compensada pela expansão em cluster
• Cenários típicos: aplicações web, APIs de microsserviços, serviços HTTPS, deploy canário, API gateway
• Produtos representativos: Nginx, HAProxy (modo camada 7), F5 (módulo camada 7), Kong, Spring Cloud Gateway

Regra de bolso: na camada 4 basta olhar a “placa” (IP e porta) para encaminhar; na camada 7 é preciso “abrir o pacote” (ver o conteúdo) antes de decidir o destino. Para desempenho, escolha a camada 4; para recursos avançados, a camada 7.

3. O que faz o F5 BIG-IP ser tão forte

O produto principal da F5, o BIG-IP LTM, tem o nome oficial deGerenciador de Tráfego Local, cobrindo balanceamento das camadas 4 a 7. Ele não é só um encaminhador; a lista de funções é bastante longa: comutação de aplicações, comutação de sessões, monitoramento de estado, NAT inteligente, persistência universal, tratamento de erros de resposta, gateway IPv6, roteamento avançado, aceleração SSL, compressão HTTP inteligente, otimização TCP, buffering de conteúdo, criptografia de cookies, filtragem de ataques a aplicações, proteção contra DoS e SYN Flood, filtragem de pacotes por firewall…

Vamos destacar as mais úteis:

1. Balanceamento e redundância multilink

Negócios críticos costumam contratar múltiplos links de ISPs para garantir qualidade e eliminar pontos únicos de falha. Há duas direções:

• Tráfego OUTBOUND(rede interna acessando a internet): o BIG-IP LC distribui o tráfego de forma inteligente entre as interfaces de Internet e aplica NAT de endereço de origem
• Tráfego INBOUND(internet acessando a rede interna): vincula os endereços públicos dos dois ISPs, resolve as requisições DNS de ambas as operadoras e responde de forma inteligente conforme a saúde dos servidores e o tempo de RTT

2. Balanceamento de servidores

O serviço é exposto via VIP (IP virtual, composto por endereço IP e porta TCP/UDP), com health checks contínuos de L4 a L7 nos servidores-alvo. Ao detectar um servidor com falha, ele é removido do grupo de balanceamento. Com os iRules, ainda é possível abrir pacotes TCP/UDP e aplicar regras por característica de conteúdo — por exemplo, direcionar o tráfego a servidores diferentes conforme a URL.

3. Alta disponibilidade do sistema

Este é o ponto mais gabado da F5. No modo de redundância com dois equipamentos, acomutação em milissegundos(em até 200ms no melhor caso) sustenta a promessa de 99,999% de disponibilidade. O princípio: enquanto todas as sessões passam pelo equipamento Active, as informações de sessão são sincronizadas ao Backup pelo cabo de sincronização de dados — por isso a sessão do usuário não cai na troca. O chip watchdog de cada aparelho monitora o sinal elétrico do outro pela linha de heartbeat; se o Active cai, o Backup é avisado na hora e assume o Shared IP e os VIPs.

4. Segurança

O BIG-IP segue princípios de design de firewall,negando por padrão. Ele derruba conexões ociosas para evitar DoS, executa rastreamento de rota de origem contra spoofing de IP e recusa SYN sem ACK contra ataques SYN. O recurso Dynamic Reaping remove com alta eficiência as conexões ociosas durante ataques DoS, ea taxa de corte de conexões acelera conforme o volume do ataque cresce — um detalhe bem agressivo. Já a tecnologia Delay Binding oferece aos servidores de backend proteção completa contra SYN Flood.

5. Aceleração SSL

Cada BIG-IP traz um chip de aceleração SSL em hardware, com licença de 100 TPS incluída, sem custo adicional. Para escalar depois, basta fazer upgrade da licença.

4. F5 ou Nginx? Comparativo de escolha

Essa é a pergunta mais frequente no trabalho real. Os dois não competem entre si; na verdade, se complementam.

F5 BIG-IP (hardware)

• Forma de implantação: aparelho dedicado de hardware (com chips customizados)
• Desempenho: milhões de conexões TCP, latência de encaminhamento em microssegundos
• Funções: completo — camadas 4+7, offload SSL, proteção DDoS, WAF, VPN, balanceamento de links
• Confiabilidade: redundância de hardware (dupla ativa), 99,999% de disponibilidade
• Custo: alto (centenas de milhares a milhões), exige engenheiros especializados para manutenção
• Escalabilidade: depende de upgrades de hardware, pouca flexibilidade
• Operação: complexa, exige familiaridade com interface de configuração e CLI proprietárias

Nginx (software)

• Forma de implantação: software, rodando em servidores comuns ou máquinas na nuvem
• Desempenho: centenas de milhares de conexões TCP, latência em milissegundos, expansão por cluster
• Funções: leve e eficiente — camada 7 como núcleo, com suporte a camada 4, offload SSL, cache, limitação de taxa, proxy reverso
• Confiabilidade: exige configurar manualmente a dupla ativa (Keepalived), dependente da estabilidade do hardware dos servidores
• Custo: open source gratuito; o Nginx Plus pago também tem preço baixo
• Escalabilidade: suporta implantação em cluster e expansão elástica em ambientes de nuvem
• Operação: simples, arquivos de configuração legíveis; engenheiros de backend dominam rápido

Na encruzilhada da escolha, siga o mapa:

• Serviços TCP de alta concorrência (jogos, bolsa de valores) + disponibilidade máxima → F5 camada 4
• Entrada de negócio crítico + demanda de segurança (WAF/DDoS) → F5 camada 7
• API gateway de microsserviços + implantação em nuvem → Nginx camada 7
• Carga de banco de dados/Redis + melhor custo-benefício → Nginx camada 4
• Negócio de pequeno e médio porte + iteração rápida → Nginx (camada 4/7)
• Datacenter corporativo + multilink → F5 na entrada, Nginx no balanceamento dos serviços internos

A última combinação é muito comum nas grandes empresas — F5 guarda a porta da frente, Nginx cuida de dentro.

5. Caso prático: o quão intrincada é a configuração do F5

A reação de muita gente ao pegar um F5 pela primeira vez é:a lógica é totalmente diferente de um switch, não sei nem por onde começar. A lógica de configuração segue um sistema próprio.

Cenário: dois servidores web atendendo externamente, com IPs 192.168.192.10-20/24, exigindo balanceamento de carga pelo endereço externo 192.168.27.100, porta 80.

O balanceamento mais simples precisa de apenas três parâmetros, encadeados um no outro:

• Node (nó): a definição mais básica; cada servidor é um Node
• Pool (pool de recursos): conjunto de Nodes que recebem e processam tráfego, por exemplo um cluster de servidores web
• Virtual Server (servidor virtual): a entrada externa, associada ao Pool

Fluxo de dados: requisição do cliente → Virtual Server → Pool → Node.

Passos práticos (interface de gerenciamento do BIG-IP):

• Passo 1: ativar o equipamento. Ao receber o F5, ative-o primeiro; o assistente é simples, mas lembre-se:é preciso conexão com a internet, de preferência antes de instalá-lo no rack — lição de quem já levou um tombo
• Passo 2: login. No navegador, abra https://IP-do-equipamento; usuário e senha padrão são admin
• Passo 3: criar VLANs. Network → VLANs, crie a VLAN e adicione as interfaces (selecione Untagged)
• Passo 4: configurar IPs. Networks → Self IPs, defina um endereço para cada VLAN
• Passo 5: configurar rotas. Networks → Routes, defina o gateway padrão ou rotas estáticas
• Passo 6: configurar o Pool. Local Traffic → Virtual Servers → Pools, defina nome, health check (como TCP), algoritmo de balanceamento (como observed-member, método de observação), IPs e portas dos servidores reais
• Passo 7: configurar o Virtual Server. Local Traffic → Virtual Servers, associe o Pool criado acima e escolha o método de distribuição (o RoundRobin é o mais comum)
• Passo 8: configurar o Monitor. Local Traffic → Monitors, verifique a saúde dos servidores e associe ao Pool
• Passo 9: configurar o Redundant, para redundância de dois equipamentos

6. Alguns parâmetros-chave do Virtual Server

O coração do F5 é o Virtual Server; ignorar alguns parâmetros gera problemas.

VS Type (tipo), três tipos comuns:

• Performance L4: encaminhamento puramente de camada 4; o TMM só distribui conexões, sem alterar parâmetros TCP, e a conexão cliente-servidor é 1:1. Taxa de encaminhamento alta, muito usado nas empresas. Para reduzir o impacto na aplicação,se puder escolher, priorize este
• Standard VS: as conexões TCP cliente-servidor são totalmente independentes. Use quando precisar de funções de camada 7 (persistência por Cookie, por Session ID, por Header, divisão de conexões longas por transação, proteção contra ataques SYN). Atenção a uma característica:sua porta fica sempre aberta externamente — mesmo com todos os Nodes de backend fora do ar, a porta 80 do VIP ainda responde a telnet; só a página não abre. Lembre disso ao diagnosticar falhas
• Forwarding IP: usado para conexões entre rede interna e externa; não tem Pool Member, e o encaminhamento depende das rotas locais. Por padrão o F5 não tem função de roteamento — é preciso criar um VS com tudo zerado para habilitá-la

Timeout precisa estar alinhado(essa é uma pegadinha de verdade). Se um TCP Profile estiver configurado no VS, conexões UDP não serão aceitas. E fique de olho no valor de Idle Timeout dentro do tcp —precisa combinar com o servidor. Se o F5 marca 150 segundos e o servidor IIS, 300, vai gerar um bocado de erros. Os dois lados precisam acertar os tempos entre si.

Address/Port Translation: por padrão, ambos habilitados. Habilite Address Translation quando o IP do VS diferir do IP real da máquina; e Port Translation quando a porta 8080 do VS corresponder à porta 80 do endereço real.

SNAT AutoMap: o endereço de origem do SNAT é o Self IP da VLAN por onde a requisição sai. Se houver vários Self IPs na mesma VLAN, eles são usados em rodízio.

7. Por que é obrigatório entender “persistência de sessão”

Este é o conceito mais ignorado — e o que mais causa incidentes — no balanceamento de carga.

Em sistemas como e-commerce e autenticação online, um cliente passa por várias interações até concluir uma transação. Essas interações sãofortemente interdependentes — ao processar a segunda etapa, o servidor muitas vezes precisa conhecer o resultado da primeira. Isso exige que todas essas interaçõessejam atendidas pelo mesmo servidor, sem serem espalhadas pelo balanceador entre máquinas diferentes.

É para isso que existe a persistência de sessão (Persistence). No F5, ela é implementada via Connectivity, com modos opcionais como:

• persistência por endereço de origem: vínculo pelo IP de origem do cliente
• persistência por Cookie: o F5 insere automaticamente o cookie de sessão; o mais usado na camada 7
• persistência por SSL Session ID: reutiliza a sessão SSL
• tabela de persistência de sessão: suporta vários tempos de expiração e regras de correspondência

E se configurar errado, o que acontece? O usuário adiciona itens ao carrinho, atualiza a página e tudo some — porque a requisição foi parar em outro servidor. Esse tipo de incidente em produção é extremamente trabalhoso de diagnosticar.

8. Alguns detalhes práticos inevitáveis

Por fim, alguns tropeços alheios já com veredito pronto:

• Escolha o nível certo para o health check: olhar só o handshake TCP não basta — o servidor pode responder na porta com a aplicação caída e ainda ser encaminhado; para checar a camada de aplicação, use um Monitor do tipo HTTP consultando endpoints como /actuator/health
• O firewall precisa virar “sanduíche”: um firewall sozinho raramente passa de 30% da taxa de linha em throughput; para melhorar, é preciso empilhar vários. Mas firewalls exigem que os dados entrem e saiam pelo mesmo caminho, senão as conexões são recusadas — a solução de balanceamento de firewalls do F5 resolve isso, mantendo a persistência transparente dos equipamentos
• Offload de SSL é o maior ganho de CPU: deixe o F5 cuidar do handshake HTTPS e da criptografia/descriptografia, e a aplicação Java de trás processa apenas HTTP — o ganho de desempenho é evidente
• Teste de carga antes de conectar à produção: a camada 4 é rápida, mas se você habilitar persistência de sessão num VS de camada 4, introduz estado — e as expectativas de desempenho precisam ser recalculadas
• Monitore três indicadores: estado dos pools, throughput dos servidores virtuais, saúde dos nodes
• Comandos de diagnóstico: tmsh show ltm pool <pool-name> para ver o estado do pool, tmsh show ltm virtual <vs-name> para ver o estado do servidor virtual

Para terminar

O balanceador de carga parece um mero “equipamento de encaminhamento”, mas ocupa a posição mais crítica de toda a arquitetura — todo o tráfego passa por suas mãos. Bem configurado, o usuário nem percebe que ele existe; mal configurado, é o seu telefone que toca de madrugada.

Na onda cloud native atual, soluções de software como LVS, Nginx e HAProxy bastam para cenários de pequeno e médio porte, com vantagem clara de custo. Mas quando se trata da entrada crítica de finanças, bolsa de valores e grandes e-commerces, o valor do balanceamento por hardware — estabilidade, comutação em milissegundos e segurança ponta a ponta — continua insubstituível no curto prazo.

Quanto ao nome “F5”, a própria trajetória de empresa a categoria já diz muito — quando um produto passa a ser usado como verbo, ele já venceu esse mercado.

Camada 4 olha a placa, camada 7 abre o pacote; para desempenho, camada 4; para recursos, camada 7.

Referências: material oficial do F5 BIG-IP LTM, caso de balanceamento F5 do livro “Operação e Gestão de Redes”, comparativo técnico de balanceamento nas camadas 4/7