Detectar Drives Danificados em Linux

SUMÁRIO

• Introdução
• Exibindo Drives de Storage
• Listar Storages e Enclosures
• Identificar Drives Danificados
• Considerações e Finalização

Introdução

Todos os grandes vendors possuem soluções integradas com atributos para monitorar drives de armazenamento - como Oracle HMP (instalável no ILOM) , TSM (IBM Tivoli), HP ILO, DELL OpenManage, Supermicro SuperDoctor e outros. Do lado open source, Nagios e Zabix cumprem (parcialmente) a tarefa de monitorar recursos de storage.

Utilitários como o gsmartcontrol e gnome-disks não são específicos para monitoração, mas servem para verificar (de forma ativa e individual) o estado dos discos locais de ambientes menores.

Drives avariados podem comprometer todo sistema de armazenamento. Geralmente, nota-se maior latência no acesso a LUNs iSCSI ou em servidores de arquivos NFS, CIFS, etc. Em desastres mais agudos pode haver perda de dados.

O objetivo deste documento é expor algumas formas de identificar drives problemáticos contidos em storages, através de ferramentas nativas em terminais Linux.

"Não é recomendado executar os procedimentos deste artigo, ou qualquer outro, em ambientes com informações críticas inacessíveis. Havendo necessidade de recuperar dados importantes, recomenda-se desativar os drives (HDs, SSDs, etc.) do storage e entrar em contato com a Hosco."

Listando Drives de Armazenamento

O ls é um programa básico presente em qualquer sistema Unix-like. O diretório /dev contém arquivos de referência para os drives detectados e ativos. Portanto, o comando ls -l /dev/sd* | sed '/[0-9]$/d' exibe todos HDs, SSDs e flash drives reconhecidos no sistema.

O utilitário lsblk faz parte das principais distribuições Linux e está embutido mesmo em instalações pequenas, como Debian Netinst e CentOS Minimal. Ele mostra informações mais detalhadas sobre as unidades de armazenamento e suas partições, com a vantagem de poder ser executado por usuários comuns.

Exibindo Storages e Enclosures

Um único node de alta densidade, Dell Compellent SC280, pode suportar mais de 80 HDs. Uma solução completa com HP 3PAR StoreServ 7440c pode comportar até 960 drives. Estes dois exemplos ilustram o quanto pode ser difícil obter informações sobre storages NAS e SAN, sem recorrer as ferramentas dos vendors (instaladas nos servidores ou controladores de armazenamento).

É, relativamente, comum a Hosco recuperar dados em plataformas com mais de 40 drives, distribuídos entre vários enclosures. Em tais circunstâncias todos os discos são analisados, isoladamente, e aqueles que estão danificados são reparados (trocas de cabeça de leitura, reparo de firmwares, etc.) e reintegrados ao storage. Entretanto, alguns deles voltam a ter problemas durante o processo de extração de dados, sendo difícil identificá-los nesses cenários.

Para resolver o problema, a equipe da Hosco desenvolve soluções (de scripts simples à programas mais completos) que entregam, de modo não invasivo, informações sobre enclosures anexados ao sistema. Nos processos de recuperação em storages, esta é uma boa prática que garante a integridade física e lógica dos dispositivos, evitando inconsistência em volumes RAID, LVM, Zvols, etc.

O findstor é um simples programa em shell que exibe os storages anexados ao sistema e seus hard/flash drives. Ele tem as vantagens de não fazer chamadas de sistema para os endereços físicos dos discos e ser executado por usuários comuns. O findstor pode ser baixado neste link.

Identificando Drives Danificados

É possível detectar dispositivos de armazenamento (HDs, SSDs e flash drives) com falhas, analisando mensagens de kernel, saídas da libata, logs do scsi_mod e demais módulos de storage.

Para customizar essa tarefa a Hosco criou outro programa bastante simples e eficiente. O script baddrive localiza drives danificados, ou que estejam comprometendo o sistema, e os exibe na saída de terminal. O baddrive pode ser baixado neste link.

Para identificação física do drive no storage, utiliza-se qualquer rotina que acione o led localizador (que fica na sua própria gaveta do ou ao lado dela). Mas não há um padrão de mapeamento do kernel que possibilite criar um simples programa de automatização. Para esta situação é mais prático instalar o lsscsi ou systool e executar algumas tarefas manuais.

Tomando um storage Sun da família ZFS 7000 como exemplo: primeiro deve-se usar um comando lsscsi com grep para filtar o offset do HD no equipamento. Em seguida, realiza-se uma pesquisa em /sys/devices e por fim se executa uma chamada através do arquivo locate. A imagem abaixo ilustra isto com detalhes e facilita a compreensão do leitor.

As rotinas acima funcionam em um storage da Sun, usando comunicação por SAS. Os processos variam de acordo com fabricante, modelo e protocolo de transporte utilizado.

Considerações e Finalização

Existem softwares mais complexos e robustos do que as citados neste artigo. Mas o propósito deste documento é o uso de ferramentas out of the box e que dispensam instalação de dependências de bibliotecas. Sendo de autoria de uma empresa de recuperação de dados, o texto também prioriza procedimentos não invasivos.

Novamente, segue recomendação de não executar procedimentos - incluindo os descritos neste artigo - em storages com dados críticos ou com informações que não podem correr risco de serem perdidas. Drives danificados devem permanecer desligados.