| Created: 2017-08-23 14:57 | Updated: 2024-04-03 20:39 |
Os links apresentados neste documento foram verificados quanto à sua disponibilidade na data de publicação deste documento porém, dado o dinamismo da Internet, é possível que alguns links não esteja mais disponíveis no momento da leitura deste documento. Para estes casos, peço desculpas ao leitor, mas este tipo de inconveniente está além do nosso controle.
Prever problemas em discos rígidos é uma tarefa nada fácil, mas ainda assim é essencial para a grande maioria dos administradores de sistemas, principalmente para aqueles que trabalham em empresas que mantém um ou mais servidores locais. Aquelas empresas que possuem dados na nuvem, contratados de grandes provedores deste tipo de serviço, quase não se preocupam muito com este tipo de falha, já que, dependendo do tipo de contrato, o problema passa a ser do provedor de serviços.
Como atualmente estou inserido no primeiro grupo (aquele que tem que se virar com poucos recursos), acabei por passar por vários problemas de falha em discos rígidos. Quando este problema afeta apenas uma estação de trabalho, apesar de ser trabalhosa a troa, os efeitos são normalmente menos catastróficos, considerando é claro, que existam backups dos dados contidos na estação de trabalho. Agora, quando o problema ocorre num servidor, aí normalmente a situação é mais complicada. Reinstalar e reconfigurar todos os serviços, restaurar os dados, testar e liberar para aquela galera que fica telefonando para você a cada 15 minutos para perguntar: "- E aí, está pronto? Quando volta a funcionar? Meu trabalho está parado por sua causa.".
Este problema piora quando não há servidores redundantes, o que, para uma boa parte das pequenas e médias empresas brasileiras, é uma realidade. Todos que já trabalharam em pequenas e até em médias empresas, sabem que conseguir convencer os gestores sobre a necessidade de sistemas e/ou servidores redundantes é difícil e, quando eles se dão por convencidos, conseguir a verba para a aquisição de hardwares e softwares é outra batalha praticamente perdida. As coisas só melhoram depois de alguma catástrofe, mas aí, já foi!
Depois de anos nesta situação, passei a me preocupar mais em analisar algumas informações de diversos sistemas e de hardwares.
Numa recente leitura de um artigo na Internet, disponível em Back Blaze, obtive informações muito interessantes que resolvi traduzir/adaptar para este artigo, com a finalidade de servir como referência para mim mesmo (já que uso meu site para minhas anotações pessoais não privadas) e, por que não, disponibilizar para quem estiver interessado.
Para o caso de discos rígidos, a ideia é tentar prever falhas nos discos, permitindo assim o planejamento de troca. Discos rígidos falham, e você pode ter certeza disso, é só uma questão de tempo. Como todo dispositivo mecânico e eletrônico, os discos rígidos têm uma vida útil determinada.
S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology), que é normalmente referenciada como o nome (e não acrônimo) SMART, é um sistema de monitoramento incluso nos discos rígidos (HDD) e discos de estado sólido (SSD) que monitoram vários indicadores da saúde destes dispositivos. Acredita-se que, se bem analisados, estes indicadores permitem que falhas sejam previstas com antecedência, de forma a permitir que os discos em estado de pré-falha possam ser substituídos antes da falha realmente ocorrer.
Uma referência sobre SMART muito citada na Internet é a disponível na Wikipedia: S.M.A.R.T. e, além de muitas outras, há a especificação de comandos ATA/ATAPI, disponível em ATA/ATAPI.
De qualquer forma, a Back Blaze, baseada em sua experiência neste assunto e nos dados estatísticos coletados de sua base de discos rígidos instalados, elencou 5 indicadores oferecidos pela SMART que ela considera os principais para a prevenção de falhas em discos rígidos. Muito, ou quase tudo, do que descrevo aqui foi obtido no blog da BackBlaze e em sites de especificação da tecnologia SMART. Então, não inventei nada do que descrevo aqui, mas apenas resumo o que encontrei por aí e considerei válido.
Segundo o blog, em 2014 a Back Blaze tinha aproximadamente 100.000.000 GB de dados armazenados em aproximadamente 40.000 discos rígidos. Acredito então que a experiência deles pode ser interessante.
Podemos considerar uma falha de disco quando ele pára de funcionar ou quando, apesar de funcionando, não é possível a gravação e/ou recuperação dos dados. Neste caso, o dispositivo tem que ser sacado do equipamento e substituído por um novo.
Segundo a Back Blaze, os 5 indicadores do relatório oferecido pela SMART que indicam falha iminente são os seguintes:
Mas e os outros indicadores? A tecnologia SMART oferece mais de 70 indicadores. É óbvio que eles também são importantes, mas acredito que dificilmente um administrador terá tempo e condições de analisar todos os indicadores e avaliar bem a situação. Então, acredito que possamos considerar os indicadores relatados pale Back Blaze como uma referência básica, até porque estes indicadores foram obtidos pela Back Blaze através de análises estatísticas de seus discos durante alguns anos.
Segundo seu relatório, a Back Blaze utiliza, por exemplo, o indicador SMART 187 como orientação básica para a troca do disco.
Vejamos então o que são alguns dos indicadores do SMART.
O indicador 187 refere-se ao número de leituras não puderam ser corrigidas usando o ECC (Error Correcting Code). Discos rígidos com este indicador igual a zero dificilmente falham. Valores maiores que zero, indicam problema iminente. Segundo a Back Blaze, este é um indicador que ela utiliza como determinante para a substituição do disco rígido.
Segundo a Back Blaze, o indicador 187 reportou valores maiores que zero consistentemente em todas as marcas de discos que ela utiliza e, talvez por isso, ela o utilize como principal indicador de disco rígido falha potencial.
A verificação deste indicador é simples:
Cuidado: a dúvida é qual valor utilizar: VALUE ou RAW_VALUE? Em vários discos eu verifiquei que o valor VALUE está em 100 (valor normalizado), enquanto que o RAW_VALUE está em zero.
Este indicador contém o número de sectores realocados. O valor bruto (raw) representa o número de setores ruins encontrados no disco e que foram remapeados. Isto significa que, quanto maior o valor deste indicador, maior é o número de setores do disco que precisaram ser relocados. Este valor é normalmente usado como uma métrica da expectativa de vida do disco: um disco com muitos setores relocados tem uma chance significativamente maior falhar nos próximos meses (ou dias).
Este indicador contém o número de operações de disco abortadas em decorrência de timeout (falta de resposta dentro dos limites de tempo esperados). Normalmente, este valor deve ser igual a zero.
Indica o número de setores "instáveis", isto é, que estão aguardando serem remapeados em decorrência de algum erro irrecuperável. Se um setor "instável" é lido com sucesso numa operação posterior, o setor é remapeado e o valor do indicador 197 é decrementado.
Erros de leitura de setores não remapeiam estes setores imediatamente: uma vez que o valor correto não pôde ser lido com sucesso, então ele também não pode ser gravado em outro local. Ao invés disso, o firmware da controladora do disco rígido lembra que o setor precisa ser remapeado, e irá remapeá-lo na próxima operação de gravação do mesmo. Contudo, alguns fabricantes optam por não remapear o setor imediatamente na próxima solicitação de gravação: ao invés disso, alguns fabricantes optam por tentar gravar mais uma vez os dados no setor original. Se a operação ocorrer com sucesso, o setor é marcado como bom. Esta é uma estratégia complicada, pois, podem ocorrer setores que falhem ocasionalmente, e isto pode fazer com que eles nunca sejam remapeados.
Indica o número de erros irrecuperáveis ocorridos na leitura ou escrita de setores. Um aumento no valor deste atributo indica defeitos na superfícies do disco ou problemas no subsistema mecânico do disco.
O comando smartctl apresenta várias informações, como as características do disco (modelo, capacidade, número de série etc), mas oa mais importantes para o diagnóstico do disco são os atributos e os resultados dos testes.
Os atributos são apresentados quando executamos o comando:
smartctl -a /dev/...
Os atributos são mostrados em colunas, como mostrado no exemplo a seguir (alguns trechos da saída do comando foram omitidos para facilitar a visualização):
sudo smartctl -a /dev/sda
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-4.11.0-mlb] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: SAMSUNG HD322GM
Serial Number: S2SXJ50B805543
LU WWN Device Id: 5 0024e9 400c9cc02
Firmware Version: 1AR10101
User Capacity: 320,072,933,376 bytes [320 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ATA8-ACS T13/1699-D revision 6
SATA Version is: SATA 2.6, 6.0 Gb/s
Local Time is: Wed Aug 23 08:30:25 2017 -03
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
...
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 20
2 Throughput_Performance 0x0026 252 252 000 Old_age Always - 0
3 Spin_Up_Time 0x0023 084 082 025 Pre-fail Always - 5107
4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1490
5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 252 252 051 Old_age Always - 0
8 Seek_Time_Performance 0x0024 252 252 015 Old_age Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 12730
10 Spin_Retry_Count 0x0032 252 252 051 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 252 252 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1499
13 Read_Soft_Error_Rate 0x003a 100 100 000 Old_age Always - 0
191 G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 15
192 Power-Off_Retract_Count 0x0022 252 252 000 Old_age Always - 0
193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 1500
194 Temperature_Celsius 0x0002 064 061 000 Old_age Always - 25 (Min/Max 10/39)
195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always - 0
196 Reallocated_Event_Count 0x0032 252 252 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0036 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 3
240 Head_Flying_Hours 0x0032 100 100 000 Old_age Always - 12730
241 Total_LBAs_Written 0x0032 099 093 000 Old_age Always - 2136924
242 Total_LBAs_Read 0x0032 091 089 000 Old_age Always - 13202799
254 Free_Fall_Sensor 0x0032 252 252 000 Old_age Always - 0
...
Cada atributo possui várias colunas, a saber:
ID: Identificador do atributo. Este identificador é conhecido como ATA S.M.A.R.T. e serve para identificar o atributo, já que a descrição (colune NAME) pode variar de um fabricante para outro. Este identificador deve ser utilizado para comparar o atributo com outras listas ou com os resultados apresentados por outros discos;
Name: Nome do atributo;
Value: O valor atual (normalizado) do atributo. em geral, valores altos são sempre melhores, exceto por exemplo, para temperaturas. Os valores normalmente são apresentados na faixa de 0 a 100, mas alguns atributos (e fabricantes) são apresentados na escala de 0 a 255. Não há um padrão definido de como os fabricantes convertem os valores reais dos atributos para valores normalizados: quando um valor normalizado se aproxima do valor de limiar (THRESHOLD), ele pode fazê-lo linearmente, exponencialmente, logaritmicamente ou de qualquer outra forma que o fabricante desejar. Isto significa então que um valor normalizado duplicado não significa necessariamente "duas vezes melhor";
Worst: Indica o pior valor (também normalizado) que o atributo atingiu em algum instante no tempo desde que o SMART foi ativado no disco (sim, o SMART pode ser ativado ou não na controladora).
Threshold: É o limite do valor normalizado abaixo do qual o atributo é considerado como "excedendo as especificações". Isto significa que, se o valor normalizado for menor que o valor de limiar (threshold), o SMART considera o disco como em condição de falha ou falha iminente;
Type: Indica o tipo do atributo, havendo dois tipos:
Observe que um mesmo atributo pode ser considerado de forma diferente por diferentes fabricantes, assim, um fabricante pode considerar um atributo como Pre-fail, enquanto que outro pode considerar o mesmo atributo como Old_age. Este é o caso, por exemplo, do atributo ID 7 (Seek_Error) que é um fenômeno generalizado em muitos discos e que não é considerado crítico por vários fabricantes, mas a Seagate o considera como Pre-fail (crítico);
Segundo o artigo Decoding smartctl output e What is SMART?, a avaliação dos resultados do comando smartctl deve seguir algumas orientações, que vou tentar apresentar a seguir.
Antes disso, porém, é preciso lembrar que cada atributo tem um valor normalizado (VALUE), o pior valor ocorrido no passado (WORST) e um valor de limiar (THRESH). Todos estes valores são normalizados, ou seja, normalmente eles aparecem numa escala de 0 a 100 ou de 0 a 255. Também há o valor bruto (RAW_VALUE), que contém o valor não normalizado, mas que nem sempre pode ser interpretado sem o conhecimento específico do fabricante.
Em linhas gerais, a análise dos dados apresentados pelo comando smartctl é a seguinte:
Se o atributo é do tipo Pre-fail e se VALUE <= THRESH então o atributo indica falha iminente do disco.
Se o atributo é do tipo Old_age (ou usage), se VALUE <= THRESH, então o atributo indica eventual final de vida do disco por velhice (idade) ou desgaste normal.
IMPORTANTE: o fato de um atributo ser do tipo Pre_fail não significa que o disco esteja prestes a falhar! Ele só tem este significado se o valor atual normalizado (VALUE) for menor ou próximo do valor de limiar (THRESH).
Se o valor normalizado do atributo (VALUE) for menor ou igual ao valor de limiar (THRESH), então a coluna WHEN_FAILED irá mostrar FAILING_NOW.
Outra possibilidade é o valor WORST ser menor ou igual ao valor de limiar (THRESH) e, neste caso, a coluna WHEN_FAILED irá mostrar In_the_past.
Uma regra geral é a seguinte: se a coluna WHEN_FAILED está vazia ("-"), então o atributo está OK. Mas é preciso ficar atendo à proximidade do valor com o limiar.
O comando smartctl retorna um código numérico quando ele finaliza sua execução. Este código não é apresentado no final do comando, porque é um valor retornado para o sistema operacional. Este código é um valor numérico de 8 bits, ou seja, na faixa de 0 a 255 e que, no caso do smartctl é codificado como um mapa de bits, e pode ser utilizado também como uma referência adicional do resultado da análise efetuada pelo comando smartctl (mas não deve ser utilizado como único indicador, já que os atributos podem dizer muito mais sobre a saúde do disco).
Para obter o resultado retornado pelo smartctl de uma forma rápida, pode-se executar o comando e imediatamente após a execução do mesmo, solicitar o código de retorno. Observe que o shell (console) do sistema operacional só armazena o valor de retorno do último comando executado. Exemplo:
smartctl -a /dev/sda ; echo $?
...
0
O valor retornado é sempre apresentado em decimal. O valor correspondente em binário possui o seguinte valor para cada bit, sendo que o bit 0 indica o bit menos significativo do valor:
Bit 0: Erro na linha de comando;
Bit 1: O dispositivo não pôde ser acessado, ou não retornou um identificador válido ou está em modo de baixo consumo (low-power);
Bit 2: Alguns comandos SMART ou ATA enviados para o dico falharam. Também pode ser ocorreu algum erro de checksum nos dados retornados pelo SMART;
Bit 3: A verificação do teste do SMART retornou o status "DISK FAILING";
Bit 4: Foram encontrados um ou mais atributos do tipo Pre-fail com valores menores ou iguais ao limiar;
Bit 5: O status do teste do SMART retornou "disco OK", porém, foram encontrados um ou mais atributos com valor menor ou igual ao limiar ocorridos no passado;
Bit 6: O log de erros do dispositivo contém registros de erro;
Bit 7: O registro de log de autoteste do dispositivo contém registros de erro. Para dispositivos ATA, erros detectados em autotestes anteriores seguidos por autotestes sem detecção de erros são ignorados.
Certa vez, não vou indicar a data pois não é relevante, tive um problema num dos discos de um dos servidores sob minha responsabilidade. O equipamento operava em RAID-1 (espelhamento), então a substituição foi bem tranquila, já que apenas um dos discos falhou.
Após a substituição do disco, efetuei o teste com o smartctl para verificar as condições do disco e verifiquei que o disco apresentava problemas. O problema residia nos seguintes atributos:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 8
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 8
Instalei o disco em outro computador, agora com o Windows, e executei um software de teste SMART mais recente disponível só para tirar a dúvida de que poderia ser um problema do smartctl com um disco novo. O mesmo problema foi indicado.
Tomei a medida padrão: entrei em contato com o fornecedor e ele substituiu o disco por um outro, de mesma marca e modelo. Substituí o disco no final de uma sexta-feira e acabei não tendo tempo de fazer todas as verificações necessárias, pois a ordem era sincronizar os discos imediatamente. Assim o fiz. Na segunda-feira, recebi vários e-mails do monitor smartd, que eu sempre costumo deixar configurado para enviar e-mails quando alguma anomalia for detectada, informando problemas no disco recém instalado. Curiosamente, o problema era idêntico ao do disco anterior.
Isto me deixou preocupado: poderia ser um problema de lote de fabricação? Ou era um problema relacionado ao software?
Resolvi então pesquisar um pouco mais sobre os atributos 197 e 198 antes de solicitar uma nova substituição do disco.
Pela descrição já apresentada anteriormente, os atributos 197 e 198 dizem, basicamente, que a controladora encontrou setores que não puderam ser gravados e que eles foram marcados para serem remapeados, isto é, gravados na área reservada do disco. Bem, aqui cabem alguns esclarecimentos:
Todo disco possui uma área reservada que é utilizada para a relocação de setores, ou seja, caso alguns setores da área principal tenham problema, eles são automaticamente mapeados para a área reservada do disco. Desta forma, um disco pode apresentar um certo número de setores defeituosos que a controladora cuida disso sem que o disco precise ser inutilizado. Esta é uma forma inteligente de fabricar discos, pois pequenas imperfeições no disco não afetam o seu uso, e permitem uma certa tolerância a erros na fabricação. O problema começa quando o número de setores defeituosos na área principal é maior que o número de setores disponível na área reservada do disco;
O atributo 197 (Current_Pending_Sector) significa que a controladora marcou N setores (provavelmente defeituosos) para remapeamento, mas ainda não os remapeou para outra posição do disco (provavelmente uma área reservada para este propósito);
O atributo SMART 198 (Offline_Uncorrectable) significa que a controladora encontrou N setores defeituosos e tentou corrigi-los, mas não conseguiu e, por isso, eles foram marcados para uma nova tentativa ou para serem remapeados (isto depende das estratégia do fabricante).
Então, como havia setores pendentes e que deveriam ser relocados para outra área do disco e como esta relocação só ocorre quando o setor for gravado, resolvi forçar a gravação do setor. Bem, havia então, basicamente, três possibilidades para fazer isto:
Descobrir quais setores estavam com problema e gravá-los algum software específico para isso, como por exemplo o hdparm. Mas não achei esta solução viável no meu caso porque o disco já estava operando em RAID e não achei seguro acessá-lo diretamente contornando o RAID;
Executar o teste offline através do smartctl. Segundo o manual do smartctl, este teste pode ser executado com o disco em operação, mas novamente pensei que isto pudesse provocar algum problema com o RAID (seguro morreu de velho);
Gravar dados no disco até que o setor seja gravado. Optei por esta possibilidade, que não era a mais simples (na verdade, a mais simples seria o teste offline), mas era a que não oferecia nenhuma possibilidade de problema com o RAID, afinal, era só criar arquivos até encher o disco.
Como o disco era parte de vários MD (dispositivos lógicos do RAID), comecei a criar arquivos em cada uma das partições (MD), começando pelas menos críticas, isto é, as que possuem arquivos estáticos (/boot, /usr etc). Sem mais delongas, depois de algum tempo criando arquivos, finalmente consegui o que eu imaginara que iria acontecer: a controladora foi obrigada a utilizar os setores defeituosos o que forçou a relocação dos mesmos para outra área do disco. Com isso, a execução dos testes do SMART não acusaram mais os erros nos atributos 197 e 198.
Continuei então monitorando o disco usando o smartd e, desde então, nenhum erro foi detectado. Sim, eu poderia simplesmente ter solicitado a troca do disco, mas lembremo-nos que este já era o segundo disco com o mesmo problema. Não tenho como dizer se esta atitude foi segura e correta, no entanto, considero que a relocação de setores do disco seja uma tarefa normal, já que a produção de discos 100% livres de erro deva ser uma meta, mas talvez não uma realidade, caso contrário, as controladoras dos discos não reservariam áreas para relocação de setores.
Outra motivação para esta atitude veio do relatório da Back Blaze que considera o atributo 187 como o principal indicador de falha iminente do disco.
Se alguém discordar ou algo a acrescentar, por favor, apresente sua experiência.
Fui.