Replicação e balanceamento de carga em servidores usando DNS

Aqui apresentarei uma forma barata, simples e fácil de implementar replicação e balanceamento de carga de servidores web, mas que pode ser usada para outros tipos de serviços, tais como SMTP, FTP, etc.

[ Hits: 76.998 ]

Por: Diego Ribas Adiers em 14/05/2005


Resolvendo o problema



Esse problema é cada vez mais comum nas empresas que estão crescendo e que já oferecem algum tipo de serviço via web. E ele pode ser resolvido elegantemente com o uso de software livre (Bind e Apache).

Então vamos à resolução do problema! Vou supor que você já possui os 2 servidores web rodando Apache (existe muita documentação de como instalar e configurar o Apache). Para saber mais acesse:
Vou supor também que o IP do servidor1 é 1.2.3.1 e do servidor2 é 1.2.3.2. Note que você pode possuir quantos servidores web necessitar, mas aqui exemplificarei com apenas 2.

Bom, o grande segredo está na configuração do DNS (BIND). Não entrarei no mérito da instalação e configuração do BIND aqui no artigo, pois existe muita documentação a respeito, inclusive aqui no Viva o Linux.

Para consultar documentação do BIND acesse o site:
Aqui no artigo direi que o domínio da minha empresa é exemplo.com.br. O que muitos não sabem é que o BIND possui uma "feature" chamada round robin. O round robin funciona como uma fila. Por exemplo, suponhamos que existem 3 clientes acessando meus servidores web. O primeiro acessa e o DNS redireciona para o servidor1. O segundo cliente acessa e o servidor DNS redireciona para o servidor2 e o terceiro cliente acessa e o DNS redireciona ao servidor1 novamente... e assim por diante.

Explicado o que é round robin, vamos à implementação do mesmo no BIND 9.x (não muito diferente para outras versões). No arquivo de configuração do BIND (geralmente em /etc/named.conf) teremos algo como:

zone "." in {
        type hint;
        file "root.hint";
};

zone "localhost" in {
        type master;
        file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.0.0.zone";
};

zone "exemplo.com.br" in {
        type master;
        file "master/exemplo.com.br";
};

No arquivo de configuração da zona master "exemplo.com.br", que no meu caso está em /var/lib/named/master/exemplo.com.br, preciso ter algo como:

$TTL 172800
@  IN SOA    dns1.exemplo.com.br.    email.exemplo.com.br. (
              2004082903      ; serial
              1800            ; refresh
              900             ; retry
              604800          ; expiry
              1D )            ; minimum

      IN NS           dns1
      IN NS           dns2
      IN MX           10 mail

dns1  IN A            1.2.3.41
dns2  IN A            1.2.3.42
mail  IN A            1.2.3.50

www   IN  A    1.2.3.1
      IN  A    1.2.3.2
      IN  A    1.2.3.3
      IN  A    1.2.3.4
      ....
      ; assim por diante.

Assim, quando o DNS for resolver www.exemplo.com.br, usará round robin para balancear a carga entre os servidores. Uma parte do problema está resolvida. Não preciso mais comprar um servidor tão potente, posso usar o que eu tenho e comprar outro igual. O outro problema era o serviço sempre estar disponível. Isso nosso caro BIND cuida também!

Quando um servidor www "cair", o bind notará e passará as resoluções de nomes apenas para os servidores que estão em pleno funcionamento, não deixando assim o nosso serviço "fora" e permitindo assim tolerar falhas de hardware, software, ou então nos permitir fazer manutenções programadas. Ótimo não? Diria que é ótimo em relação ao trabalho que se tem para configurar essa replicação/balanceamento. Mas existem alguns problemas. Vamos à eles:

1 - A atualização dos servidores web é muito custosa se eu tiver vários replicados. Uma possível solução para isso seria utilizar um sistema de arquivos distribuído (compartilhado) como o NFS. Assim bastaria a atualização no servidor que exportaria o diretório da página web.

2 - O problema de cache de DNS. Porque os DNSs possuem uma cache para as últimas requisições realizadas para agilizar nesse processo de resolução. Isso pode ser um problema porque o balanceamento não seria feito de forma justa para todos os servidores www. Uma "solução" que apenas ameniza o problema é a diminuição do TTL (time to live), que é o tempo de vida de um registro em uma cache de DNS em segundos. Então com um TTL baixo eu faço com que o outros servidores DNS não guardem por muito tempo o registro em suas caches. Ou seja, amenizo o problema de cache.

