NASDEC: A primeira substituição de disco

Neste artigo vou narrar a troca de um dos discos que, após três anos de bom serviços, está na iminência de pifar no meu NASDEC (meu NAS para durar uma DÉCada). Descrevo ainda a escolha e instalação de um substituto – tudo isso sem interrupção no serviço e sem perder nenhum dado, em um exemplo bem sucedido de "segurança contra indisponibilidade".

Este é um artigo bem técnico; assumo que o leitor tenha familiaridade com administração de sistemas Linux via linha de comando, conhecimentos de como funcionam os discos rígidos e sistemas de armazenamento em geral. Para dar mais contexto, recomendo ainda uma relida nos primeiros artigos da série, especialmente esse sobre o hardware e esse sobre a arquitetura. Repito aqui o mínimo absoluto que você precisa saber: o NASDEC é composto de duas máquinas quase idênticas, chamadas monkey e dinky, e uso o GlusterFS para manter uma certa árvore de diretórios acessível via rede, ao mesmo tempo em que é transparentemente replicada entre as duas máquinas.

O Incidente

O problema apareceu quando eu estava copiando uma leva grande de fotos e vídeos (uns 2,5 GB no total) do cartão de memória do meu celular para umas pastas no NASDEC. Sendo uma operação corriqueira, eu sabia por experiência que deveria levar não muito mais que dois minutos. Deixei a cópia em andamento, fui tomar café e esperava que estivesse terminado quando eu voltasse. Qual não foi minha supresa quando olho a barra de progresso e não tinha passado nem da metade. A velocidade indicava que a transferência estava transcorrendo a menos de 1MB/s, uma velocidade absurdamente baixa, mais de 30 vezes menos que o normal. Claramente havia algo errado.

Loguei na máquina monkey, que normalmente era a "primária" do cluster. Olhando o log do kernel, revelado pelo comando dmesg, deparei-me com um monte de mensagens assim:

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x65
ata1.00: failed command: READ DMA EXT
ata1.00: cmd 25/00:08:e0:94:5e/00:00:36:00:00/e0 tag 0 dma 4096 in
          res 51/40:08:e0:94:5e/40:00:36:00:00/e0 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/133
sd 0:0:0:0: [sda] Unhandled sense code
sd 0:0:0:0: [sda]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 0:0:0:0: [sda]  Sense Key : Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
        36 5e 94 e0 
sd 0:0:0:0: [sda]  Add. Sense: Unrecovered read error - auto reallocate failed
sd 0:0:0:0: [sda] CDB: Read(10): 28 00 36 5e 94 e0 00 00 08 00
end_request: I/O error, dev sda, sector 912168160
ata1: EH complete
btrfs read error corrected: ino 1 off 2313647734784 (dev /dev/mapper/vg0-nasdec sector 4526199648)

Esse bando de mensagens é gerado pelo subsistema do Linux que conversa com o disco rígido. O item crucial aí é a mensagem "auto reallocation failed". Isso significa que o disco detectou um erro de leitura e até conseguiu recuperar os dados, mas não conseguiu copiá-lo na "área sobressalente"; isso se chama "relocação automática" e é feita automaticamente pelo firmware do disco rígido, sem intervenção do sistema operacional. A mensagem de erro do Linux é meio infeliz: ele diz "unrecovered read error", mas a leitura parece ter sido bem sucedida, pois a última mensagem indica que o sistema de arquivos BTRFS (que têm verificação de integridade embutida) disse que o erro foi "corrigido".

A lerdeza observada deve ter sido causada pelo fato que, a cada nova leitura ou gravação, o disco estava tentando compensar as falhas, que demora muito mais do que uma leitura/gravação que dá certo logo na primeira vez.

