[GTER] Configuração de strong x weak host model para servidores

[Rafael Possamai]

Entendi agora, interessante o problema. Quando implementar, seria legal se
postasse na lista um update de como foi.


2014-10-05 15:24 GMT-05:00 Carlos Ribeiro <cribeiro at telbrax.com.br>:

> Rafael,
>
> Na verdade são muitos serviços rodando, mas a maioria deles se trata de
> "sistemas legados" que não operam em "cluster" com um servidor em BH e
> outro em SP (como é comum em soluções que foram desenhadas desde o começo
> para operar em alta disponibilidade). Existe uma imagem virtual única
> rodando em um site e sendo replicada no storage do outro lado. Esses
> sistemas teriam que ser reescritos, ou então, teria que haver um
> investimento muito mais alto na solução de virtualização, que não é viável
> no momento.
>
> O jeito mais simples de resolver é mantendo o site de SP em modo "standby",
> sem nenhum acesso entrando por lá. Assim tudo vem para BH sempre. Se o site
> de BH falhar a réplica assume em SP. É assim que a maioria desses sistemas
> funciona. Mas há o desejo de dar maior disponibilidade permitindo acesso
> pelos dois links simultaneamente.
>
> De todo modo, como havia falado, há outras opções, e eu acabei trazendo
> essa para discutir porque achei que era um tema interessante :-) Não quer
> dizer que será adotada. Mas acho que vale a pena investigar.
>
> *Carlos Ribeiro*
> *Sócio*
> Cel: +55 (31) 9303-3366
> Tel: +55 (31) 3305-5620
> Geral: +55 (31) 3305-5600
> cribeiro at telbrax.com.br
> www.telbrax.com.br
>
> Em 5 de outubro de 2014 15:51, Rafael Possamai <rafael at gav.ufsc.br>
> escreveu:
>
> > A diferenca de acesso via SP e BH eh tao diferente? Se o conteudo do
> > servidor for exatamente o mesmo, round robin ou load balancer pode
> > funcionar sem ter que perder os cabelos redesenhando L2 e/ou L3. Talvez
> eu
> > esteja simplificando de mais, mas por experiencia propria, as vezes vale
> a
> > pena.
> >
> > 2014-10-05 13:19 GMT-05:00 Carlos Ribeiro <cribeiro at telbrax.com.br>:
> >
> > > Uma observação curiosa: ao estudar essa questão do "weak host model" no
> > > Linux, acabei entendendo melhor algumas coisas que eu nunca tinha
> > entendido
> > > na arquitetura do iptables. As consequências dessa escolha de
> arquitetura
> > > são bem pervasivas na implementação da pilha TCP/IP.
> > >
> > > *Carlos Ribeiro*
> > > *Sócio*
> > > Cel: +55 (31) 9303-3366
> > > Tel: +55 (31) 3305-5620
> > > Geral: +55 (31) 3305-5600
> > > cribeiro at telbrax.com.br
> > > www.telbrax.com.br
> > >
> > > Em 5 de outubro de 2014 15:18, Carlos Ribeiro <cribeiro at telbrax.com.br
> >
> > > escreveu:
> > >
> > > > Rubens,
> > > >
> > > > É mais ou menos isso mesmo. A receita de bolo é mais ou menos essa:
> > > >
> > > > 1) Configuração básica
> > > >
> > > > eth0: 172.19.0.200
> > > > eth1: 172.27.0.200
> > > > Rota default: 172.19.0.1 (via eth0)
> > > >
> > > > 2) Política de roteamento
> > > >
> > > > A rede 172.19.0.0/24 atende o tráfego recebido em BH
> > > > A rede 172.27.0.0/24 atende o tráfego recebido em SP
> > > >
> > > > (Desse jeito, um único servidor - esteja em BH ou em SP - pode
> > responder
> > > > requests recebidos por qualquer um dos dois lados da rede e irá
> > devolver
> > > > para o firewall correto).
> > > >
> > > > 3) Criar uma nova tabela de roteamento
> > > >
> > > > echo 200 upstreamsp >> /etc/iproute2/rt_tables
> > > >
> > > > 3) Criar regras de "source routing" associadas ao tráfego originado
> do
> > IP
> > > > 172.27.0.200
> > > >
> > > > ip rule add from 172.27.0.200 lookup upstreamsp
> > > > ip route add default via 172.27.0.1 dev eth1 table upstreamsp
> > > >
> > > > 4) Salvar a configuração de forma persistente
> > > >
> > > > post-up ip rule from 172.27.0.200 lookup upstreamsp
> > > > post-up ip route add default via 172.27.0.1 dev eth1 table upstreamsp
> > > >
> > > > *Carlos Ribeiro*
> > > > *Sócio*
> > > > Cel: +55 (31) 9303-3366
> > > > Tel: +55 (31) 3305-5620
> > > > Geral: +55 (31) 3305-5600
> > > > cribeiro at telbrax.com.br
> > > > www.telbrax.com.br
> > > >
> > > > Em 4 de outubro de 2014 20:15, Rubens Kuhl <rubensk at gmail.com>
> > escreveu:
> > > >
> > > > 2014-10-04 19:22 GMT-03:00 Carlos Ribeiro <cribeiro at telbrax.com.br>:
> > > >>
> > > >> > Rubens,
> > > >> >
> > > >> > Tem outro jeito de fazer isso, criando duas tabelas de roteamento
> e
> > > >> > associando rotas default diferentes para cada interface. Peguei um
> > > >> exemplo
> > > >> > hoje e vou testar durante a semana. Estou fora de casa, chegando
> > mais
> > > >> tarde
> > > >> > eu posto aqui.
> > > >> >
> > > >>
> > > >> Para quem só sabe usar martelo, todo problema é um prego...
> iptables é
> > > >> parte da zona de conforto, mas mesmo com iptables precisa de duas
> > > tabelas
> > > >> de roteamento. O que você deve estar citando é fazer source-routing
> > > direto
> > > >> no "ip rule", que de fato funciona também, e já usei uma vez.
> > > >>
> > > >>
> > > >> Rubens
> > > >> --
> > > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >>
> > > >
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>