Corrupção do banco de dados do Exchange 2013 com o evento 476 no ESE

Question

Estou tendo algumas corrupções de banco de dados aleatórias em nosso Exchange Server 2013 com o evento 476 no ESE. Esta é a quinta vez que isso acontece e a situação já é inaceitável. Aqui está uma captura de tela do Event Viewer com o incidente.

O procedimento de recuperação deve ser feito a partir de backups ou feito por eseutil /p , que é um procedimento com perdas, já que os logs também foram corrompidos.

Neste ponto, quero isolar o problema e descobrir qual dispositivo devo culpar. Este Exchange Server está sendo executado dentro de uma VM no vSphere 6.0. O VMDK é exportado por meio do iSCSI de um Dell Powervault MD3820i.

Devido à natureza do erro, parece ser um problema com o subsistema de armazenamento, mas como podemos investigar isso? Nas edições anteriores, o pessoal da DELL disse que estava tudo bem no armazenamento, mas não sei se os diagnósticos executados por eles são confiáveis o suficiente.

Agradecemos antecipadamente

EDITAR: Não há nenhum software antivírus instalado no servidor. O hardware host que executa o VMware vSphere 6.0 é um DELL PowerEdge R730 homologado pela DELL para executar o vSphere. Não há erros no VMware ou algo assim nos logs, ou pelo menos não consegui encontrar nenhum problema nos logs.

A comunicação de armazenamento é feita pelo iSCSI usando dois cabos Cat6 no modo multipath com controladores duplos no PowerVault MD3820i, por isso é uma configuração padrão e sabe trabalhar, e novamente, foi homologada pela DELL.

Eu sei que as coisas homologadas pela DELL não significam que é bom. Mas eles venderam o hardware e recomendaram suas melhores práticas, e seguimos todos eles.

EDIT II: O dispositivo de armazenamento PowerVault está executando o firmware mais recente da DELL, a versão 08_20_09_60 que é mais antiga do que a mais recente abordou um problema específico que leva à corrupção de dados: Endereçado uma condição rara que tem o potencial de causar uma falha no processador que pode resultar em um problema de integridade de dados

Sobre as placas de rede, estamos usando um Broadcom NetXtreme II BCM57810 10GbE. A placa não suporta o descarregamento do motor TCP e / ou o descarregamento iSCSI, portanto, isso não deve ser o problema.

O VMware também é executado com os drivers recomendados para os controladores SAS locais: o driver megaraid_sas em vez do deafault tg3 empacotado com o VMware. Eu não acho que este seja o problema, já que as VM's estão no Armazenamento iSCSI e não no armazenamento local.

    

Answer 1

Como se diz na descrição do erro do log de eventos, isso quase certamente será uma falha no hardware do sistema, que pode ser um conceito bastante nebuloso quando se fala de convidados virtuais.

Eu ficaria muito preocupado com o subsistema de armazenamento - Tendo em vista minhas recentes experiências com clusters virtuais criados em servidores Dell, suspeito de um problema com o firmware da placa de rede ou o firmware do sistema de armazenamento nessa ordem.

Depois de tomar uma xícara de chá e pensar, olhei novamente para o seu erro, você está recebendo um erro de 1019. Isto está dizendo especificamente que o servidor do Exchange foi para ler alguns dados no banco de dados que ele 'sabia' tinha sido escrito mas não conseguiu encontrá-lo (você leu link - os erros são discutidos aqui com algum detalhe).

Isso só pode ser corrupção de disco de algum tipo e a causa principal para isso é muito provável que seja um problema com o sistema de armazenamento, especialmente considerando que você mencionou isso já aconteceu antes.

Minha outra preocupação neste momento é que 1019 erros podem ser bastante insidiosos; pode ser o resultado final de uma gravação dando errado há algum tempo, não sendo detectada porque os dados não eram necessários por algum tempo. Restaurar o backup de ontem não ajudará se a corrupção ocorreu na semana passada, por exemplo.

Neste ponto, certamente entrarei em contato com a Dell e também com a Microsoft.

    

Answer 2

Com as informações limitadas sobre o ambiente em que está sendo executado, eu começaria verificando o seguinte.

Certifique-se de que o AV tenha as exclusões adequadas definidas para troca.

Verifique se os drivers para armazenamento e rede são as versões estáveis corretas para os dispositivos na outra extremidade.

procure outros eventos que precedam a falha.

Tente incluir mais informações sobre o hardware, tipo de servidor, mem, cpu, tipos de placa de rede e configuração (canal de porta, etc.)

observe seus logs do vsphere em busca de erros relacionados ao armazenamento.

    

Answer 3

Existem problemas no VMware 6 que podem corromper armazenamentos de troca (ou qualquer coisa ativa como um banco de dados). Existem problemas (relacionados?) Com o recurso CBT (Changed Block Tracking) usado pelo software de backup virtual como o Veeam. Pesquise contra esses tópicos e você encontrará outras pessoas com armazenamentos corruptos do Exchange. É um problema particularmente desagradável, pois depois que sua loja for corrompida, os erros do CBT podem ter tornado inutilizável TODOS os seus pontos de restauração de backup (inclusive fora do local). Pelo que entendi, a VMware tem um patch para evitar a corrupção do servidor em execução, mas, no momento desta publicação, não há uma correção para os problemas de CBT e os backups baseados em CBT do ESXi 6.0 não são confiáveis. FWIW - Eu tive uma boa experiência com as MD SANs da Dell. Eles não são extravagantes, mas eu tenho vários clientes executando-os e nunca tive um problema. Da mesma forma, tenho algumas prateleiras da Equallogic que são confiáveis. Claro, eu uso apenas recursos básicos de LUN, nada extravagante como instantâneos ou replicação; contando com a Veeam para isso.