[GTER] Redundância entre Switchs (Era -Re: [caiu] Cloud Tecla Off)

[Shine]

Vc está correto. Apenas observe que nem todos switches em stack fazem isso,
por isso é importante vc checar se os switches aonde vc vai conectar seu
servidor suporta.
Mas falando especificamente de Linux... caso os switches não suportem a
funcionalidade acima ainda assim vc poderia usar soluções no kernel do
Linux como fazer bridging e usar STP para controlar o loop de camada 2.
A solução mais comum é utilizar redundância de camada 3 (por exemplo VRRP),
conforme apresentado anteriormente pelos colegas. Mas a melhor avaliação do
que aplicar vc tem q fazer conforme seu ambiente. Exemplificando, uma
solução conveniente para uma rede enterprise pode não ser aplicável a um
datacenter, outras são melhores para operadoras... e assim vai.

sd,
Edgar

Em 14 de fevereiro de 2012 09:55, Lista <lista.gter at gmail.com> escreveu:

> Então pelo que entendi, se eu tiver dois switchs fazendo Stacking, tipo sw1
> porta 1 e sw2 porta 1, e ativo o lacp em ambas as portas e conecto meu
> roteador em ambas eth1 na porta 1 sw1 e eth2 porta1 sw2, e ativo o
> bonding/lacp o switch e o roteador entederá que seria um unico equipamento,
> devido a eles estarem empilhado, ae sim teria uma redundância entre switchs
> via lacp/bonding (linux)?
> Essa seria uma solução mais usual, oq vocês costuma utilizar nesse aspecto?
>
> Em 13 de fevereiro de 2012 21:36, Rafael Ganascim <rganascim at gmail.com
> >escreveu:
>
> > Uma alternativa é ter duas placas de rede no servidor. Conectar cada
> > uma dessas placas em um switch diferente. Então, duas hipóteses:
> >
> > - ter dois switchs 'empilhados' (via stack) e fechar um link
> > aggregation - eu gosto desta;
> > - ter softwares como o Bacs da Broadcom, o lagg no FreeBSD no modo
> > failover, ou ainda um shell script,  que deixam você ter duas placas,
> > deixando uma em standby (sem aggregation)  - morreu uma ele assume a
> > outra
> >
> >
> > Em 13 de fevereiro de 2012 21:06, Lista <lista.gter at gmail.com> escreveu:
> > > Tá mas a VRRP, vai atuar como backup de um interface de um roteador ou
> > dele
> > > por inteiro, ou switch, a pergunta é um roteador está conectado no sw1,
> > via
> > > porta X, como fazer para caso esse sw1 caia um sw2 assuma?
> > >
> > > Em 13 de fevereiro de 2012 16:27, Henrique de Moraes Holschuh <
> > > henrique.holschuh at ima.sp.gov.br> escreveu:
> > >
> > >> On 13-02-2012 15:44, Lista wrote:
> > >>
> > >>> Caros colegas mais experiente no assunto, nesse caso como relato
> > >>> pelo Pina, como disponibilizar que um host(servidor, ou roteador)
> > >>> atrás de um switch fique redundante para o outro switch em caso de
> > >>> pane eletrica, queima de eqpto, ou problemas de "osmár"?
> > >>>
> > >>
> > >> Usando VRRP ou outro protocolo de alta-disponibilidade, só que..
> > >>
> > >>
> > >>  Uma análise já foi conduzida (aparentemente erro de configuração
> > >>>> no VRRP do switch) e um relatório será encaminhado para a Tecla em
> > >>>> até 48 horas. Após recebermos o relatório, os clientes receberão
> > >>>> uma cópia.
> > >>>>
> > >>>
> > >> ... precisa ter certeza que não trocou "osmár" por coisa pior.
> > >>
> > >> Aqui a regra é testar o fail-over em todas as janelas de manutenção:
> > >> VRRP e seus irmãos são todos notoriamente fáceis de configurar
> > >> incorretamente.  Quando não é o VRRP, é a spanning-tree, ou alguma
> > >> "feature" de segurança de equipamento de rede que atrapalha o
> fail-over
> > >> correto.
> > >>
> > >> --
> > >> Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
> > >> IM@ - Informática de Municípios Associados
> > >> Engenharia de Telecomunicações
> > >> TEL +55-19-3755-6555/CEL +55-19-9293-9464
> > >>
> > >> Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
> > >> e do custo que você pode evitar.
> > >>
> > >> --
> > >> gter list    https://eng.registro.br/**mailman/listinfo/gter<
> > 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
>