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

[Shine]

A maioria dos fabricantes tem isso em seus switches high end e alguns em
switches stackable mais modulares (e baratos). Cisco, Juniper, H3C,
Brocade, Allied, Force10, Extreme. É pra todos os gostos e bolsos.
O que vai pontuar a escolha é a necessidade de cada projeto (e o budget
dele ;) ).

sd,
Shine

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

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