Como eu estava com pressa pra terminar a cópia dos arquivos, parei o serviço do GlusterFS em monkey, efetivamente colocando o cluster no "modo degradado", ou seja, operando com menos do que o total de nós. Aqui é onde a redundância salva o dia, permitindo que eu continue normalmente e sem nenhuma perda de dados. Refiz a operação de cópia e, como previa, ela transcorreu na velocidade normal; o GlusterFS fez o que foi projetado para fazer: automaticamente percebeu que o nó monkey estava fora do ar e usou o nó secundário rodando em dinky.

Enquanto a cópia transcorria, rodei o utilitário smartctl para olhar os parâmetros S.M.A.R.T. de auto-monitoração do disco e a história que ele me contou foi essa (ressaltei em vermelho e laranja as partes mais relevantes):

[email protected]:~# smartctl -a /dev/sda
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD30EZRS-00J99B0
Serial Number:    WD-WCAWZ0165484
Firmware Version: 80.00A80
User Capacity:    3,000,592,982,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sat Aug 16 09:18:03 2014 BRT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!

Drive failure expected in less than 24 hours. SAVE ALL DATA.
See vendor-specific Attribute list for failed Attributes.

   (... um monte de outras coisas omitidas por brevidade ...)

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   194   194   051    Pre-fail  Always       -       3162
  3 Spin_Up_Time            0x0027   147   140   021    Pre-fail  Always       -       9650
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       64
  5 Reallocated_Sector_Ct   0x0033   133   133   140    Pre-fail  Always   FAILING_NOW 943
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   065   065   000    Old_age   Always       -       26275
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       58
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       32
193 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       1204884
194 Temperature_Celsius     0x0022   110   104   000    Old_age   Always       -       42
196 Reallocated_Event_Count 0x0032   001   001   000    Old_age   Always       -       631
197 Current_Pending_Sector  0x0032   199   199   000    Old_age   Always       -       896
198 Offline_Uncorrectable   0x0030   200   199   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       2
200 Multi_Zone_Error_Rate   0x0008   158   153   000    Old_age   Offline      -       12877

O item mais importante aí é o contador "Reallocated Sector Count", que excedeu o limite (isso acontece quando o número no campo "VALUE" é menor que o "THRESH"). O valor "cru" ("raw") sugere que o disco já tentou realocar 943 setores.

Todo disco rígido vem com uma certa "área sobressalente" de alguns poucos megabytes. Quando acontece um erro de leitura que os códigos corretores de erro conseguem recuperar, o firmware regrava os dados recuperados na área sobressalente e marca o setor defeituoso para que não mais seja utilizado. Com o passar do tempo e a degradação natural do disco, mais e mais setores são realocados para a área extra e ela acaba enchendo. A partir desse ponto, o disco não consegue mais compensar automaticamente os erros de leitura/gravação e daí em diante ele não mais garante que você sempre obtenha de volta o que gravou.

Esse disco tem pouco mais de três anos de comprado e o contador Power_On_Hours informa que o disco passou 26275 horas ligado, ou 2,99 anos no total. Colocando o número de série desse disco no site de suporte da WD, confirmei que a garantia dele venceu em março deste ano. Não deixa de ser curioso notar a coincidência desse incidente ter ocorrido justamente poucos meses depois. Em todo caso, se a garantia era de 3 anos, isso quer dizer a WD não esperava mesmo que o disco durasse mais muito mais do que isso. Sob essa ótica, eu deveria me declarar satisfeito, pois o disco excedeu ligeiramente o previsto. Ainda assim, já vi muitos HDs durarem mais de cinco anos e não consigo me livrar da impressão de que esse está saindo de combate em plena meia idade.

Uma coisa que me deixou inicialmente supreso é que o GlusterFS não mascarou os erros; eu intuitivamente achava que ele deveria observar que o primário está falhando e tentar salvar diretamente no secundário. Pelo jeito, ele não faz isso; parece que ele sempre tenta salvar em todas as réplicas e tem sempre que esperar pela mais lenta. Há um lado bom nisso: a lerdeza me chamou atenção para o disco pifando. Se o GlusterFS tivesse compensado, eu talvez não tivesse notado o problema e acabasse operando meses a fio com um único disco bom.

