Avaliando erros ECC incorrigíveis e métodos de fallback

5

Eu corri um servidor que acaba de experimentar um erro que eu não encontrei antes. Ele emitiu alguns bipes, reiniciou e ficou preso na tela de inicialização (a parte em que o BIOS mostra seu logotipo e começa a listar informações) com o erro:

Node0: DRAM uncorrectable ECC Error

Node1: HT Link SYNC Error

Após uma reinicialização a frio, o sistema inicializou bem e ainda não relatou nada sobre o edac-util.

Minha pesquisa me diz que, mesmo com a memória ECC e um sistema em condições ideais, um erro incorrigível ainda é possível e, provavelmente, provavelmente ocorrerá durante a vida útil do sistema em algum momento; alguns relatórios sugerem pelo menos uma vez por ano ou antes.

O servidor executa o CentOS 6.5 com vários módulos ECC. Eu já estou no processo de tentar diagnosticar qual módulo jogou o erro para fazer uma avaliação se isso é uma falha ou o resultado de algo tão inevitável como um raio cósmico.

Minha pesquisa também sugere que quando o sistema pára assim, não há lugar para um log ser escrito e que a única maneira confiável de fazer isso é ter o sistema anexado a outro com o log sendo gravado através de um serial porta.

Além do usual edac-util, memtest, testes de estresse e substituição por precaução, há algo mais que eu deva levar em consideração ao lidar com esse erro?

Não consegui encontrar nenhum registro desse travamento em nenhum dos logs do CentOS que pesquisei, o que leva em conta minha crença de que não é possível registrar esse erro em um disco local. O erro foi relatado apenas a mim pelo BIOS após uma reinicialização automática. É aconselhável estar escrevendo logs do sistema para serial em todos os momentos para registrar esses tipos de erros?

Esse tipo de falha é evitável usando um único sistema ou isso só é possível usando uma solução corporativa cara?

O que posso fazer para fornecer medidas de fallback nesses casos de falha para um único servidor de produção; como em, o próprio servidor de produção não abrange várias máquinas, mas um servidor de fallback pode existir.

    
por Zhro 26.08.2014 / 00:02

3 respostas

1

Esta é uma resposta de como eu parei o sistema de travar, mas não resolve a questão original. Ainda estou pesquisando soluções e compartilharei todas as novas informações que surgirem à medida que forem aprendendo.

O sistema é uma caixa branca com uma placa-mãe Supermicro H8SGL-F com memória Viking de 64GB (16x4) Hynix e 32GB (16x2). A especificação da placa-mãe diz que os módulos RAM devem ser instalados em conjuntos de quatro conforme o processador usa o controlador de memória quad-channel. Eu joguei os dois módulos extras da Viking para ver se funcionava e funcionou. Essa solução funcionou por meses, mas foi meu primeiro erro.

Meu segundo erro foi que eu instalei o carneiro incorretamente. Os slots de memória são codificados por cores e intercalados para a configuração de quatro canais. Eu tinha o RAM instalado assim:

[ ========== ] 16GB Hynix
[ ---------- ] 16GB Hynix
[ ========== ] 16GB Hynix
[ ---------- ] 16GB Hynix
[ ========== ] 16GB Viking
[ ---------- ] 16GB Viking
[ ========== ]
[ ---------- ]

Embora essa configuração funcionasse por vários meses e só começasse a produzir um problema recentemente, eu não determinaria se a falha era devido ao aumento de capacidade causando um problema com meu layout fora de especificação se um módulo realmente tinha um problema .

Como eu tinha apenas um sistema de produção, removi todos os módulos e comecei a rotacioná-los como pares de dois (ainda sem especificação) e executando o sistema com capacidade reduzida por várias semanas. Não recebi nenhuma falha e não houve relatos de erros da ecc no edac-util. No entanto, é possível que um módulo defeituoso tenha estado no segundo slot e simplesmente não tenha sido acessado de forma que causaria uma falha.

