Infelizmente, parece que não conseguimos chegar ao fundo da aplicação, mas para obter algum algum valor deste incidente, quis criar uma resposta de referência. Isso é centralizado no gerenciamento de VMware e camada virtual. Muitos administradores estão segregados e não conseguem acesso de convidado ou armazenamento rapidamente, e isso é para eles :)
Olink parece ser a melhor correspondência para uma aplicação real, que @MosheKatz encontrou.
Se isso acontecer no futuro, a investigação deve ser assim:
- Você percebe algumas mas nem todas as VMs falharam. Você suspeita que isso é devido a um problema de armazenamento (como geralmente a causa mais provável)
- Primeiro, tente isolar um fator comum. Todas as VMs com falhas compartilham o mesmo armazenamento de dados? Neste caso eles estavam, mas algumas máquinas estavam ok, então descartamos problemas óbvios de hardware.
- Verifique todas as VMs quebradas para ver se havia um fator comum (hora, função etc.). Neste caso não houve.
-
Verifique se há outros eventos incomuns. Algo levantou uma bandeira aqui:
-
- O armazenamento NFS era thin-backed (no nível da matriz). Isso significa que, embora ex. 200GB é apresentado para os hosts ESXi, na verdade, apenas 100GB estão disponíveis. Apenas a matriz tem esse conhecimento no entanto. O que descobrimos foi que várias VMs foram pausadas porque ficaram sem espaço em disco. Embora essa possa ter sido a causa raiz, nossa primeira ação foi alocar mais armazenamento no back-end, para remover isso como um problema.
-
Depois que isso foi resolvido (uma simples alteração na interface do usuário) e as VMs pausadas foram reiniciadas com sucesso, voltamos ao problema original. Montamos os discos virtuais das VMs quebradas para uma VM funcional e vimos que não havia nenhuma tabela de partição nos discos. Nós não tínhamos um visualizador de hexadecimais disponível, então tivemos que assumir que os discos estavam vazios.
-
O sistema de monitoramento alertou para uma nova VM que não respondia. Isso foi ótimo, já que uma carga de VMs tinha minutos antes de ter se tornado insatisfatória devido ao problema de espaço em disco, portanto, o fato desta nova VM ter sido encontrada rapidamente foi um sinal de boa administração de monitoramento.
-
Abrimos um console, verificamos o convidado e vimos a captura de tela acima.
-
- Nesse estágio, fui até a sala de bate-papo de falhas do servidor para ver se o programa poderia ser identificado, enquanto meu colega de armazenamento verificava todos os logs e eventos da camada virtual para garantir que não houvesse nenhuma operação de armazenamento em execução.
- O que deveríamos ter feito era suspender a VM, permitir que o arquivo de suspensão fosse escrito e analisar o despejo para ver se o programa em execução poderia ser identificado. Suspenda a VM no PDF principal VMware KB
No final do dia, sabíamos e ferramentas de infraestrutura virtual não teriam sido relatadas dentro de um convidado como o acima estava fazendo. Poderíamos ver que não havia ISO montado e nenhum evento registrado na VM. Poderíamos ver que a VM não era "hard power cycled", apenas uma reinicialização suave (isso é invisível para a infraestrutura subjacente). Sabíamos que não era o lado do armazenamento, já havíamos decidido isso. Suspeitamos que não fosse automatizado, pois estava acontecendo ao longo de algumas horas em VMs específicas. Nós achamos que não era malicioso, porque o console reportaria o Disk Wipe se fosse :)
Então, a conclusão foi uma limpeza de disco iniciada pelo usuário. Até onde minha investigação foi, mas espero que você tenha achado útil.
Lições aprendidas:
- Backup e teste suas restaurações
- Certifique-se de que todos os usuários, usuários particulares de administração, saibam que estão trabalhando em um ambiente thin provisioned e evite qualquer coisa como formatação de disco de write-out (ou seja, gravar cargas de 1s
- Tenha um bom sistema de monitoramento em vigor.
- E um novo para mim: em qualquer ambiente virtual grande, tenha uma VM pronta para as ferramentas, mesmo desligada, com as ferramentas de diagnóstico instaladas; desempenho, armazenamento de rede. Se isso estivesse disponível, poderíamos ter montado e executado um dump hexadecimal no disco danificado para ver se estava realmente vazio ou se faltava apenas um mbr. Poderíamos também ter visto se foi escrito com 1's.