20/03/2014 → Guxta → Comentários: 9
Trabalho há alguns anos com HAProxy e Varnish, duas excelentes tecnologias opensource para aumentar a alta disponibilidade de sites web, mitigar ataques DoS e DDoS e melhorar a performance e o tempo de resposta de requisições HTTP.
Acontece que uma solução não substitui a outra. Vamos enter o por quê ?
Mas antes, vamos ver quais são os pontos em comum:
- reverse-proxy mode
- advanced HTTP features
- no SSL offloading
- client-side HTTP 1.1 with keepalive
- tunnel mode available
- high performance
- basic load-balancing
- server health checking
- IPv6 ready
- Management socket (CLI)
- Professional services and training available
E agora, as diferenças entre cada um deles.
Primeiro, as funcionalidades que existem no Varnish e que não existem no HAProxy:
- caching
- grace mode (stale content delivery)
- saint mode (manages origin server errors)
- modular software (with a lot of modules available)
- intuitive VCL configuration language
- HTTP 1.1 on server side
- TCP connection re-use
- Edge side includes (ESI)
- a few command line tools for stats (varnishstat, varnishhist, etc…)
- powerful live traffic analyzer (varnishlog)
- possibilidade de utilizar o fail2ban para bloquear ips graças ao varnishlog
- varnishlog podem ser gerados no padrão w3c, tendo assim uma maior facilidade quanto a análise de tráfego e objetos
Nota: O Varnish até que faz, e bem, balanceamento de carga e com a possibilidade de utilizar um health check, mas a performance do HAProxy o supera e muito .
E por último, as funcionalidades que só são presentes no HAProxy:
- advanced load-balancer
- multiple persistence methods
- DOS and DDOS mitigation
- Advanced and custom logging
- Web interface
- Server / application protection through queue management, slow start, etc…
- SNI content switching
- Named ACLs
- Full HTTP 1.1 support on server side, but keep-alive
- Can work at TCP level with any L7 protocol
- Proxy protocol for both client and server
- powerful log analyzer tool (halog)
Alguns pontos importantes:
- As boas práticas quanto a utilização do HAProxy requerem que vc tenha, no mínimo, 3 servidores. 1 dedicado ao HAProxy e os outros dois responsáveis por receberem o tráfego balanceado.
- Não adianta nada vc ter um HAProxy bem configurado e instalado em um S.O. que não esteja tunado. Estou falando de parâmetros no /etc/sysctl.conf e nas configurações do limits.
- Outro ponto é quanto a instalação e configuração de um firewall no HAProxy. Que seja um Iptables, mas que esteja configurado. Mesmo com ele instalado no HAProxy, haverá necessidade de ter um instalado no Varnish, já que o mesmo possui integração com o fail2ban.
- E aí vai outra dica. Uma segunda camada de Varnish não faz mal a ninguém, que o diga o pessoal da R7.com e da Globo.com
Arquitetura:
WEB ==> HAProxy Server ==> Server 1 ==> Server 2
E uma info importante – caso vc esteja utilizando o serviço de Cloud da Amazon, pense, e muito bem, em migrá-lo para a Digital Ocean, utilizando o HAProxy, pois eles possuem ip internos privados, melhorando e muito a performance do seu ambiente Web, além do custo ser bem mais atraente. Mas cuidado com a largura de banda, já que a DO não possui nenhuma solução anti-DDoS.
Eu por exemplo, tive que utilizar a cloudflrare para aguentar o tranco contra o blog. Melhor do que pagar uma fortuna de tráfego a RackSpace ou Amazon.
P.S.: tudo isso que foi dito, e mais um pouco, será abordado no curso de Varnish+Nginx+Apache do Coruja de TI, versão 2.0
Douglas Camata
Tenho uma dúvida: você sugere usar Varnish E HAProxy, ou somente um dos dois? Se for usar os dois, teria um Varnish para cada web server, ambos na mesma máquina?
Gustavo Lima
Douglas, a necessidade de se utilizar o HAproxy em conjunto com o Varnish dependerá, e muito, do tamanho do seu ambiente. Caso seja um ambiente que tenha mais de 2000 conexões TCP/IP estabelecidas por segundo, o emprego do HAProxy é mais do que recomendado, dividindo a sua carga com dois varnishs…
Daniel Checchia
Guscol, tudo bem?
A DO também possui IPs internos privados. A diferença é que vc precisa ir no painel e habilitar e depois subir (configurar) manualmente uma Eth para este IP privado.
Gustavo Lima
Daniel, isso mesmo, mas atenção, já que esta opção não está presente para todas as regiões que suportam o serviço da DO.
Humberto
Considerando o cenário ” […] no mínimo, 3 servidores. 1 dedicado ao HAProxy e os outros dois responsáveis por receberem o tráfego balanceado.” uma falha no servidor HAProxy acarretaria em impossibilidade de acesso em nenhum dos outros dois servidores, correto ?
Para resolver esse problema eu precisaria de, pelo menos, 4 servidores !?
2 HAProxy com keep-alive/heartbeat e os outros dois que receberiam o tráfego balanceado ?
Gustavo Lima
Humberto, excelente pergunta. Primeiro, são poucas as empresas que utilizam mais de um load balance para suportar o seu ambiente, e por isso que o post foi focado neste tipo de cenário. Mas tentarei explicar cenários que possuem mais de 1 load balances – todo o load balance possui um ip vip, onde este ip que fica configurado no dns ou é passado para algum ambiente quando desejamos que a carga que ele receba seja distribuída para um conjunto de servidores. Quando temos mais de 1 load balance apontando para os mesmos servidores e com mais vips, há necessidade de adicionar a função de “balanceamento de carga” ao seu serviço de DNS, onde o mesmo utilizará o algoritmo de round-robin – a amazon possui um serviço igual a este que acabei de falar e com mais inteligência do que costumamos ver no mercado – health check, por exemplo. Acredito que vc pensou no spof – single point of failure quando fez o seu comentário, correto ?
Humberto
Exatamente, Gustavo !
Muito obrigado pelo esclarecimento !
[]s
S0nic
Muito bom colega!! Você deveria preparar um curso de Alta disponibilidade em servidores web, seria muito bem vindo abordando varnish , ngx e HA PROXy!!!
Gustavo Lima
S0nic, obrigado pela dica. Mas antes de montar este treinamento, finalizarei os anteriores e divulgarei no mercado. Bem que este, de alta disponibilidade, poderia ser de 6 horas e com um preço bem em conta.