A Escolha do Substituto

A escolha mais simples seria adquirir um outro disco idêntico. Fazendo uma busca no MercadoLivre, fiquei surpreso em observar que os melhores preços para um Caviar Green de 3TB são praticamente os mesmos R$ 550,00 que eu paguei há 3 anos atrás... eu achava que depois desse tempo todo o preço deveria ter baixado substancialmente.

Mas, aproveitando que eu já teria de trocar o disco mesmo, talvez fosse melhor pegar logo um disco de maior capacidade. No ML, um Caviar Green de 4TB já ia pra lá de R$ 800,00, um aumento de 62% no preço para apenas 33% na capacidade. Mas eu achei também um Seagate de 4TB por R$ 500,00. Se a relação custo por gigabyte fosse o único critério, esse teria sido a melhor escolha.

Mas eu tinha lido pela web afora que vários fabricantes tinham acabado de lançar discos de 6TB. No ML só achei um, da Seagate, modelo ST6000DX000, por R$ 1.100,00. Era o dobro do preço do Caviar Green, mas também era o dobro da capacidade; ou seja: o mesmo custo por gigabyte. Também a favor pendiam os fatos que, como eu só tenho espaço físico para dois discos por nó, vale usar discos da maior capacidade possível; e eu estava mesmo querendo testar essa nova leva de discos. No lado dos pontos negativos, eu li umas avaliações em alguns sites dizendo que o disco esquentava muito, era incomumente ruidoso, etc.

Apostar as fichas em uma tecnologia nova e um produto imaturo tem lá seus riscos; não seria injusto arguir que isso vai contra a filosofia do NASDEC: se a idéia é durar décadas, talvez fosse mais sábio priorizar produtos e tecnologias mas amadurecidas.

A despeito disso, resolvi arriscar e comprei uma única unidade. Isso significa que eu vou passar um tempo ainda limitado a 3TB, que é a capacidade do disco de dinky que ainda está bom. Eu não quis comprar duas unidades e migrar logo pra 6TB porque, no projeto do NASDEC, estou adotando o princípio da "redundância dissimilar", em que os elementos redundantes devem ser de fabricantes diferentes, pois assim têm menos chance de falhar ao mesmo tempo ou pela mesma razão quando operados em condições semelhantes. Vou me confiar justamente na redundância dissimilar para mitigar o risco da tecnologia nova demais.

Como eu não achei outro disco de 6TB de outro fabricante, vou preferir esperar um pouco até algum aparecer. Mas não posso demorar muito: já estou com 90% dos meus 3TB ocupados! Além disso, o outro disco de dinky também é da Seagate, então estou temporariamente violando a tal "redundância dissimilar".

Instalação e Inicialização

Três dias depois, o disco chegou. Parei a máquina monkey graciosamente com o comando halt e puxei o disco antigo fora. Tirei uma foto do antigo e do novo para a posteridade:

A instalação física foi quase tão simples quanto deveria ser, exceto que, como eu havia lido em uns fóruns, o ST6000 só tem dois furos de fixação de cada lado ao invés de três; e o suporte do gabinete (modelo CI-9E89) usava justamente o furo do meio, que o ST6000 não tem. Parafusei só de um lado e fiz um armengue com uma fita "silver tape" para evitar que o disco virasse ou ficasse sambando.

Conectei os cabos de força e de dados, remontei e religuei a máquina e, após a partida do sistema, o dmesg me contou que o disco fora detectado normalmente:

[email protected]:~# dmesg | egrep "0:0:0:0:|sda"
scsi 0:0:0:0: Direct-Access ATA ST6000DX000-1H21 CC45 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 11721045168 512-byte logical blocks: (6.00 TB/5.45 TiB)
sd 0:0:0:0: [sda] 4096-byte physical blocks
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: unknown partition table
sd 0:0:0:0: [sda] Attached SCSI disk

Lembrando que no NASDEC usamos cifragem total de disco via software, o primeiro passo é preencher o disco com números aleatórios, o que já serve inclusive como um teste pra ver se não teremos um caso de mortalidade infantil:

# size=$(blockdev --getsize64 /dev/sda)
# echo 0 $[size/512] zero | dmsetup create bigzero
# openssl rand -base64 32 | \
  cryptsetup -c salsa20_12-plain-plain64 create bigrand /dev/mapper/bigzero
# pv -s $size < /dev/mapper/bigrand > /dev/sda
4.8GB 0:01:24 [  60MB/s] [>                                 ]  0% ETA 27:16:32

A velocidade em torno de 60MB/s deixou um pouco a desejar, mas, vá lá que seja. Como o disco é muito grande, a previsão oferecida pelo utilitário pv é que o processo todo levasse umas 27 horas.

Quando eu já estava fechando tudo para ir dormir, resolvi por curiosidade olhar os atributos S.M.A.R.T. do disco novinho em folha. Tudo muito normal, exceto isso:

[email protected]:~# smartctl -a /dev/sda | grep "Airflow"
190 Airflow_Temperature_Cel 0x0022   043   041   045    Old_age   Always   FAILING_NOW 57 (0 98 59 32)

Eu tinha mesmo lido umas avaliações pela _web afora dando conta que esse disco esquentava bastante, mas confesso que fiquei chocado em ver um disco novinho já excedendo o limite operacional – 57 graus celsius é bem quente para um disco rígido. De fato, tocando com a mão no gabinete de monkey e comparando com dinky, a diferença é notável. Isso não é um começo muito auspicioso.

Depois que a inicialização do disco terminou, experimentei deixar o disco em modo de espera ("standby") usando o comando:

# hdparm -y /dev/sda

Isso faz com que, entre outras coisas, o disco pare de girar, o que diminui o consumo de energia e, presumivelmente, a temperatura. De fato, algumas horas depois, o disco reportou uma temperatura de 38 graus:

[email protected]:~# smartctl -a /dev/sda | grep "Airflow"
190 Airflow_Temperature_Cel 0x0022   062   039   045    Old_age   Always   In_the_past 38 (1 127 61 32)

Isso me deixa em um dilema: devo operar esse disco girando e super quente o tempo todo, ou devo confirar o modo de espera automático por inatividade? Muita gente defende que fazer muitos ciclos de parada e reinício tendem a fazer o disco pifar mais rápido, mas também muita gente diz que o excesso de temperatura também acelera a degradação.

Deixei pra pensar nisso depois e continuei com a inicialização do disco – preparar o dispositivo cifrado, criar os volumes lógicos, formatar o sistema de arquivos, etc:

# cryptsetup --verify-passphrase -c salsa20_12-plain-plain64 create esda /dev/sda
Enter passphrase: (... digitei a frase-senha aqui ...)
Verify passphrase: (... digitei novamente a frase-senha aqui ...)
# pvcreate /dev/mapper/esda
  Physical volume "/dev/mapper/esda" successfully created
# vgcreate vg0 /dev/mapper/esda
  Volume group "vg0" successfully created
# lvcreate -L 2.4T -n nasdec /dev/vg0
  Rounding up size to full physical extent 2.40 TiB
  Logical volume "nasdec" created
# mkfs.btrfs /dev/vg0/nasdec

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /dev/vg0/nasdec
        nodesize 4096 leafsize 4096 sectorsize 4096 size 2.40TB
Btrfs Btrfs v0.19

Um detalhe de segurança importante é usar uma frase-senha diferente da usada no disco anterior. Sempre que se usar o modo "cru" do cryptsetup juntamente com um algoritmo de cifragem orientado a bytes, como é o caso do Salsa20, é imprescindível ter o cuidado de não reutilizar frases-senha.

