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

[Carlos Ribeiro]

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
>