O servidor Ubuntu não responde a problemas no disco rígido, apesar da configuração do raid

Question

Estou executando um servidor no Ubuntu 10.04.4 LTS (Linux xxxx 2.6.32-67-servidor # 134-Ubuntu SMP quarta 24 de setembro 18:55:00 UTC 2014 x86_64 GNU / Linux) com dois discos rígidos em um invasão de software 1.

Eu repetidamente tive o problema de que o sistema ficou completamente sem resposta por um período significativo (> 1 hora), efetivamente derrubando o servidor. O ataque mantém o disco problemático na matriz, algumas vezes iniciando uma reconstrução. Eu tive o mesmo problema em três máquinas separadas (mesma configuração).

Existe uma maneira simples de evitar esses tempos de inatividade? O disco com defeito em si não me incomoda muito (todos eles estão funcionando sem parar por alguns anos), mas o tempo de inatividade resultante me incomoda. Fiquei com a impressão de que o ataque 1 manteria o sistema funcionando mesmo quando um disco rígido estivesse falhando. Não haveria problema se o controlador de ataque apenas chutasse o disco da matriz e o sistema continuasse funcionando. Melhor ainda seria se tentasse resolver os problemas em segundo plano, sem congelar. Alguma degradação de desempenho também não seria problema, desde que o sistema permaneça operável.

Aqui está uma entrada de registro de amostra de um evento como esse:

Nov 14 14:00:10 xxxx kernel: [2137088.775542] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov 14 14:00:10 xxxx kernel: [2137088.788591] ata2.00: irq_stat 0x40000001
Nov 14 14:00:10 xxxx kernel: [2137088.801879] ata2.00: failed command: READ DMA EXT
Nov 14 14:00:10 xxxx kernel: [2137088.814988] ata2.00: cmd 25/00:80:d1:b9:89/00:00:16:00:00/e0 tag 0 dma 65536 in
Nov 14 14:00:10 xxxx kernel: [2137088.814991]          res 51/40:00:d3:b9:89/00:00:16:00:00/e0 Emask 0x9 (media error)
Nov 14 14:00:10 xxxx kernel: [2137088.867197] ata2.00: status: { DRDY ERR }
Nov 14 14:00:10 xxxx kernel: [2137088.880205] ata2.00: error: { UNC }
Nov 14 14:00:10 xxxx kernel: [2137088.906336] ata2.00: configured for UDMA/133
Nov 14 14:00:10 xxxx kernel: [2137088.906345] sd 1:0:0:0: [sdb] Unhandled sense code
Nov 14 14:00:10 xxxx kernel: [2137088.906347] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov 14 14:00:10 xxxx kernel: [2137088.906351] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
Nov 14 14:00:10 xxxx kernel: [2137088.906356] Descriptor sense data with sense descriptors (in hex):
Nov 14 14:00:10 xxxx kernel: [2137088.906358]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Nov 14 14:00:10 xxxx kernel: [2137088.906367]         16 89 b9 d3 
Nov 14 14:00:10 xxxx kernel: [2137088.906371] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
Nov 14 14:00:10 xxxx kernel: [2137088.906376] sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 16 89 b9 d1 00 00 80 00
Nov 14 14:00:10 xxxx kernel: [2137088.906385] end_request: I/O error, dev sdb, sector 378124755
Nov 14 14:00:10 xxxx kernel: [2137088.919172] ata2: EH complete

Esta é a configuração do raid (cat / proc / mdstat):

Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] [linear] [multipath]
md2 : active raid1 sda3[0] sdb3[1]
      726266432 blocks [2/2] [UU]

md1 : active raid1 sdb2[1] sda2[0]
      2104448 blocks [2/2] [UU]

md0 : active raid1 sdb1[1] sda1[0]
      4200896 blocks [2/2] [UU]

unused devices: <none>

Muito obrigado antecipadamente!

    

Answer 1

Você está usando o software RAID. Você não tem um "controlador RAID" para "chutar o disco da matriz". Em vez disso, você tem o kernel gerenciando os controladores ATA, e quando os discos não respondem (porque eles estão tendo erros de mídia, neste caso) o kernel aguarda. Esse tipo de situação nem sempre cria sintomas visíveis, mas certamente pode.

O mais simples é usar um controlador RAID de hardware. Mesmo assim, sempre há uma chance de que falhas estranhas possam criar um sintoma visível, mas é muito menos provável. Um controlador RAID de hardware real terá uma chance muito maior de manter a máquina responsiva mesmo em caso de erros de mídia.