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

[Juliano Primavesi | KingHost]

Concordo plenamente.

Em 14/02/12 09:55, Lista 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