Depois de girar o ram não conseguiu reproduzir o erro, percebi que tinha configurado o aríete incorretamente. Eu removi os módulos Viking e configurei o novo layout assim:

[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ] 
[ ========== ] 16GB Hynix
[ ---------- ]

Desde que fiz essa alteração, o sistema permaneceu estável. Apesar do alinhamento à especificação, isto não confirma se a falha é com o layout, um módulo Viking (desde que eles foram removidos) ou se o módulo incorreto é simplesmente um dos módulos Hynix mais abaixo no layout que é acessado com pouca freqüência não a culpa.

Por favor, veja esta resposta não como uma conclusão para o problema, mas como um passo que tomei para abordar a questão geral. Eu não terminei e continuarei informando enquanto continuo procurando soluções.

Também digno de nota, a energia do sistema pedalou ontem pela primeira vez desde que eu configurei a memória para o novo layout. Não posso confirmar se isso ocorreu devido ao problema de memória que está sendo resolvido ou se este é um problema separado com a fonte de alimentação, portanto leve esse incidente único até agora como um grão de sal.

    
por 23.09.2014 / 21:39
1

Bem, esse não é um sistema totalmente integrado como um servidor HP, Dell ou IBM, portanto, o monitoramento e o relatório de tal falha não estarão presentes ou consistentes.

Com os sistemas que gerenciei, os discos falham com mais frequência, seguidos por RAM, fontes de alimentação, ventoinha, placas de sistema e CPUs.

A memória pode falhar ... Não há muito o que fazer sobre isso.

Veja: É necessário gravar -em RAM para hardware de classe de servidor?

Como você não pode realmente evitar erros de ECC e falhas de RAM, apenas esteja preparado para isso. Mantenha peças de reposição. Tenha acesso físico aos seus sistemas e mantenha a garantia de seus componentes. Eu definitivamente não introduziria "substituto de precaução" em um ambiente. Algumas destas são uma função do seu hardware ... Você tem IPMI? Às vezes, os registros de hardware acabam lá.

Este é um dos agregados de valor de um melhor hardware de servidor. Aqui está um trecho de um servidor HP ProLiant DL580 G4 onde o limite de ECC na RAM foi excedido, em seguida, progrediu para o DIMM sendo desativado ... e, finalmente, o servidor falhando (ASR) e reiniciando-se com o DIMM incorreto desativado.

0004 Repaired       22:21  12/01/2008 22:21  12/01/2008 0001
LOG: Corrected Memory Error threshold exceeded (Slot 1, Memory Module 1)

0005 Repaired       20:41  12/06/2008 20:43  12/06/2008 0002
LOG: POST Error: 201-Memory Error Single-bit error occured during memory initialization, Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.

0006 Repaired       21:37  12/06/2008 21:41  12/06/2008 0002
LOG: POST Error: 201-Memory Error Single-bit error occured during memory initialization, Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.

0007 Repaired       02:58  12/07/2008 02:58  12/07/2008 0001
LOG: POST Error: 201-Memory Error Single-bit error occured during memory initialization, Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.

0008 Repaired       19:31  12/08/2009 19:31  12/08/2009 0001
LOG: ASR Detected by System ROM
    
por 26.08.2014 / 21:58
1

Se o DIMM tiver erros incorrigíveis, recomendo substituí-lo. Se forem apenas erros corrigíveis em uma taxa baixa, você provavelmente poderá viver com isso e, em qualquer caso, por erros corrigíveis, será mais difícil obter um reembolso.

Se você quiser ver se há um registro, tente acessar os registros do IPMI SEL, com ipmitool sel elist ou uma ferramenta equivalente.

A outra alternativa é configurar um kernel de travamento do Linux para inicializar e salvar o dmesg, isso também pode capturar as informações sobre a falha de hardware.

A terceira alternativa é registrar o console serial do servidor em algum lugar persistente, ele também incluirá as pistas para uma falha de software ou hardware do servidor.

    
por 27.08.2014 / 20:56