Se isso não for problema para seu tipo de replicação/balanceamento, recomendo fortemente o uso do DNS para esse propósito. Porque além de simples, é de fácil implementação e funciona muito bem. Testei isso em um sistema real e foi além das minhas expectativas.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Resolvendo o problema
   3. Conclusão
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Configurando Servidor WEB Completo [Apache2 + Postfix/Courier + Bind9 + ISPConfig + Roundcube Webmail]

Ubuntu Server 12.04 LTS - Como Servidor Gateway e DHCP

Instalando o CMS Joomla

VPN (filial) autenticando e usando o proxy do servidor de VPN (matriz)

Configurando o a1200i Motorola Motoming para acessar internet em seu Linux Slackware

  
Comentários
[1] Comentário enviado por filipealvarez em 14/05/2005 - 11:47h

Antes de tudo parabens pelo artigo. Gostaria de saber se é possivel tambem fazer isso com um servidor de email (MX)... funcionaria dessa forma?

MX mail.dominio.com.br
mail IN A 1.2.3.1
IN A 1.2.3.2

Teria algum problema? (fora os ja citados no artigo?)

[2] Comentário enviado por y2h4ck em 14/05/2005 - 23:07h

Onde entra a replicação ???

[3] Comentário enviado por rdsat em 15/05/2005 - 09:49h

Também fiquei com a dúvida do y2h4ck .... cade a replicação ????

[4] Comentário enviado por diego.ribas em 15/05/2005 - 22:49h

No caso da replicação de servidores de e-mail é um pouco diferente. Na maioria das vezes a replicação ocorre criando um servidor master e seus slaves que são apenas backups do master. Para isso se define prioridades de entrega do e-mail entre os servidores no DNS. Algo como:
IN MX 10 mail
IN MX 20 mail2
IN MX 30 mail3
... assim por diante
Note ainda que precisa configurar adequadamente ainda teu servidor de e-mail para funcionar corretamente isso.
Mas não sei se seria exatemente esse tipo de replicação que te interessa...
Outra replicação utilizada é do servidor SMTP que funciona da mesma forma que a do servidor www.

[5] Comentário enviado por diego.ribas em 15/05/2005 - 22:51h

A respeito da replicação:
A replicação ocorre quando eu possuo uma ou mais cópias do objeto replicado. No caso dos servidores web, eu posso ter quantas cópias eu necessitar. No exemplo do artigo, ocorreu a replicação do servidor web(1.2.3.1) onde sua réplica é o 1.2.3.2 . Então é lógico que ocorreu replicação não concordam?

[6] Comentário enviado por o_lalertom em 16/05/2005 - 08:59h

Parabens pelo artigo,

E quando li seu artigo voce falou de possiveis problemas de atualizacao dos arquivos do site.

Para solucionar este tipo de problema eu uso o 'rsync' um sincronizador de arquivos remoto, num sei se voce ja o conhece, ele e muito leve e facil de configurar. O tipo de sincronicao que o 'rsync' trabalha e de tempo real, e ele atualiza por pacotes que agiliza muito a sincronizacao.

Fica ai uma dica a mais, se alguem estiver enterecado e so acessar o site:

http://www.samba.org/rsync/

para maiores detalhes.

Falou, ate a proxima...

[7] Comentário enviado por ygorth em 16/05/2005 - 10:31h

