Load Balance: o que é e como funciona


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 vem comigo.

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 no LAB que pode ser lido aqui. 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

  1. Criei o arquivo /etc/rsyslog.d/haproxy.conf
    local2.* /var/log/haproxy

    3. E criei o arquivo /var/log/haproxy
  1. 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.

KingHost parceria de sucesso

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

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 a 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.

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.

Vanessa de Oliveira Mello

Network Analyst | NOC | NetOps em KingHost
Cursando Engenharia de Software, trabalha há 10 anos com T.I. Apaixonada por infraestrutura, redes, programação e indie rock dos anos 90.
Vanessa de Oliveira Mello

Últimos posts por Vanessa de Oliveira Mello (exibir todos)

Resumo
Load Balance: o que é e como funciona
Nome do Artigo
Load Balance: o que é e como funciona
Descrição
Neste artigo vamos ver exemplos de duas ferramentas que realizam o load balance e, ao final, veremos uma conclusão dos dois testes.
Autor
Nome
KingHost
Logo

Comentários

comentário(s)