() () (sobre)
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.
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.
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.
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
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
Adicionar um comentário...
https://phcco.com/alta-disponibilidade-e-balanceamento-de-carga-http-com-haproxy 6/6