Alta disponibilidade de links

chroot

Neste artigo venho compartilhar a minha experiência e desespero quando precisei criar um sistema de alta disponibilidade de links em ambiente Linux numa Sexta-feira às 5:30 da tarde. Acredito que muitos já passaram por isso. Obtive sucesso com a minha solução e espero que este artigo ajude muitas pessoas contribuindo ainda mais com a comunidade.

[ Hits: 33.237 ]

Por: Bruno em 16/11/2004

0 0

Denuncie Favoritos Indicar Impressora

Ambiente

O cliente possui 2 links, o primeiro é uma LP de 256 Kbps e o segundo é um Speedy Empresarial.

					
	Link 1 (Principal) LP = 200.232.63.203 
				GW = 200.232.63.201
				IFACE = ETH0

	Link 2 (Secundário/Speedy)IP = 200.207.207.91
				 GW = 200.207.207.65
				 IFACE = ETH2

Basicamente a idéia é que se o primeiro link cair, o outro assume, então a partir disto fui tentar achar algo na internet, mas nada do que eu achei me ajudou, ou era complicado demais para a solução que eu queria.

Então resolvi colocar a mão na massa e escrever um shell script com regex que resolvesse o meu problema.

A minha dúvida era como eu faria se o link secundário entrasse em ação após a queda do link primário e se o link primário voltasse a responder após alguns minutos, que ele voltasse a ser o link principal como antes, além disso, colocando as regras de MASQUERADE para cada interface de rede, toda vez que uma assumia o posto.

A solução foi trabalhar com rotas, manter a interface eth2 (link secundário) up sempre e fazer um script que ficasse pingando o gateway da LP (link principal) e não o próprio ip da eth0, isto é obvio, pois ele sempre irá conseguir pingar ele mesmo.

Se o gateway da LP (200.232.63.201) parar de responder, o script automaticamente apaga a rota default da LP e adiciona o ip do gateway da Speedy como rota default e finalmente adiciona a regras de MASQUERADE para todos na interface eth2 que agora se torna a principal.

Coloquei no crontab para este script rodar de 5 em 5 minutos, se o link principal voltar a responder, o script vai conseguir pingar a vai entrar em ação, deletando as rotas correspondentes ao link secundário e também as regras de POSTROUTING que estavam ativas na eth2, colocando a eth0 "LP" como link principal novamente.

Página anterior Próxima página

Páginas do artigo

   1. Introdução
   2. Ambiente
   3. Implantação

Outros artigos deste autor

POP3 gateway com fetchmail

Detectando possíveis trojans e lkms em seu servidor

Leitura recomendada

Monitoramento de pops para provedores

Ingressando estações de trabalho Ubuntu no AD com Closed In Directory

Gerar músicas aleatórias com YAD (Modo Gráfico)

Receba seu IP externo via e-mail ou ensine o bash a ler e enviar e-mails

Como programar backup com rsync e cron de maneira rápida e simples

Comentários

[1] Comentário enviado por fabio em 16/11/2004 - 00:04h

Bruno, muito bom seu artigo, com certeza será útil para muito. Bela sacada! Já foi pra pastinha de favoritos da minha conta aqui no VOL :)

[]'s

0 0

[2] Comentário enviado por pop_lamen em 16/11/2004 - 01:25h

Amigo, bem legal,
mas eu acho q faltou um IF aih, se a LP estivesse down, mas o speedy ja configurado, então ele deveria sair:

echo "verifica se existe rota da LP, se existir deleta"
if route -n | grep $LPGW > /dev/null; then
route del default gw $LPGW > /dev/null

fi
#agora vamos checar se o gw ja nao eh speedy
if if route -n | grep $SPEEDY > /dev/null ;then
#se for sai, se não continua
echo "Speedy ja ativado"
exit 0
else
echo "adiciono a rota default da speedy"
route add default gw $SPEEDY > /dev/null
echo "rota adicionada"
$IPTABLES -t nat -D POSTROUTING 1 > /dev/null
$IPTABLES -t nat -A POSTROUTING -i eth2 -j MASQUERADE > /dev/null
echo "regras de firewall adicionadas"

fi
#acionamos um ultimo
fi
done

--------------
Além disso serial legal implementar funções, a asism chama-las com um loop infinito, pausando, podendo assim, checar tudo de tempo em tempo.

0 0

[3] Comentário enviado por silvioreis em 16/11/2004 - 03:41h

Bruno,

A proposta é boa, mas a sua implementação precisa melhorar, essas soluções de coisas no cron monitorando de tempos em tempos são horriveis.

Estou trabalhando no mesmo problema e não vejo como fugir do iproute2 + "alguma coisa".

O problema link dedicado com ip fixo e link adsl com ip dinamico parece não ser muito facil de resolver de maneira simples, ou seja, sem precisar aplicar patches de kernel.

Pq vc desistiu do iproute2 ?

0 0

[4] Comentário enviado por naoexistemais em 16/11/2004 - 05:28h

Bruno,

Esse artigo posso considerar o melhor que já vi aqui no VOL, parabens.......

Falou,

0 0

[5] Comentário enviado por y2h4ck em 16/11/2004 - 10:11h

Ae Bruno sup3r hax0r b1g b33r eheheh
Mandou bem no artigo.

Demorou mais saiu aheheheh

[]s brow.

Spawn

0 0

[6] Comentário enviado por chroot em 16/11/2004 - 10:18h

Obrigado pela forca galera, deixando claro que a solução esta aberta para criticas e opiniões, pois o objetivo é que juntos, consigamos tornar a solução a melhor possivel, então mãos a obra e ajudem a comunidade ;)

ps : humildade sempre

0 0

[7] Comentário enviado por wronieri em 16/11/2004 - 21:06h

Muito bom seu artigo Bruno estou tentando fazer este tipo de esquema mas com heartbeat vc nunca tentou usar este esquema?

Parabéns ;-)

0 0

[8] Comentário enviado por removido em 17/11/2004 - 15:48h

Excelente material...
Parabéns!!!!!!!!!!!!

0 0

[9] Comentário enviado por uxhsilva em 23/05/2006 - 16:08h

Parabens !!

0 0

[10] Comentário enviado por removido em 14/11/2006 - 09:38h

bonding \o/

0 0

[11] Comentário enviado por andrelopes.mrx em 26/12/2009 - 16:52h

Eu achei precário, que a inteligência fique num script agendado no cron, pense nisso: mantenha rota para os 2 gateways de saída para a internet, sendo a saída pelo link secundário com uma metrica pior.

Em ambientes BSD, você pode monitorar as interfaces de maneira eficiente com ifstated, mas creio que para o seu cenário nem isso seja necessário.

Espero ter contribuído com alguma idéia.

André Gustavo
blog: http://blog.mrx.com.br
gtalk: andre@mrx.com.br

0 0