01/09/2017 Alta disponibilidade e load balance HTTP com HAProxy

()  ()  (sobre)

Alta disponibilidade e load balance HTTP com HAProxy

03/09/2012 por Paulo H. Cazarotto

Alta disponibilidade em serviços web é indispensável para o sucesso de um negócio na Internet. Em uma loja virtual seus visitantes
podem desistir de navegar se sua página demorar muito tempo para carregar, seus potenciais compradores podem descon ar da baixa
qualidade do serviço e irem procurar o que querem em outra loja. Sem contar o trabalho necessário para reestabelecer o serviço.
Recuperando backups porque dados foram salvos parcialmente devido a um shutdown forçado do administrador de infraestrutura que
estava desesperado.
Este artigo irá explicar como utilizar o HAProxy para criar um ambiente de alta disponibilidade com balanceamento de carga. Não é
intenção explicar a construção do ambiente completo, da aplicação ao banco de dados, pois o assunto é extenso e pode variar muito de
acordo com a tecnologia utilizada na sua aplicação. Então aqui vou explicar apenas um pouco da arquitetura, focando em uma aplicação
para o frontend do ambiente de alta disponibilidade. Que no nal das contas é uma parte muito importante do ambiente de HA (i{High
Availability}i) que não pode car indisponível para o cliente em momento nenhum.

Cenário de alta disponibilidade

O cenário da REF{cenario} é um exemplo de arquitetura simples de alta disponibilidade, com um sistema web composto por três camadas
de servidores: rewall, aplicação e banco de dados. Na camada de rewall há um servidor que recebe todas as conexões provenientes da
Internet, neste caso normalmente é su ciente um servidor de backup, que é ativo automaticamente quando é detectada a falha no
rewall mestre. Na camada de aplicação consideramos múltiplos servidores provendo a mesma aplicação, se um servidor tiver problemas
os outros podem dar conta do serviço. O mesmo vale para o banco de dados.

Note que na prática o esquema todo não é tão simples assim. Garantir o funcionamento da aplicação em mais de um servidor ao mesmo
tempo pode ser bem complicado se analisar os detalhes técnicos, como compartilhamento de cookies/sessões, rotinas agendadas e até a
manutenção de arquivos. E garantir consistência e redundância em um banco de dados não é uma tarefa fácil, basta olhar alguns
manuais pela Internet para entender que não é apenas um desenvolvedor que pode manter este ambiente. Até porque isso é trabalho
para um administrador de infraestrutura e/ou DBA.
Como indiquei no início deste artigo, a ideia é focar no frontend do ambiente de alta disponibilidade. O frontend no cenário acima é o
servidor de rewall, que está exposto ao à Internet e é por onde todas as conexões de usuários "entram no ambiente de HA". No futuro
pretendo explicar o uso de outras aplicações para HA tanto no frontend quanto na aplicação web e banco de dados. Este artigo não
explicará como criar o servidor de rewall backup, já estou montando outro artigo sobre este assunto para publicar aqui no site.

Um pouco mais sobre o HAProxy

