Un problema que suele ocurrir con mayor frecuencia que la esperada, es la rotura de un disco rígido en un servidor. El día más temido por todo SysAdmin improvisado. Sin embargo, los SysAdmins semi-decentes utilizamos arreglos de discos en alguna configuración RAID (1, 5 10, RAIDZ, o por software en sistemas Linux). Ahora bien, supongamos que se rompió un disco y hay que cambiarlo, ¿cómo identificar el disco físico fallido asociado al dispositivo en cuestión? Este artículo explica la técnica correcta y menciona otras, también válidas, y otras más un tanto extrañas.



Uno de nuestros servidores de archivos NFS reportó una falla en uno de los discos de su RAIDZ:

root@fbsd10:~ # zpool list
NAME     SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zroot   3.59T  2.01T  1.58T         -    30%    56%  1.00x  DEGRADED  -
root@fbsd10:~ # zpool status zroot
  pool: zroot
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://illumos.org/msg/ZFS-8000-2Q
  scan: scrub repaired 0 in 2h50m with 0 errors on Mon Mar 20 18:52:36 2017
config:

        NAME                      STATE     READ WRITE CKSUM
        zroot                     DEGRADED     0     0     0
          raidz1-0                DEGRADED     0     0     0
            gpt/zfs0              ONLINE       0     0     0
            gpt/zfs1              ONLINE       0     0     0
            17822362725707917483  UNAVAIL      2     3     0  was /dev/gpt/zfs2
            gpt/zfs3              ONLINE       0     0     0

errors: No known data errors

Se observa que el pool sigue funcionando correctamente, pues cuenta con suficientes réplicas. De esto se trata justamente la redundancia de hardware y replicación de datos: poder sobrevivir a un fallo sin ocasionar pérdidas de datos ni caídas de servicios.

La cuestión es que el disco ha fallado, no se puede recuperar, y es necesario reemplazarlo. Revisando el log de mensajes del kernel, se puede deducir que se trata del dispositivo ada2:

root@fbsd10:~ # head /var/log/dmesg.yesterday
(ada2:ahcich2:0:0:0): Retrying command
(ada2:ahcich2:0:0:0): READ_DMA. ACB: c8 00 28 00 00 41 00 00 00 00 00 00
(ada2:ahcich2:0:0:0): CAM status: ATA Status Error
(ada2:ahcich2:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 10 (IDNF )
(ada2:ahcich2:0:0:0): RES: 51 10 28 00 00 41 01 00 00 00 00
(ada2:ahcich2:0:0:0): Retrying command
(ada2:ahcich2:0:0:0): READ_DMA. ACB: c8 00 28 00 00 41 00 00 00 00 00 00
(ada2:ahcich2:0:0:0): CAM status: ATA Status Error
(ada2:ahcich2:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 10 (IDNF )
(ada2:ahcich2:0:0:0): RES: 51 10 28 00 00 41 01 00 00 00 00

Se trata de un dispositivo SATA.

Existen diferentes alternativas para identificar qué disco físico corresponde con cada dispositivo, pero la más precisa consiste en identificarlo a través de su número de serie, el cual se encuentra impreso en el chasis del disco rígido.

Identificar un disco rígido a través de su número de serie

Para obtener el número de serie (serial number) del dispositivo desde línea de comandos se puede recurrir a la herramienta camcontrol. Esta permite además listar todos los discos conectados:

root@fbsd10:~ # camcontrol devlist
<WDC WD10EARX-00N0YB0 51.0AB51>    at scbus0 target 0 lun 0 (ada0,pass0)
<WDC WD10EARX-00N0YB0 51.0AB51>    at scbus1 target 0 lun 0 (ada1,pass1)
<WDC WD10EARX-00N0YB0 51.0AB51>    at scbus2 target 0 lun 0 (ada2,pass2)
<WDC WD10EARX-00N0YB0 51.0AB51>    at scbus3 target 0 lun 0 (ada3,pass3)
<HL-DT-ST BD-RE  BH10LS38 1.00>    at scbus4 target 0 lun 0 (pass4,cd0)
<AHCI SGPIO Enclosure 1.00 0001>   at scbus6 target 0 lun 0 (pass5,ses0)

El número de serie para el caso de discos ATA/SATA se obtiene con el subcomando identify (inquiry para el caso de discos SCSI):

root@fbsd10:~ # camcontrol identify ada2 | grep serial
serial number         WD-WMC0S0532489

Otro método para obtener el número de serie consiste en examinar los mensajes de inicio del kernel de FreeBSD:

root@hal9000:/usr/home/emi # grep 'ada[0-9]' /var/log/dmesg.today
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0: <WDC WD5000AAKX-001CA0 15.01H15> ATA8-ACS SATA 3.x device
ada0: Serial Number WD-WCAYUU316558
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 476940MB (976773168 512 byte sectors)
Trying to mount root from ufs:/dev/ada0s1a [rw]...

Ahora basta con abrir la carcasa del servidor e identificar el disco rígido fallido examinando la etiqueta del fabricante.

Otros métodos

Muchos de los fabricantes de hardware más importantes incluyen un LED exclusivo para cada bahía. Estos LEDs identifican cada disco y es posible encenderlos por software. Esta es una forma muy práctica y sencilla, pero claro, depende del fabricante. Si nuestro servidor no cuenta con esta funcionalidad, se deberá recurrir al método del número de serie. Para los sistemas GNU/Linux existe el utilitario ledmon/ledctl desarrollado por Intel.

Una técnica un tanto más precaria consiste en generar una gran cantidad de actividad sobre el disco (por ejemplo, leer todo su contenido y enviarlo a /dev/null, utlizando dd) y luego examinar cuál de los LEDs de actividad es el que permanece encendido. Por supuesto se requiere que exista un led de actividad para cada disco, y se realice en un momento de baja actividad (sino será imposible distinguirlo).

La alternativa más extrema y peligrosa consiste en tirar del cable SATA de cada disco, de a uno por vez, y ver cuál desaparece de la salida de camcontrol. Esto es posible gracias a la característica de hot plug/hot swap de los dispositivos SATA (siempre que el motherboard sea compatible con dicha característica). Sin embargo esto puede provocar daños a nivel filesystem. Por más loco que parezca he leído que muchos mencionan esta técnica como una posibilidad. Yo no lo recomendaría en absoluto, y me parece mucho menos dañino utilizar el número de serie.

Referencias

  • man camcontrol


Tal vez pueda interesarte


Compartí este artículo