HAProxy

HAProxy (High Availability Proxy) é um balanceador de carga e servidor proxy TCP/HTTP de código aberto e alto desempenho, que distribui o tráfego de rede entre vários servidores backend para maximizar performance, confiabilidade e capacidade de servidor. Ele opera tanto na camada 4 (TCP) quanto na camada 7 (HTTP) do modelo OSI, permitindo gerenciamento preciso de tráfego, alta disponibilidade e uso eficiente de recursos para aplicações e serviços.

O HAProxy é conhecido por sua velocidade, estabilidade e capacidade de lidar com volumes de tráfego muito altos. Costuma ser implantado na frente de servidores web, servidores de aplicação e clusters de banco de dados para garantir a distribuição uniforme das requisições dos clientes, evitar sobrecarga de servidores e facilitar operações de manutenção sem interrupções.

Load balancing com HAProxy

Load balancing é o processo de distribuir o tráfego de rede entre um grupo de servidores backend, conhecido como server farm ou cluster. O HAProxy usa vários algoritmos para determinar qual servidor recebe a próxima requisição, com o objetivo de otimizar o uso de recursos, maximizar o throughput, minimizar o tempo de resposta e evitar a sobrecarga de servidores individuais.

Os principais aspectos do load balancing do HAProxy incluem:

• Seleção de algoritmo: o HAProxy oferece vários algoritmos para atender a diferentes necessidades de aplicação.
• Health checks de servidores: monitoramento contínuo da disponibilidade e da capacidade de resposta dos servidores backend.
• Peso dos servidores: priorização de determinados servidores para receberem mais tráfego.

Algoritmos de load balancing

O HAProxy oferece uma variedade de algoritmos configurados na seção backend:

• roundrobin: distribui as requisições sequencialmente para cada servidor do grupo backend. Algoritmo padrão.
• leastconn: direciona novas conexões para o servidor com menos conexões ativas. Ideal para conexões de longa duração.
• source: usa um hash do endereço IP de origem para determinar o servidor. Garante que um cliente se conecte sempre ao mesmo servidor, útil para aplicações com estado sem persistência de sessão explícita.
• uri: aplica hash à parte esquerda da URL (antes da query string) para escolher um servidor. Útil para proxies de cache.
• hdr(<name>): aplica hash ao valor de um header HTTP especificado.
• random: escolhe um servidor aleatoriamente.

backend web_servers
    balance roundrobin
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check
    server web3 192.168.1.12:80 check

Proxy com HAProxy

O proxying envolve um servidor intermediário que atua em nome de um cliente ou servidor. O HAProxy funciona como reverse proxy: aceita conexões dos clientes, encaminha-as para os servidores backend e devolve as respostas dos servidores aos clientes. Essa camada de abstração traz benefícios de segurança, performance e operação.

Proxy na camada 4 (TCP)

Na camada 4, o HAProxy encaminha conexões TCP brutas sem inspecionar o conteúdo da camada de aplicação. Isso é adequado para serviços não HTTP, bancos de dados ou protocolos personalizados em que a inspeção de conteúdo não é necessária nem desejada.

listen mysql_cluster
    bind *:3306
    mode tcp
    balance leastconn
    server db1 192.168.1.20:3306 check
    server db2 192.168.1.21:3306 check

Proxy na camada 7 (HTTP)

Na camada 7, o HAProxy pode inspecionar e manipular headers de requisição e resposta HTTP, URLs e cookies. Isso habilita recursos avançados como roteamento baseado em conteúdo, terminação SSL, reescrita de URL e persistência de sessão.

frontend http_frontend
    bind *:80
    mode http
    default_backend web_servers

Componentes de configuração do HAProxy

A configuração do HAProxy normalmente fica em /etc/haproxy/haproxy.cfg e é estruturada em várias seções.

Seção global

A seção global define parâmetros válidos para todo o processo, como logging, configurações de segurança e limites de performance. Essas definições se aplicam a toda a instância do HAProxy.

global
    log /dev/log    local0 info
    maxconn 20000
    chroot /var/lib/haproxy
    pidfile /var/run/haproxy.pid
    user haproxy
    group haproxy
    daemon
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners

Seção defaults

A seção defaults especifica parâmetros padrão para todas as seções listen, frontend e backend que vierem depois dela. Isso reduz a redundância na configuração.

defaults
    mode http
    log global
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms
    option httplog
    option dontlognull
    option http-server-close

Seção frontend

Um frontend define o ponto de entrada público onde o HAProxy escuta as conexões dos clientes. Ele especifica o endereço IP, a porta, o protocolo (mode) e as regras para rotear requisições para backends específicos usando Access Control Lists (ACLs).

frontend http_in
    bind *:80
    mode http
    acl host_app1 hdr(host) -i app1.example.com
    acl host_app2 hdr(host) -i app2.example.com

    use_backend app1_servers if host_app1
    use_backend app2_servers if host_app2
    default_backend default_web_servers

Seção backend