O HAProxy (http://haproxy.1wt.eu/) é oferecido como um con ável balanceador de carga de alto desempenho para HTTP e TCP. Na prática
ele recebe as conexões dos usuários e atua como um proxy (http://pt.wikipedia.org/wiki/Proxy), criando um canal entre o usuário e um
dos servidores de aplicação. Há benchmarks bem interessantes indicando desempenho de mais de 40 mil conexões por segundo
(http://haproxy.1wt.eu/10g.html) em um hardware já considerado ultrapassado com rede de 10Gbps.
Esta aplicação possui alguns mecanismos interessantes para escolher o servidor web que deve encaminhar a solicitação do usuário.
Dentre as estratégias de escalonamento suportadas as mais importantes, no meu ponto de vista, são:
Round-robin (http://pt.wikipedia.org/wiki/Round-robin_%28algoritmo%29): Onde o servidor é escolhido de forma circular,
independente da carga em cada um dos servidores de aplicação;
Menos conexões: Onde o servidor com menos conexões é escolhido, o que garante que o servidor mais ocioso seja utilizado;
Cookie: Onde o HAProxy tentará sempre indicar o mesmo servidor que o usuário conectou pela primeira vez;
Hash de IP: Neste caso a aplicação irá escolher o servidor de acordo com o IP.
Dentre os mecanismos acima, apenas o mecanismo de cookie não é um escalonador do HAProxy, ou seja, deve ser combinado com o
escalonador round-robin ou de menos conexões. O mecanismo de cookie ou o escalonador por hash de IP são muito importantes para
garantir que seu cliente não perca a sessão da aplicação HTTP. Sem isso seu usuário pode ser "deslogado" da aplicação quando o

https://phcco.com/alta-disponibilidade-e-balanceamento-de-carga-http-com-haproxy 1/6
01/09/2017 Alta disponibilidade e load balance HTTP com HAProxy
escalonador trocar o servidor de aplicação. O uso do escalonador de menos conexões é muito útil em casos onde as conexões demoram
a ser fechadas, nestes casos evita-se que por uma "sorte" um servidor seja sempre escolhido para as conexões mais demoradas.

Ambiente de testes
Para testar o ambiente montei um conjunto de máquinas virtuais. O host destas máquinas virtuais era um Quad Core com 8 Gb de RAM e
executava além da máquina do HAProxy duas máquinas virtuais com as aplicações web e banco de dados e uma máquina virtual que
realizava as conexões repetitivas de teste através do HAProxy. A situação pode ser visualizada na REF{testemaquinavirtual}.

Neste artigo vou apresentar as con gurações utilizando os IPs indicados no esquema da REF{testemaquinavirtual}. Todas estas máquinas
estão ligadas em um mesmo switch gigabit em uma mesma rede. Como no meu caso utilizava uma rede virtual da própria plataforma de
virtualização, a comunicação não era nem mesmo enviada ao switch. O ideal é manter apenas a máquina com o rewall conectada a
Internet, e manter as demais máquinas em uma DMZ (zona desmilitarizada) (http://en.wikipedia.org/wiki/DMZ_%28computing%29). As
máquinas utilizadas são (todas com sistema operacional Debian 6):
MV-Cliente-01 (IP 192.168.25.30, 2 Cores + 1024 GB RAM): Nesta máquina foi instalada a aplicação Apache Bench (do pacote apache-
utils no Debian). Esta aplicação permite criar múltiplas conexões a um mesmo endereço e também cria um relatório estatístico
básico com as informações do teste;
MV-Firewall-01 (IP 192.168.25.41, 2 Cores + 1024 GB RAM): Esta máquina é que executa o HAProxy;

MV-App-01 (IP 192.168.25.51, 2 Cores + 512 GB RAM): Esta máquina possui a aplicação web que será servida aos clientes;
MV-App-02 (IP 192.168.25.52, 2 Cores + 512 GB RAM): A segunda máquina que possui a aplicação web.

Con guração do HAProxy

Você pode compilar o HAProxy a partir do fonte, disponível no site do HAProxy (http://haproxy.1wt.eu/). No Debian é bem mais fácil
instalar através do apt-get .

# Primeiro de tudo, entre no modo ROOT, no caso do Debian e demais variações:

su
# Instalando o HAProxy
apt-get install haproxy

O próximo passo é editar o arquivo /etc/haproxy/haproxy.cfg . O arquivo original possui vários exemplos, crie um novo arquivo e insira o
conteúdo abaixo se quiser con gurar conforme o ambiente exposto na REF{testemaquinavirtual}.

https://phcco.com/alta-disponibilidade-e-balanceamento-de-carga-http-com-haproxy 2/6
01/09/2017 Alta disponibilidade e load balance HTTP com HAProxy
# Nesta seção informamos parâmetros gerais do HAProxy
global
# Qual o número máximo de conexões?
maxconn 3000
5. # Qual é o usuário que o HAProxy deve usar no Debian?
user haproxy
# Qual é o grupo de usuário que o HAProxy deve usar no Debian?
group haproxy
# Indicamos que a aplicação deve executar como um daemon
10. daemon
# Quantos processos do HAProxy devem ser executados?
# Não faz sentido utilizar mais de um com apenas um núcleo de processador
nbproc 1

15. # Nesta seção informamos parâmetros para o frontend and backend

defaults
# Modo HTTP, já que vamos servir páginas por HTTP
mode http
# Habilitamos as estatísticas
20. stats enable
# Definimos um usuário e senha para acesso as estatísticas
stats auth usuario:senha
# Ocultamos a versão do HAProxy
stats hide-version
25. # Informamos que a página de estatísticas deve recarregar a cada segundo
stats refresh 1s
# Indicamos qual a URI vamos acessar para ler as estatísticas
stats uri /estatisticasdohaproxy
# Aqui escolhemos o escalonador
30. balance roundrobin
# A opção abaixo força o HTTP 1.0, liberando as conexões mesmo
# se o servidor servir em HTTP 1.1 com KeepAlive ativo no cliente
option httpclose
# Indicamos ao HAProxy encaminhar o IP do usuário ao servidor de aplicação
35. option forwardfor
# Informamos a chamada que deve ser feita no servidor de aplicação
# para detectar se este está online ou offline
option httpchk GET / HTTP/1.1\r\nHost:\ localhost
# Indicamos qual é o tempo máximo de conexão do backend
40. timeout connect 3000ms
# Indicamos qual é o tempo máximo de espera de resposta do backend
timeout server 50000ms
# Indicamos qual é o tempo máximo de espera de comunicação do usuário
# com o frontend (o firewall)
45. timeout client 50000ms

# Definimos a porta de entrada de conexões

frontend HA-HTTP
# Indicamos qual é a porta no firewall para entrada
50. # Neste caso é necessário escolher a porta 80, de qualquer interface (*)
bind *:80
# Indicamos qual é o número máximo de conexões no frontend
maxconn 3000
# Indicamos qual é o backend que deve servir esta porta
55. default_backend App-Servers

# Aqui definimos os servidores de backend (de aplicação)

backend App-Servers
# Associamos ambos os servidores
60. # indicando que deve ser utilizado um cookie para persistência
server App01 192.168.25.51:80 cookie HAP check
server App02 192.168.25.52:80 cookie HAP check

Agora basta salvar o arquivo e reiniciar o serviço (ainda como ROOT):

/etc/init.d/haproxy restart

Ambiente pronto para os testes!

Testes com o HAProxy

No ambiente que foi montado, basta acessar http://192.168.25.41/haproxyinfo para observar a situação do HAProxy (REF{haproxy}). É
possível ver o número de conexões, os valores máximos atingidos até o momento, o volume de dados trafegados pelo HAProxy e também
a situação de cada servidor de backend.

https://phcco.com/alta-disponibilidade-e-balanceamento-de-carga-http-com-haproxy 3/6
01/09/2017 Alta disponibilidade e load balance HTTP com HAProxy

Os testes foram feitos apenas para avaliar o comportamento da aplicação. Tentei realizar alguns testes de desempenho porém ao utilizar
máquinas virtuais os resultados foram muito similares pois as máquinas compartilhavam o mesmo hardware, desta forma não
apresentaram-se resultados consistentes onde é possível observar os gargalos. Para gerar as cargas utilizei os seguintes comandos
dentro da máquina virtual cliente:
# Sintaxe básica do Apache Bench
# ab -c <numero> -t <numero> URL
# -c <numero> (número de conexões concorrentes)
# -t <numero> (tempo em segundo para teste)
5. # URL (URL utilizada no teste)
ab -c 10 -t 30 http://192.168.25.41/
ab -c 50 -t 30 http://192.168.25.41/
ab -c 100 -t 30 http://192.168.25.41/
ab -c 300 -t 30 http://192.168.25.41/
10. ab -c 600 -t 30 http://192.168.25.41/

Na REF{haproxy-gd} há um print do monitoramento logo após parar a máquina virtual responsável pelo App02. No momento estava
realizando o teste de 600 conexões concorrentes. Alguns segundos depois, o HAProxy marca o servidor de backend como o ine e
automaticamente passa a conectar apenas no App01. Neste caso o desempenho cai, porém o serviço não ca o ine.

https://phcco.com/alta-disponibilidade-e-balanceamento-de-carga-http-com-haproxy 4/6
01/09/2017 Alta disponibilidade e load balance HTTP com HAProxy

Com ambos servidores ativos, consegui até 3.000 conexões simultâneas por segundo nos resultados do Apache Bench. Não é possível
con ar nas estatísticas do HAProxy. Se utilizar dois processos ( nbproc 2 ) a página de monitoramento intercala entre ambos os processos
e não apresenta resultados consolidados.
Se ambos os servidores carem o ine as conexões são recebidas e o HAProxy mantém a conexão até que um servidor que disponível.
Se muitas conexões acumularem o timeout con gurado no HAProxy é responsável por eliminar estas conexões. É claro que se houverem
muitas conexões e o timeout for muito alto o rewall poderá car o ine também. Há outras técnicas para resolver esse problema de
DDoS (http://en.wikipedia.org/wiki/Denial-of-service_attack).
Note que o Linux possui algumas restrições quanto a quantidade de conexões simultâneas, relacionadas ao número de descritores de
arquivos. Se algumas variáveis não estiverem devidamente ajustadas no kernel você não conseguirá chegar um grande número de
conexões simultâneas. Dê uma conferida nas variáveis somaxconn , portrange , tcp_fin_timeout , netdev_max_backlog , file-max , ulimit ...
e outras.

Conclusões
Na prática a ferramenta é muito interessante para implementar um ambiente de alta disponibilidade, o balanceamento de carga é
consequência. Há como con gurar os servidores no esquema de master/backup, tendo assim um sistema de alta disponibilidade sem o
balanceamento de carga. Não faz muito sentido se o hardware está disponível sempre, mas se você pagar a infraestrutura pelo consumo
de recursos (processador + memória) talvez lhe interesse.
Com relação ao processamento e consumo de memória, não consegui chegar ao limite de recursos no ambiente, o gargalo era o sistema
de virtualização. Por algum motivo não conseguia trafegar mais de 100 megabits nas máquinas virtuais. O tamanho da página com certeza
mudaria os resultados dos testes feitos. Uma página maior ocupará por mais tempo o rewall que obviamente demandará de mais
recursos para atender mais conexões simultâneamente. O uso de um ou dois processos não mudou muito os resultados, acredito que o
uso das máquinas virtuais também colaborou para isso.
A aplicação pareceu bem estável, não indisponibilizando as conexões dos clientes, apenas atrasando a resposta mesmo quando um dos
servidores cava o ine. Esta aplicação não é exclusiva para HTTP, ela pode servir outras conexões TCP e balancear a carga de diversas
aplicações que utilizem TCP.
Creio que os próximos testes envolverão a comparação entre outras aplicações com a mesma funcionalidade, como o Pound e o
CrossRoads. Precisarei de máquinas físicas separadas para o resultado apresentar resultados consistentes. Há outros cenários de alta
disponibilidade que envolvem o uso de aplicações de caching no frontend do ambiente. Estas aplicações não podem ser comparadas com
este tipo de aplicação diretamente, mas podem isolar e diminuir a carga nos servidores de backend, em breve criarei um artigo
explicando uma destas aplicações.

Referências
Site do HA Proxy (http://haproxy.1wt.eu/)
Manual do Apache Bench (http://httpd.apache.org/docs/2.2/programs/ab.html)

https://phcco.com/alta-disponibilidade-e-balanceamento-de-carga-http-com-haproxy 5/6
01/09/2017 Alta disponibilidade e load balance HTTP com HAProxy

0 comentários Classificar por Mais antigos

Adicionar um comentário...

Plugin de comentários do Facebook

https://phcco.com/alta-disponibilidade-e-balanceamento-de-carga-http-com-haproxy 6/6