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.
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.
[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:
[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!
[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.
[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.