Estou executando o Ubuntu 12.04 LTS. Ontem encontrei uma mensagem na minha caixa de correio informando que meu servidor foi desligado. Eu reiniciei o sistema, mas ele não apareceu depois de muitos minutos e eu não tinha um sistema KVM de hardware para ver o que o kernel estava imprimindo no terminal. Então reiniciei o sistema para uma imagem de resgate do Linux e vi que a matriz RAID 1 do software estava fora de sincronia. O sistema de resgate também começou a reconstruir a matriz RAID.
Até o momento não há evidências de que algum dos discos apresente erros de hardware. Os status SMART parecem bons até agora.
Nunca recebi uma notificação por email do mdadm, embora a notificação por email estivesse ativada em /etc/mdadm/mdadm.conf.
Este servidor também foi configurado para encaminhar todas as mensagens syslog para um host de log, então verifiquei meu host de log. As partes relevantes são:
20 de maio 15:38:40 kernel: [1.869825] md0: alteração de capacidade detectada de 0 a 536858624 20 de maio 15:38:40 kernel: [1.870687] md0: tabela de partição desconhecida 20 de maio 15:38:40 kernel: [1.877412] md: bind 20 de maio 15:38:40 kernel: [1.878337] md/raid1:md1: não limpo - iniciando a reconstrução em segundo plano 20 de maio 15:38:40 kernel: [1.878376] md/raid1:md1: ativo com 2 de 2 espelhos 20 de maio 15:38:40 kernel: [1.878418] md1: alteração de capacidade detectada de 0 a 3000052808704 20 de maio 15:38:40 kernel: [1.878575] md: ressincronização da matriz RAID md1 [recorte] 20 de maio 15:52:33 kernel: O registro do kernel (proc) foi interrompido. 20 de maio 15:52:33 rsyslogd: [origin software = "rsyslogd" swVersion = "5.8.6" x-pid = "845" x-info = "http://www.rsyslog.com"] saindo no sinal 15 .
Como você pode ver, o sistema (o normal, não o sistema de recuperação) já detectou que algo estava errado com a matriz RAID durante a inicialização do sistema. Então, pouco depois, algo (não eu) interrompeu o sistema.
Então minhas perguntas são:
- O que poderia fazer com que os discos ficassem repentinamente fora de sincronia?
- Por que não fui notificado por e-mail?
- Por que o erro não foi registrado corretamente no syslog antes de interromper o sistema? Será que o sistema tentou fazer logon no syslog, mas o fez depois de interromper o daemon do syslog? Se sim, o que posso fazer para evitar isso?
- O que posso fazer para descobrir o que aconteceu? Ou, se não há como descobrir o que aconteceu agora, como posso melhorar o registro e as notificações para que da próxima vez eu possa fazer uma autópsia melhor?
Minha pergunta énãosobre a prática adequada de backup. Já sei que RAID não é um backup etc. Minha dúvida é apenas sobre notificações e diagnóstico.
Responder1
O que poderia fazer com que os discos ficassem repentinamente fora de sincronia?
Pode ser qualquer falha de hardware ou software no caminho entre os pratos da unidade e os dados na memória. O que pode significar, mas não está limitado a: cabeçote da unidade, controlador da unidade, cabeçote de conexão no cabo, o próprio cabo (quebra de fio interno), a porta à qual o cabo se conecta na unidade, a porta na placa-mãe ou placa filha , o chip controlador na placa-mãe ou placa filha, ou até mesmo uma falha no software (em algum lugar).
História verídica: uma vez tive um espelho RAID que estava instável, deixando cair uma unidade sem motivo. As unidades funcionaram bem, os pratos estavam limpos (as repetições dos passes SMART não resultaram em nada) e tudo funcionou bem - até que ele descascasse novamente e novamente. Substituí o cabo SATA de US$ 3 e os problemasimediatamentese afastou. Moral da história: MUITO pode dar errado e você nem sempre pode presumir que "está tudo bem" se não verificar todos os componentes no caminho dos dados.
Por que não fui notificado por e-mail?
A notificação por e-mail ocorre apenas quando (a) monitora ativamente a matriz ou (b) quando a matriz é interrogada.
Meu conselho é: você precisa que o mdadm monitore ativamente a matriz de unidades como um processo. Isso pode ser feito com algo semelhante (mas não exatamente igual):
mdadm --monitor --scan --syslog
Você precisará ajustar a linha acima para sua instalação específica.
Por que o erro não foi registrado corretamente no syslog antes de interromper o sistema? Será que o sistema tentou fazer logon no syslog, mas o fez depois de interromper o daemon do syslog? Se sim, o que posso fazer para evitar isso?
Pode ter havido vários problemas que fizeram com que o registro fosse interrompido.
Primeiro, há toda a questão de como o syslog funciona em geral; e embora muitos anos tenham sido necessários para torná-lo robusto e confiável, há certos casos extremos em que os dados podem não chegar ao disco. Este é um problema de design bem conhecido e que foi abordado ativamente com o gerenciamento de serviços no estilo de supervisão (também conhecido como daemontools e similares). A solução era ignorar completamente o syslog e gravar a saída em um logger que tivesse um descritor de arquivo aberto o tempo todo, para que nada fosse descartado e o logger despejasse a saída no disco o mais rápido possível; embora não seja uma solução 100% eficaz, ela melhora significativamente as chances de eventos gravados na unidade antes que o kernel entre em pânico ou seja desligado.
Em segundo lugar, existe a possibilidade de o kernel ter entrado em pânico total ou de ter ocorrido algum outro evento que forçaria a máquina a encurralar. Até mesmo hardware defeituoso pode causar um problema - já vi máquinas com fontes de alimentação de baixa potência causarem desligamentos espontâneos no Windows 8. A substituição da fonte de alimentação corrigiu o problema de desligamento permanentemente. Obviamente,nadao que o kernel pode fazer irá proteger contra uma máquina que simplesmente decidiu "Já estou farto disso" e começou a reiniciar.
O que posso fazer para descobrir o que aconteceu? Ou, se não há como descobrir o que aconteceu agora, como posso melhorar o registro e as notificações para que da próxima vez eu possa fazer uma autópsia melhor?
Existem várias abordagens:
Coloque o log em uma partição separada. Embora isso não seja uma garantia de que você obterá logs intactos, ajuda a isolar problemas do sistema de arquivos, como disco cheio, não é possível gravar, corrupção que causa uma remontagem para somente leitura, etc. casos específicos.
Observe o registro remoto de informações vitais do sistema. Novamente, isso não é uma garantia, mas ajudará se o último pacote puder "sair pela porta" antes que ocorra uma reinicialização, e esse pacote tiver pistas críticas sobre o motivo da reinicialização.
Para serviços críticos específicos, considere substituir a saída do syslog por outra coisa, como o registro em estilo de supervisão, onde um registrador dedicado intercepta a saída e a grava no disco o mais rápido possível. Isso aumenta a confiabilidade da saída que chega ao armazenamento. Com um pouco de trabalho, ele pode coexistir lado a lado com outros arranjos de gerenciamento de serviços.
Responder2
O que poderia fazer com que os discos ficassem repentinamente fora de sincronia?
Falha na unidade, falha no controlador, alguma outra falha de hardware. Algum problema de software obscuro.
Por que não fui notificado por e-mail?
O Ubuntu tem um cronjob /etc/cron.d/mdadmque resulta na verificação dos volumes RAID uma vez por dia às 00h57. Se o seu sistema não estava com problemas ou já havia falhado, não havia como enviar uma mensagem.
Por que o erro não foi registrado corretamente no syslog antes de interromper o sistema?
Bem, se as unidades estiverem falhando, não faz sentido tentar gravar nelas, pois qualquer gravação adicional poderá destruir o que resta. Sem saber a natureza exata da sua falha, pode ser que o seu volume ou sistema de arquivos tenha se tornado somente leitura. Por padrão, o Ubuntu está configurado para mudar para um sistema de arquivos somente leitura se houver erros no volume raiz.
como posso melhorar o registro e as notificações para que da próxima vez eu possa fazer uma autópsia melhor?
Configure o log em um host syslog remoto. Dessa forma, uma falha de armazenamento não significa que nada possa ser registrado.