[GTER] Uso intensivo de ksoftirq no Server U L-800+Red Hat+Quagga+VRRP Keepalived.

[Rafael Possamai]

Eu sei que nao eh uma opcao muito simples, mas muda pra FreeBSD e seja
feliz! Roteamento em Linux eh um saco. Pensa assim... os servidores que
rodam netflix sao baseados em FreeBSD... :)

2015-06-02 6:19 GMT-05:00 Kalil de A. Carvalho <kalilac at gmail.com>:

> Bom dia pessoal.
>
> Não sei se alguem já passou por isso mas estamos com um problema bastante
> estranho:
>
> Na empresa que trabalho temos um ServerU L-800 com 16GB de RAM rodando Red
> Hat 7.0, Quagga 0.99.22.4 (pacote da própria distribuição) e Keepalived
> servindo como nosso roteador de borda. Fechamos sessões BGP com três
> operadoras e recebemos rota full de todas elas.
> A mais ou menos três semanas identificamos que o serviço ksoftirq ficava
> com uso de 100% em um dos núcleos do nosso servidor e apesar de termos
> outros sete o desempenho era bastante afetado, nosso clientes reclamavam,
> nosso sistema de monitoramento mostrava uma queda de 60% no nosso consumo
> durante o problema.
> Como temos uma outra maquina exatamente igual, a outra ponta do VRRP,
> viramos o roteamento e reiniciamos a maquina. Com a normalização voltamos o
> serviço para a primeira e tudo ficou normal por aproximadamente cinco dias.
> Depois deste tempo o problema retornou.
> Desta vez ao foi tentado uma abordagem diferente: Paramos o Keepalived,
> forçando o roteamento a mudar, mas não reiniciamos o servidor. Depois de
> uns quarenta minutos o ksoftirq normalizou. E é este o caso que temos
> agora.
> O que quero chamar a atenção é que o nosso roteador secundário. o que esta
> rodando neste momento, esta com as mesmas configurações e não esta
> apresentando qualquer pico ou gargalo. Reafirmo que o problema ocorreu a
> umas três semanas atrás, sem nenhuma atualização.
> Buscando na Internet por problemas com VRRP achei apenas postagens antigas
> falando de problemas quanto a recebimento de arp ou bug na versão. Na nossa
> configuração não utilizamos multicast para consultas do Keepalived e sim
> unicast. Mesmo assim, se fosse bug ou arp storm acredito que o secundário
> também teria problema o que não é o caso.
> Abri chamado junto a Red Hat e me pediram para pegar os dados via comando
> perf durante o problema, o que foi feito. Eles alegam que o problema ocorre
> no momento de alguma mudança de vizinhança, já que tem um intensivo uso de
> processamento que pode estar causando isso tendo como suporte a esta teoria
> uma mudança em um dos nossos pares BGP.
> Respondi que é uma ação comum realizarmos reset nas vizinhanças e nunca
> tivemos nenhum problema, o que reforça esta minha certeza é que o servidor
> secundário tem as mesmas conexões que o primário, somente mudando os IP's
> mas sofrendo qualquer modificação que o primário passar já que as
> operadoras fornecem o mesmo caminho apenas com IP's secundarios nas
> conexões.
>
> Alguém já passou por uma situação como esta?
>
>
> --
> Atenciosamente,
> Kalil de A. Carvalho
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter