O balanceamento de carga, load balance, é uma configuração utilizada para redistribuir as requisições entre dois ou mais webservers, visando repartir recursos como banda e de hardware e para garantir convergência e alta disponibilidade do serviço.
Neste artigo vamos ver exemplos de duas ferramentas que realizam o load balance e, ao final, veremos uma conclusão dos dois testes. Quer ter mais conhecimento? Então confira o material exclusivo que nós da KingHost separamos!
Load Balance com HAProxy
O High Availability Proxy é um balanceador de carga, ou seja, realiza o load balance, e que atua como um proxy reverso – fiz um post sobre “Proxy Reverso: o que é e como usar“. Licenciado na GNU GPL 2, foi desenvolvido pelo Willy Tarreau, que também contribuiu com o desenvolvimento do kernel do linux.
Instalação no CentOS 7: yum install haproxy
Servidores: 3 máquinas virtuais:
1. HAProxy:
IP 192.168.0.111.
Hostname: lbhaproxy.com.br
As outras duas VMs possuem webserver nginx instalado:
2. backends
nginx01.com.br 192.168.0.104
nginx02.com.br 192.168.0.109
/etc/hosts da minha máquina física:
192.168.0.111 lbhaproxy.com.br
Arquivo /etc/haproxy/haproxy.cfg:
global
log 127.0.0.1 local2
maxconn 4096
user haproxy
group haproxy
daemon #spawna o processo em background
A configuração do user e group facilita se você quiser incluir algum serviço de monitoramento, como o monit, por exemplo.
Configuração do Log:
1. Alterei na sessão global de
De
log 127.0.0.1 local0 notice
Para
log 127.0.0.1 local2
- Criei o arquivo /etc/rsyslog.d/haproxy.conf
local2.* /var/log/haproxy
3. E criei o arquivo /var/log/haproxy
- Reiniciei o serviço do rsyslog: systemctl restart rsyslog
Demais configurações:
defaults #parâmetro default para todas as outras sessões
log global
option httplog #log de request http, sessões e timers
option dontlognull #conexão de monitoramento, por exemplo, poderia gerar muito lixo no log, esta opção desativa este tipo de log.
retries 3 #tentativas e conexão antes do HA entender que a conexão com o backend falhou
option redispatch #em caso de falha em um server, redistribui nos demais backends
maxconn 2000 #número máximo de conexões concorrentes, o HA proxy pára de aceitar novas conexões quando estoura esse valor
timeout connect 5000 #timeout da conexão
timeout client 50000 #timeout de inatividade no client side (conexão cliente <-> HA server)
timeout server 50000 #timeout no server side (conexão HA Server <-> backends)
mode http #define o modo de funcionamento do balanceador
listen webfarm #combina backend e HA Proxy em uma sessão só
bind 192.168.0.111:80 #apenas escuta neste IP do balanceador e respectiva porta 80
stats enable #ativa as estatísticas do serviço
stats auth admin:admin #usuário e senha para autenticação nas estatísticas
acl url_de_teste path_beg /teste #definição da acl, qualquer requisição para o /teste, usará o HA.
use_backend vanessa_lb if url_de_teste #associar a acl a um grupo de servidores
backend vanessa_lb #define a farm de servers backend para o site
balance roundrobin #define o algoritmo de balanceamento
server node1 192.168.0.104:80 check # define o servidor e porta e o parâmetro de Health check
server node2 192.168.0.109:80 check # define o servidor e porta e o parâmetro de Health check
Com essas configurações, ao acessar no meu navegador: http://lbhaproxy.com.br/teste, a requisição sera redirecionada para um dos backends (192.168.0.104 ou 192.168.0.109).
Log customizado:
Não há tratamento nesta configuração inicial para outras URLs que não o /teste (ocasionando os retornos 503) no log.
Deixei o servidor 192.168.0.109 (node2) indisponível e o HA já detectou essa queda (log 10:03:58), informando que não tinha rota, ou seja, ele enviará todas as requisições para 192.168.0.104 (node1), em alguns ms o HA fará uma nova checagem para verificar se o node2 já está operacional. Caso não, ele continuará a enviar requisições somente para o node1.
Load Balance com NGINX
O NGINX é extremamente poderoso, pois além de load balance, pode ser usado como servidor web, ao contrário do HA.
A estrutura também será de um load balancer e dois backends, conforme exemplo anterior.
* Se não for definido nada na diretiva http > upstream, o padrão será o algoritmo Round Robin.
* Para uso dos upstreams, é necessário habilitar o módulo ngx_http_upstream_module.
Configurações em /usr/local/nginx/conf/nginx.conf:
user nginx; #usuário dono do processo
worker_processes auto; #nesta configuração, o nginx spawnará os processos de acordo com o número de cores, configurando de maneira automática.
error_log /var/log/nginx/error.log; #arquivo de log
pid /run/nginx.pid; #ID do processo do nginx
events {
worker_connections 1024; #número de conexões
}
http {
log_format main ‘$remote_addr – $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for”‘
‘tempoRequisicao=$request_time tempoConnUpstream=”$upstream_connect_time” tempoHeadersUpstream=”$upstream_header_time” tempoRespostaUpstream=”$upstream_response_time”‘;
Este formato de log é importante para visualização dos tempos de conexão do load balancer em relação aos upstreams. O upstream é para onde ele redirecionará os acessos (192.168.0.104 e 192.168.0.109).
server {
listen 80 default_server; #Servidor padrão, escutando IPv4 e IPv6 na porta 80
listen [::]:80 default_server;
server_name _;
root /usr/share/nginx/html; #diretório root
include /usr/local/nginx/default/*.conf;
location / {
proxy_pass http://backend; #Redireciona todo acesso para um dos upstreams, listados à seguir
}
access_log /home/logs/access.log main; #Configuração dos logs de acesso
upstream backend {
server 192.168.0.104;
server 192.168.0.109;
}
Configuração por Passive Health Checks:
upstream backend {
server 192.168.0.104 max fails=3 fail_timeout=30s;
server google.com.br; #retornará erro 404
server 192.168.0.109;
}
Nesta configuração, ele faz um health check semelhante ao HA Proxy, se tiver 3x de retorno inválido, o NGINX não redirecionará novas requisições por 30 segundos para o 192.168.0.104.
Derrubei o serviço web do servidor 192.168.0.104, o balanceador do NGINX recebeu o retorno 499.
499 – CLIENT CLOSED REQUEST
É um código de status não padrão introduzido pelo NGINX para quando um cliente fecha a conexão enquanto o NGINX está processando a solicitação.
Neste caso, o 192.168.0.104 foi colocado em “blacklist” do upstream até a nova checagem, daqui a 12 segundos.
Como deixei o algoritmo de carga default, as demais requisições foram alternadas (Round Robin), podendo ser observada nos códigos de retorno 404 (upstream google.com.br) e upstream 302 – redirecionamento para o upstream 192.168.0.109.
Outra configuração possível é indicar um servidor para receber mais requisições que os demais:
upstream backend {
server 192.168.0.104 weight=3;
server google.com.br;
server 192.168.0.109;
}
Se os três servidores estiverem operacionais, a cada 5 requisições, 3 serão redirecionadas para o 192.168.0.104, 1 para o google.com.br e uma para o 192.168.0.109.
Existem diversas outras customizações que podem ser feitas no NGINX, porém a maioria delas são habilitadas somente na versão paga, o NGINX Plus, o que acaba engessando muitas das configurações de load balance com o NGINX.
Conclusão: onde as tecnologias são aplicadas?
As duas ferramentas para load balance são consolidadas. A primeira versão do HA é de 2002 e a do NGINX, de 2005, ambas escritas em C. HA Proxy possui uma versão paga, porém é mais relacionado à consultoria do que features disponibilizadas somente na versão comercial (no caso do NGINX).
O HA Proxy foi desenvolvido especificamente para balanceamento de carga, o NGINX é um webserver que também oferece o balanceamento e cache de conteúdo, então depende muito do que o administrador precisa na hora de escolher a ferramenta correta.
O HA possui muitas customizações que são nativas, porém requerem maior conhecimento técnico para aplicá-las, enquanto que o NGINX possui customizações semelhantes porém muitas são pertencentes apenas a plataforma paga e/ou requerem a adição/compilação de módulos adicionais.
Aqui na KingHost nós usamos o HA Proxy na estrutura de emails e do painel de controle. São alguns dos serviços que requerem alta disponbilidade e resiliência.
Deste modo, temos um cluster de servidores backend que recebem as requisições dos servidores de balancer. Em caso de indisponibilidade de algum backend, as próximas requisições não serão enviadas para ele, até que o backend esteja novamente operacional. Assim, você poderá acessar seus emails e realizar as configurações necessárias em seu painel de controle sem ser afetado por dificuldades em algum backend.
Quer ter toda essa tecnologia trabalhando ao seu favor? Contrate os planos da KingHost e tenha a melhor infraestrutura disponível no mercado, alinhado com o melhor suporte 24h/7.
Ficou com alguma dúvida relacionada ao conteúdo? Deixe nos comentários que a gente responde pra você!
Fique ligado no nosso LAB, o Blog da KingHost para mais conteúdos sobre desenvolvimento.
