O BIG-IP pode apresentar um comportamento inesperado, resultando no reboot ou chaveamento do equipamento caso esteja utilizando versões antigas. Ao analisar os Logs do LTM e mcpd, observamos o evento “release all rows before calling tmstat_dealloc”, logs de parity error e problemas com o processo bcm56xxd. Este artigo demonstra uma solução de contorno para este problema.
Observamos que alertas podem ocorrer por vários fatores. Visando auxiliar na monitoração de um BIG-IP, este artigo busca demonstrar como solucionar em eventos onde são gerados grandes arquivos de LOG gerados devido ao chaveamento de tráfego e alguns erros de processos.
Observa-se que o BIG-IP possui um mecanismo de monitoramento de seu hardware, software e tráfego de dados. Os eventos que ocorrem são armazenados por meio de LOGs e divididos em categorias, como LTM, GTM, Packet Filter, Audit entre outros.
Depois de um longo período de monitoramento de um BIG-IP, notamos que o desempenho do sistema pode ser degradado e, eventualmente, ficar sem resposta ou reiniciar devido a exaustão de memória.
Referente ao reboot do equipamento podemos identificar a ocorrência de registro de log de erro no diretório /var/tmp/mcpd.out.
Analise o arquivo em por estes comandos:
- cd /var/tmp
- cat mcpd.out
Imagem 1: /var/tmp/mcpd.out
Este é um BUG do balanceador, no qual a versão atual do equipamento apresenta bug de memory leak para o processo MCPD. Este após um longo período de tempo, o processo MCPD pode apresentar restart culminando num possível chaveamento do tráfego para o equipamento standby.
Como resultado desse problema, além do reboot inesperado do sistema e do registro de mensagens no arquivo /var/tmp/mcpd.out, você pode perceber um aumento progressivo na quantidade de memória que o processo MCPD utiliza.
Imagem 2: LOG LTM
Em nossas análises sobre os ambientes, este chaveamento se dá basicamente em equipamentos que estão assistidos por apenas uma lâmina (física ou virtual). Equipamentos com duas ou mais lâminas em seus slots possuem maior redundância, fato que apresenta menor probabilidade de chaveamento.
Outro ponto a salientar é de que, neste exemplo, o problema passou a se manifestar após aproximadamente 419 dias de uptime do equipamento.
Imagem 3: uptime
Também observe se é gerado o LOG com o processo Bcm56xxd. Este processo está relacionado à falha no driver switch (bcm56xxd) do sistema BIGIP. No exemplo abaixo, o balanceador esta na versão 11.5.1 HF7.
Imagem 4: Configuração
Em suma, o problema pode causar interrupções no tráfego na rede balanceada. O fabricante já mapeou o problema e os detalhes podem ser visto no ticket SOL17306.
Imagem 5: Processo bcm56xxd
Outra verificação que podemos realizar é entre o balanceador e switch validando a conectividade de camadas 1 e 2 entre os equipamentos. Garanta que não encontre divergências nas configurações do balanceador conforme descrido no SOL13142.
Como ação paliativa sugerimos um reboot do equipamento que está apresentando as logs na intenção de restartar o processo “bcm56xxd”. Para esta ação é necessário realizar o backup dos elementos e o chaveamento do tráfego para o equipamento standby.
Caso encontre o log de Parity Error, isto pode causar interrupções no tráfego de rede e lentidão na comunicação. A causa provável do evento está relacionada ao impacto reportado no bug SOL17306 / SOL15888: The bcm56xxd process may restart due to parity errors. Recomenda-se chavear o tráfego para o outro membro e reiniciar o sistema.
Imagem 6: parity error
Por ser um problema conhecido e um “BUG de versão”, a correção para o problema, indicada pelo fabricante, seria a atualização do equipamento para a versão 11.5.2 ou superior.
Referencia:
https://support.f5.com/kb/en-us/solutions/public/16000/100/sol16166.html?sr=50516019
https://support.f5.com/kb/en-us/solutions/public/15000/800/sol15888.html
https://support.f5.com/kb/en-us/solutions/public/17000/300/sol17306.html
Conclui-se que a monitoração é uma ferramenta imprenssindível em qualquer sistema. Entretanto temos que saber como proceder quando um evento ocorrer.
Um evento pode alertar sobre um problema de fonte, reboot do sistema, alto consumo de CPU, entre outros.
No caso deste artigo, conseguimos aprender como lidar caso ocorra um reboot inesperado do sistema e vários LOGs sejam gerados, informando “release all rows before calling tmstat_dealloc” no arquivo /var/tmp/mcpd.out, parity error no LTM, entre outros. Porém a F5 recomenda uma atualização de versão para resolver este BUG.