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

[Juliano Primavesi | KingHost]

F10 S55 e Dell 62XX fazem isso.

Juliano

Em 14/02/12 23:46, Shine 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