Hoje vou relatar um caso que me defrontei recentemente envolvendo o Microsoft Cluster Services, um sistema de Storage iSCSI e as configurações de Jumbo Frame nas placas de rede iSCSI.
Um de nossos clientes reclamou que durante a execução do Backup o servidor do cluster tornava-se insuportavelmente lento e esta lentidão persistia até que o mesmo travasse. Como ele está em um processo de migração, onde está trabalhando com apenas um único nó ativo no cluster, o serviço se tornava indisponível para todos os usuários e adicionalmente ele estava sem o Backup.
Como ele utiliza a avançada solução de Backup Dell DL1000 o primeiro passo que executei foi uma verificação na ferramenta de Backup, notei que além de uma performance muito baixa o backup não se completou após algum tempo, indicando como erro uma desconexão do host, como pode ser observado na figura abaixo. O volume do cluster de 1,92TB não estava sendo protegido. Em um primeiro momento atualizei a solução de Backup e o agente presente no cluster e o problema persistia.
Continuando a análise, percebi que os discos locais eram protegidos pelo Backup sem qualquer anormalidade, indicando que o problema não seria de fato na solução de Backup, mas sim algo relacionado aos volumes do cluster. A Storage não indicava qualquer anormalidade no funcionamento. Durante à noite, remotamente acompanhei a execução do Backup e o servidor travou e reiniciou, na sequencia comecei a análise pelos “log’s” do Windows, no primeiro momento notei que existiam vários erros tendo como a origem iScsiPrt e MsiSCSI como pode ser observado nas imagens abaixo:
Na sequencia podemos encontrar no log (imagem abaixo) o momento em que a máquina reiniciou e foi gerado um despejo de memória, usualmente quando isso ocorre temos um travamento com tela azul (a famosa BSOD ou “Blue Screen of Death”), também é comum que seja gerado um despejo de memória resumido conhecido como MiniDump.
Como estava conectado remotamente e necessitava descobrir a causa do problema, optei por realizar uma análise no MiniDump (copiei ele para realizar a análise localmente, este tipo de arquivo geralmente possui menos que 512 Kb).
Para analisar arquivos de despejo do Windows, uma boa opção é o uso do WinDBG, para facilitar a análise com informações preciosas, recomendo fortemente que sejam utilizados os símbolos públicos da Microsoft (http://msdl.microsoft.com/download/symbols). Abrindo o arquivo no WinDBG, ao invés de executar diversos comandos de depuração, basta executar apenas um único: !analyze –v , se observarmos na imagem abaixo, logo após a execução do comando, já temos uma indicação de qual a origem da falha e o motivo.
Como podemos observar na imagem acima, temos um timeout na função “WatchdogSourceClussvcIsAlive” e este timeout está relacionado a espera pelo recurso “PhysicalDisk”, como identifiquei que o problema era no disco e somente nos discos disponibilizados pela Storage, verifiquei as configurações do “Iniciador iSCSI” e do “MPIO” (Multipath I/O), como aparentemente tudo estava OK, conferi as placas de rede. Na análise das placas de rede, encontrei a configuração de Jumbo Frames ativada, como pode ser observado na imagem abaixo:
Realizei um teste desabilitando o Jumbo Frames, para isto alterei “MTU” para 1500 (conforme a especificação IEEE 802.3 que define o Ethernet). Com este ajuste o problema desapareceu, o que é estranho, pois geralmente a configuração de Jumbo Frames proporciona uma melhora de performance na casa de 20 a 30% em SAN’s (Storage Area Network) iSCSI.
A Infomach é uma parceira Veeam altamente especializada, com preços acessíveis e disponível para cuidar do seu backup para você, com suporte 24 horas, 7 dias por semana. As soluções de backup da Veeam são simples, flexíveis e confiáveis, de modo que os dados da sua empresa estarão sempre protegidos e disponíveis. Clique no banner e saiba mais!