O artigo ta muito bom. A dica do rsync tambem ... (:

[8] Comentário enviado por diego.ribas em 16/05/2005 - 13:43h

Quanto ao rsync:
Conheço sim. Mas nunca utilizei o mesmo. Alias muito boa a dica do rsync. Resolve o problema de atualizacao dos varios servidores.

[9] Comentário enviado por soviedo em 17/05/2005 - 11:47h

Muy buen articulo, yo lo tengo implementado en mis servidores de mail...funciona a la perfección !!!

[10] Comentário enviado por ecr em 28/05/2005 - 11:56h

Cara ta show o seu artigo, é muito útil para comunidade.

Esclarece uma coisa, tem como eu configurar no dns para que ele acesse o servidor secundário de www somente se o primário não estiver ativo? Do jeito que foi implementado pelo que eu entendi ele divide o acesso entre os servidores, mas eu tenho a necessidade de acessar o servidor 2 apenas se o servidor 1 não estiver ativo.

[11] Comentário enviado por diego.ribas em 29/05/2005 - 20:26h

Valeu erc!
Mas com DNS não conheço nenhuma maneira de fazer isso que tu quer. E como foi implementado no artigo isso não se torna possível como bem lembraste. Algumas alternativas que me vem agora a cabeça é deixar um script rodando e verificar se teu primário tá ativo a cada minuto digamos. Se ele não estiver vc lanca o teu servidor web na maquina secundaria ou entao insere uma linha no teu servidor dns dizendo q agora quem responde por www é a outra máquina. Entendeu?
Espero ter te dado uma luz!
feito!

[12] Comentário enviado por jakjr em 30/01/2006 - 16:56h

Muito bom. Mas se meu site utiliza sessions ?? Compartilharia as sessions via NFS ?? Já testei isto e não ficou muito bom. Alguém tem alguma idéia ??

[13] Comentário enviado por removido em 25/06/2007 - 21:47h

Tá todo mundo dizendo que o artigo está isso e aquilo, está mesmo, mas porque a nota dele é 8. Falta de coerência de todos.
Parabéns diego, seu artigo está 10, pelo menos pra mim.

[14] Comentário enviado por krun em 02/09/2008 - 16:25h

Gostaria de saber se tem como fazer esse balanceamento de carga web usando iptables?

[15] Comentário enviado por paulogur em 27/10/2010 - 15:50h

Meus 2¢

Sei que o comment é antigo, mas para aqueles que pararem aqui como eu, até onde eu sei, o problema do erc até poderia ser resolvido com o iptables sem o uso do dns ;) ao invés de trocar a entrada no DNS, trocaria no iptables redirecionando o trafego direcionado a porta 80.

Para fazer o load balance com iptables, se houver nat, uma estratégia seria a seguinte:
iptables -t nat -A POSTROUTING -o eth0 -j SNAT -p tcp --dport 80 --to 1.2.3.1-1.2.3.4

[16] Comentário enviado por bruno_vidal_87 em 21/10/2011 - 19:12h

Legal mesmo isso é muito útil, mas assim o dns em round-robin ele apenas faria controle das conexões correto ? tipo, ele balancearia as solicitações de conexões e q tal utilizar um sistema inteligente de balanceamento de carga utilizando agentees ? esse sim balancearia a carga em utilização e tráfego, esse monitor deveria monitorar mem.ram , disco rigido e utilização de processamento.

To implementando isso, vamos ver ao término como se comporta ! E na frente destes servidores um servidor de pool e secundario do mesmo.. em caso de problemas.


Abraços a todos ! Caso houver alguma sugestão ! b.8.7@live.com <msn

[17] Comentário enviado por marlluslustosa em 23/06/2013 - 19:21h

Sei que o tópico é antigo, porém, acho que qualquer comentário vale.

Dúvida do ecr:
Esclarece uma coisa, tem como eu configurar no dns para que ele acesse o servidor secundário de www somente se o primário não estiver ativo? Do jeito que foi implementado pelo que eu entendi ele divide o acesso entre os servidores, mas eu tenho a necessidade de acessar o servidor 2 apenas se o servidor 1 não estiver ativo.

Você pode fazer isso utilizando HeartBeat (faz monitoramento de interfaces de rede reais e criação de uma única virtual) + mon (monitoramento de processos) + DRBD (ou rsync, para realizar a replicação de dados entre as máquinas).

Você montando um cenário com estes programas poderá colocar no registro A do DNS o nome do servidor para a interface virtual criada pelo HeartBeat, e este cuida do trabalho de procurar alguma máquina funcionando.

Agora, em relação ao tópico criado, na minha opinião, esse cenário só seria perfeito se eu tivesse um um webserver que não fosse atualizado constantemente (atualizações em banco de dados, etc.). E utilizar NFS para isso não é distribuir tráfego, pois, na verdade você estaria só descentralizando o acesso nas máquinas. A escrita seria em servidor NFS central.

Na minha opinião, seria interessante utilizar bancos de dados de forma distribuída. O que não é uma tarefa trivial hoje em dia.
OBS: Estou falando no objetivo de um cenário 100% funcional sem perca de dados.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts