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: 32.861 ]

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

Simples sistema de backup com acesso remoto

O comando tput

Aprendendo a melhorar os seus scripts

Apresentando o Yad - "zenity melhorado"

Criando Autoridades Certificadores e Certificados de Testes no Linux

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