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

Lista lista.gter at gmail.com
Wed Feb 15 09:36:12 -02 2012


Entendi Shine, e a todos obrigado pelos esclarecimento.
PS:Teria algum switch que vocês conheçam que suporte essa feature em cima
de stack?

Em 14 de fevereiro de 2012 23:46, Shine <eshine at gmail.com> escreveu:

> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list