sábado, 9 de janeiro de 2010

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

Introdução

Esse artigo tem o objetivo de ensinar ao leitor como implantar um sistema de balanceamento de carga e replicação de servidores web utilizando os softwares mais comuns no mundoLinux, como o servidor web Apache e o servidor DNS Bind. 

Esse artigo abordará o exemplo específico de replicação e balanceamento de servidores web. Mas nada impede a implantação desse sistema para outros tipos de serviços. É sugerido que o leitor tenha um conhecimento básico de DNS (preferencialmente BIND). 

O problema


Suponhamos que eu possua um servidor web rodando em uma máquina relativamente boa, mas o número de requisições em meu servidor aumentam muito mês à mês, pois minhaempresa disponibilizou um sistema via web para que os clientes façam pedidos, consultem e tudo mais. 

Minha empresa está crescendo assim como o número de acessos ao meu servidor e sua importância de estar sempre on-line. Mas o problema é que meu servidor não está aguentando mais a carga de requisições e muitas vezes preciso fazer manutenção no mesmo, deixando todo sistema "fora do ar". 

Além disso, hoje na minha empresa "exemplo" a importância do meu serviço estar sempre no ar é muito maior. Porque eu estou perdendo dinheiro e credibilidade cada vez que o serviço está fora. 

Além de tudo isso, não estou afim de jogar fora o meu servidor e comprar um ainda mais caro. Quero poder reutilizar o que eu possuo e comprar outro igual, porque sai mais barato pra mim. E quando um servidor sair fora do ar, quero que automaticamente o outro entre em ação e aceite todas as requisições automaticamente! 

E pior de tudo... não quero pagar caro e nem gastar muito tempo para implantação de um sistema que me permita tudo isso! 

 



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. 

Conclusão





O uso do DNS (round robin) para replicação/balanceamento é extremamente simples e fácil de implementar. Além disso eu não preciso usar um middleware (stub ou proxy) para a distribuição do processamento (balanceamento), o que torna ainda mais simples de configurar, além de eliminar esse ponto único de falha que pode ser o middleware (se eu tiver apenas um). 

Espero ter ajudado alguém com esse artigo e espero principalmente, o contato de pessoas que realmente implementaram algo parecido em um sistema real para compartilharmos experiências e novas novidades nesse tipo de replicação/balanceamento. 

0 comentários :

Enviar um comentário