Um backend define um grupo de servidores para os quais o HAProxy pode encaminhar requisições. Inclui o algoritmo de load balancing, os parâmetros de health check e as definições individuais de servidor.

backend app1_servers
    balance leastconn
    option httpchk GET /healthz
    server s1 10.0.0.10:8080 check inter 2000 fall 3 rise 2
    server s2 10.0.0.11:8080 check inter 2000 fall 3 rise 2 backup

• check: habilita health checks para o servidor.
• inter 2000: verifica a cada 2000ms.
• fall 3: marca o servidor como fora do ar após 3 verificações falhas consecutivas.
• rise 2: marca o servidor como no ar após 2 verificações bem-sucedidas consecutivas.
• backup: o servidor só será usado quando todos os outros servidores não backup estiverem fora do ar.

Seção listen

Uma seção listen combina as funcionalidades de um frontend e de um backend em um único bloco. Costuma ser usada em configurações mais simples ou para serviços como a página de estatísticas do HAProxy.

listen stats_page
    bind *:8080
    mode http
    stats enable
    stats uri /haproxy?stats
    stats realm HAProxy\ Statistics
    stats auth admin:securepassword
    stats refresh 5s

Access Control Lists (ACLs)

ACLs são regras condicionais poderosas usadas para casar critérios específicos nas requisições dos clientes (por exemplo, IP de origem, header host, caminho da URL, método HTTP). Elas permitem roteamento dinâmico, content switching e bloqueio.

frontend website_frontend
    bind *:443 ssl crt /etc/haproxy/certs/mydomain.pem

    # ACLs baseadas no caminho
    acl is_admin_area path_beg /admin
    acl is_api_v1   path_beg /api/v1

    # Roteamento com base nas ACLs
    use_backend admin_backend if is_admin_area
    use_backend api_v1_backend if is_api_v1
    default_backend main_website_backend

Health checks

O HAProxy monitora continuamente a saúde dos servidores backend para garantir que as requisições sejam enviadas apenas a instâncias operacionais. Se um servidor falha nos health checks, o HAProxy o remove temporariamente da rotação até que ele se recupere.

• TCP check (check): conectividade básica de porta.
• HTTP check (option httpchk): envia uma requisição HTTP (por exemplo, GET /health) e espera um código de status HTTP válido (2xx ou 3xx).
• SSL Hello check (ssl-hello-chk): verifica se é possível estabelecer um handshake SSL.

Recursos avançados do HAProxy

Terminação e offloading de SSL

O HAProxy pode cuidar da criptografia e da descriptografia SSL/TLS, tirando essa tarefa intensiva em CPU dos servidores backend. Ele descriptografa o tráfego HTTPS de entrada e encaminha HTTP puro para o backend, ou pode recriptografar para SSL ponta a ponta.

frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/mydomain.pem
    mode http
    default_backend web_servers

Sticky sessions (persistência)

As sticky sessions garantem que as requisições de um cliente sejam sempre roteadas para o mesmo servidor backend durante toda a sessão. Isso é crítico para aplicações que mantêm o estado da sessão em servidores individuais.

• Persistência por cookie: o HAProxy insere um cookie no navegador do cliente, que depois é usado para identificar o servidor backend correto nas requisições seguintes.
• Persistência por IP de origem: usa o endereço IP de origem do cliente para rotear sempre para o mesmo servidor (menos confiável atrás de NAT).

backend web_servers_sticky
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server s1 10.0.0.10:80 check cookie s1
    server s2 10.0.0.11:80 check cookie s2

Roteamento baseado em conteúdo

O roteamento baseado em conteúdo direciona o tráfego para diferentes pools de servidores backend conforme atributos específicos da requisição do cliente, como o caminho da URL solicitada, o header host HTTP ou headers HTTP personalizados. Isso facilita arquiteturas de microsserviços ou aplicações multi-tenant.

(Exemplo já mostrado na seção frontend, com acl host_app1 e use_backend.)

Alta disponibilidade do próprio HAProxy

Embora o HAProxy seja projetado para dar alta disponibilidade aos serviços backend, as próprias instâncias do HAProxy podem se tornar altamente disponíveis com mecanismos externos como VRRP (Virtual Router Redundancy Protocol) e ferramentas como o Keepalived. Isso cria um endereço IP flutuante que faz failover automático entre os servidores HAProxy primário e secundário em caso de falha, garantindo serviço contínuo de load balancing.

HAProxy vs. Nginx (comparação breve)

Tanto o HAProxy quanto o Nginx podem funcionar como reverse proxies e balanceadores de carga. Seus objetivos principais de design e os padrões típicos de implantação são diferentes.

O HAProxy costuma ser escolhido para ambientes críticos de alto tráfego, em que performance pura de load balancing e health checking robusto são essenciais. O Nginx é frequentemente usado quando se precisa de uma combinação de servidor web, cache e reverse proxy, além do load balancing. É comum vê-los implantados juntos, com o HAProxy atuando como load balancer principal e o Nginx cuidando de proxy específico no nível da aplicação ou de conteúdo estático.