Isso feito, eu reiniciei o sistema e executei o script start-nasdec.sh que eu já havia descrito no artigo anterior desta série. Depois, desabilitei o script self-heal que eu tinha colocado no cron.hourly e executei manualmente dentro de uma sessão do screen:

# find /nas -noleaf -print0 | xargs -0 stat >/dev/null

Isso é necessário porque o GlusterFS gerencia as réplicas por diretório e só nota que elas estão desatualizadas quando o diretório que as contêm é acessado. Esse comando find varre toda a hierarquia de diretórios, disparando a cópia de todos os arquivos do disco antigo em dinky para o novo em monkey. Como eu já tenho uns 2,2TB ocupados nesse volume, e a julgar pelas 27 horas que foram necessárias para escrever o disco todo com números aleatórios, estimei que essa operação iria levar umas 12 horas pra se completar.

Enquanto rolava essa cópia, aproveitei pra medir o consumo de energia: deu 70VA ou 47W a um fator de potência de 0,67 (a máquina monkey usa uma fonte PD075). A título de comparação, antes de eu trocar o disco o consumo era de 60VA ou 38,5W a um fator de potência de 0,64. Em outras palavas, esse novo disco consome 10VA a mais; não admira que ele esquente.

Terminada a cópia, reativei o script self-heal e pronto! Meu NASDEC já está novamente no modo normal com redundância total dos dados. Ao todo, passei pouco mais de uma semana em modo degradado.

O Destino do Disco Pifado

Como todo o conteúdo do disco antigo era gravado cifrado pelo sistema operacional, eu não precisei me dar ao trabalho de obliterar seu conteúdo para evitar vazamento dos meus dados confidenciais, pois, sem a frase-senha de cifragem, não há como decifrar os dados; se esse disco parar nas mãos de um analista forense, tudo que ele vai conseguir ler do disco serão 3TB do que lhe parecerá ser números aleatórios. Isso dispensa a necessidade de passar nele um obliterador de dados, tal como o famoso DBAN – até porque, se o disco tivesse pifado mesmo, isso seria impossível.

Conclusões

Dentre as falhas de disco que já vi, essa foi uma das mais graciosas e menos repentinas: o WD Caviar Green ainda não "morreu" de verdade; ele mesmo estava avisando que estava ficando caduco – eu que é que não vinha olhando. Quando o contador de realocações sai de zero, já é mesmo hora de substituir o disco. Já tive vários outros discos que tiveram "morte súbita": simplesmente pararam de responder a qualquer comando em absoluto, sem dar aviso nenhum.

A coisa boa é que o NASDEC fez o que se propôs a fazer: resistiu, sem interrupção de serviço, a uma falha de disco e prossegue mantendo meus dados íntegros, acessíveis e sem perda de confidencialidade. O problema do aquecimento do novo disco Seagate de 6TB me preocupa um pouco; pergunto-me quanto tempo ele vai durar e se ele vai se provar ser um bom ou mau investimento. Será que eu consigo chegar a dez anos sem perder nenhum dado? Só o tempo dirá.

Partes anteriores

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Robson | 2014-09-01 03:19:53 | permalink | topo

Mais um grande artigo !

Muito interessante, eu tinha feito essas mesmas avaliações, e cheguei a conclusão de que no momento para mim, não valia pegar um disco destes de 4 ou mais TB, mais pela relação custo benefício.

Reparei que deveriam esquentar muito e não quis arriscar, foi ficar na espera pelo "prazo de vida dele".

Eu comprei um gabinete similar ao que usou "modelo F", para montar um Media Center experimental pois o meu "chines" pifou depois de mais de 2 anos.

Reparei que o gabinete é mesmo projetado só para um HD 3,5 e estarei usando ele para testar a placa que usarei no NASDEC.

Estou pensando em um gabinete de madeira/mdf ou alumínio/aço de forma a ter bastante espaço para ventilação pois quero colocar as duas máquinas num único móvel, depois lhe envio fotos de como ficou, deve ficar pronto ano que vem.

Continue com o excelente trabalho. abs