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.

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
Vanessa de Oliveira Mello

Vanessa de Oliveira Mello

Analista de Infraestrutura Linux em KingHost
Cursando Análise e Desenvolvimento de Sistemas, trabalha há 9 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)

Comentários

comentário(s)