http://travaux.ovh.com/?do=details&id=4440
Boa noite,
Para o datacenter Roubaix 2, decidimos implementar a rede
com um objectivo de 100% de disponibilidade. Para isso, vamos
utilizar os switchs Cisco 6509 na configuração VSS. Trata-se de um
sistema baseado em 2 chassis que funcionam como 1 só. Com 2
chassis tudo é multiplicado por 2, e então deveremos ter 100% de
disponibilidade.
No mundo real, temos vários problemas com os VSS que provocam
cortes no serviço e não preenchemos o contrato inicial. A base, temos
um problema crónico no BGP. A menor alteração de painel de roteamento,
o CPU do routeur está à 100% durante 15 minutos no mínimo. Não é grave.
Mas no final de 2009, implementamos protecções fortes na rede interna que
consistem em isolar cada servidor um do outro. Realizamos-o a través de vlan
privado e da implementação de um proxy arp. Muito standard como solução. O
routeur responde no lugar de todos os servidores e garante o roteamento mesmo
no vlan. Tudo é então muito seguro. No entanto, o routeur deve responder a todos
os pedidos de MAC de todos os servidores e o processo que gere no VSS pega
muito CPU.
Em tempo normal tudo isto funciona sem problema. Mas basta que a rede recalcula
os painéis de roteamento para que o BGP tome 100% do CPU e impeça o processo
MAC de funcionar. A consequência: os servidores não reconhecem os MAC e há um
corte no serviço durante 1, 3, ou 8 minutos, conforme a importância do recalculo
dos BGP.
Pensamos fixar o problema BGP com routeurs específicos que só vão fazer
isso. Route reflector. Normalmente deveríamos receber o material este mês
mas a encomenda foi mal registada entre o distribuidor e o fabricante... e
vamos finalmente recebê-lo miados de Setembro... Decidimos não esperar mais
por esta entrega, e implementar uma solução este fim de semana.
Mas vamos continuar a ter um problema de MAC. Decidimos então partir a
configuração VSS e repartir no que sempre funcionou bem : o routeur num
único chassis. Temos cerca de 30 routeurs na configuração mono chassis
que não criam nenhum problema. É apenas na configuração dupla chassis
que temos problemas. Vamos então partir os chassis.
Então a partir da última semana, vamos efectuar as alterações nos VSS
afim de passar para uma configuração baseada num único chassis.
Vamos proceder em 4 etapas:
- todos os links do datacenter ligados no chassis 2 serão novamente
ligados ao chassis 1. Sem corte no serviço porque tudo irá funcionar
no chassis 1.
- todos os links para Internet ligados ao chassis 2 serão novamente
ligados ao chassis 1. Sem corte no serviço porque tudo irá funcionar
no chassis 1.
- corte electrico do chassis 2. Sem corte no serviço porque o chassis
2 não será utilizado.
- mudança da configuração do chassis 1 para a versão mono chassis.
Ai será preciso reiniciar o routeur em hard. E então será preciso contar
15 minutos de corte no serviço. Vamos proceder por volta das 4 horas
da manhã no final da próxima semana se avançamos bem.
Vamos num primeiro tempo tratar do vss-2 problemático.
Normalmente, no máximo na etapa 4, não teremos mais nenhum problema
BGP. É possível que a través das configurações sobre 2 chassis este
problema possa ser resolvido a partir da etapa 3 ver 2, porque tudo
funcionará num único chassis. Mas não temos a certeza. Em todos os
casos no fim da etapa 4 tudo estará resolvido.
E como o BGP será fixado, pensamos que é provável que os problemas
de MAC também o sejam. Se o BGP não funciona em condições em
duplo chassis, então talvez outros processos tambémnão funcionem bem
em duplo chassis? Também vamos ver isso.
Lamentamos todos estes pequenos cortes que os clientes de Roubaix
2 sofreram ultimamente que são principalmente devidas aos problemas
descritos aqui. A escolha errada no material que assumimos plenamente.
Pensávamos que o fabricante ia resolver os problemas de CPU mas conforme
o que nos indica é normal. Este material é então incompatível com as nossas
necessidades. Vamos trocá-lo. Gerimos mal a situação e não devíamos ter
pedido ajuda ao fabricante mas agira logo para encontrar simplesmente uma
solução. Erro na gestão de problema.
Para continuar na transparência, talvez notaram os problemas
em Londres, Amesterdão e Frankfurt há cerca de 14 dias.
Pois, adicionamos links de protecção nessa altura. Entre Londres/Amesterdão
e Paris/Frankfurt. Investimentos consequentes foram decididos para tornar
a backbone totalmente segura e 100% disponível mesmo em caso de problema
na fibra óptica. O facto de adicionar estes link nos routeurs, provocou a
saturação da RAM disponível de routeurs e o crash de Londres. Isto teve
na mesma ocasião consequência em Amesterdão e Frankfurt pelos mesmos
motivos. Quem diz crash de routeurs, diz recalculo de BGP e então 100% do
CPU nos vss ... eis a razão de estes crashs que tiveram por consequência o
serviço em Roubaix 2 Resolvemos o problema desactivando o MPLS que
não é necessário mas ocupa 20% da RAM. Desde então está estável.
Pensávamos substituir todos os routeurs durante as férias, mas o material
que desejamos implementar não está disponível o que está disponível
não funciona. Pois, recebemos o novo Cisco Nexus 7000 e o BGP não
funciona mas gera mensagens de erro... Material novo e pronto...
Escolha errada do material mais uma vez. E então grande analise de
nós mesmo em perspectiva... No entanto vai gerar também atrasos
nas substituições de routeurs previstas. Por isso actualmente apertamos
as mão a todos os fabricantes do mercado para ver o que vamos
implementar no lugar do que tínhamos previsto. Trabalho imprevisto
que irá provocar atraso noutros projectos...
Pronto ...
Acho que não posso ser mais transparente a cerca destes últimos
eventos.
Amigavelmente,
Octave
