Hoy toca verificar el estado de los discos de un servidor CentOS 6 que en nuestro ejemplo, cuenta con un RAID 1 software con 2 discos SATA de 3TB cada uno. Para ello, lo primero que podemos hacer es asegurarnos de qué discos tiene nuestro servidor, con un simple df -h para ver las particiones y verificar como todas son del estilo «mdX» lo cual nos indica que se trata de un RAID software:
[root@myServer]# df -h
S.ficheros Size Used Avail Use% Montado en
/dev/md5 1,1T 81G 908G 9% /
[…]
Podemos verificar el estado del RAID con:
[root@myServer]# cat /proc/mdstat
Personalities : [raid1]
md5 : active raid1 sdb7[1] sda7[0]
[…]
Aquí observamos como por ejemplo, md5 está activo, y tiene un RAID1 entre sdb7 y sda7.
Con fdisk podemos ver si el servidor dispone de más discos, además de los que hemos observado a simple vista:
[root@myServer]# fdisk -l
Disco /dev/sdb: 3000.6 GB, 3000592982016 bytes
[…]
Disco /dev/sda: 3000.6 GB, 3000592982016 bytes
[…]
Además, el fdisk nos mostrará las particiones de cada disco, así como las particiones del tipo «mdX». En nuestro caso, fdisk confirma que únicamente contamos con 2 discos, sda y sdb.
Pasemos, pues, a analizar la integridad de ambos discos con SMART.
SMART Monitor Tools
Con S.M.A.R.T. podemos verificar el estado de los discos. Si no tenemos instaladas las tools, podremos hacerlo mediante yum
[root@myServer]# yum install smartmontools.x86_64
Una vez instaladas, podremos verificar si los discos tienen soporte SMART con:
[root@myServer]# smartctl -i /dev/sda
[…]
SMART support is: Available – device has SMART capability.
SMART support is: Enabled
Para los tests de salud de los discos, SMART ofrece tres tipos de test. Con la opción «-c» obtendremos los tests disponibles en el disco, así como una estimación de cuanto durará cada test.
[root@myServer]# smartctl -c /dev/sda
[…]
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 330) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
Así pues, podemos ejecutar los tests de integridad, con:
[root@myServer]# smartctl -t short /dev/sda
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-2.6.32-358.2.1.el6.x86_64] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: «Execute SMART Short self-test routine immediately in off-line mode».
Drive command «Execute SMART Short self-test routine immediately in off-line mode» successful.
Testing has begun.
Please wait 1 minutes for test to complete.
Test will complete after Thu Jun 6 12:13:53 2013Use smartctl -X to abort test
Al ejecutar el test, volveremos al a terminal, pero el test nos indicará la fecha y hora en la que el test finalizará. Hasta entonces, no podremos ver los resultados. Cambiaremos «short» por «long» o «conveyance» según el tipo de test que queramos ejecutar. Los tres tipos de tests se pueden ejecutar con el sistema ejecutando las operaciones normales, es decir, no necesitamos desmontar el disco ni tener los servicios del sistema interrumpidos. Seguramente sea buena idea ejecutar los 3 tests si se quiere tener la mayor información posible del estado de los discos.
Una vez se haya completado el test (hayamos llegado a la hora indicada), podremos ver los resultados, con tres comandos.
La opción «-H» nos mostrará en una palabra si el disco ha pasado o no los tests.
[root@myServer]# smartctl -H /dev/sda
La opción «-l selftest» mostrará un listado de los testeos realizados y los errores encontrados.
[root@myServer]# smartctl -l selftest /dev/sda
Finalmente, la opción «-a» mostrará toda la información, incluyendo información más detallada.
[root@myServer]# smartctl -a /dev/sda
NOTA: Podremos ejecutar tests en diferentes discos, de forma simultánea, pero no recomendaría ejecutar más de un test de forma simultánea en el mismo disco.
Interpretación de los resultados
Una vez llegada la hora de finalización de los tests, podremos repasar el informe de resultados, el cual no es tan sencillo de analizar como pudiera parecer. Analizaremos ahora alguna de las sección del resultado con la opción «-a». Por ejemplo:
En la anterior imagen vemos una sección del report de estado de un disco. Vemos que la columna «WHEN_FAILED» no tiene ningún valor, lo cual significa que ninguno de los atributos ha fallado. Las columnas «VALUE», «WORST» y «THRESH» muestran valores normalizados entre 1 y 253, que varían según las especificaciones del fabricante.
La columna «TYPE» muestra el tipo de atributo, el cual puede tomar únicamente dos valores: «Pre-fail» o «Old age«. Los atributos de tipo «Pre-fail» indicarán que puede haber un fallo de disco, si sus valores en «VALUE» son menores o iguales que el valor indicado en «TRESH». El hecho de que el atributo sea de tipo «Pre-fail» no significa que esté a punto de fallar, ésto únicamente sería así si el valor de VALUE fuera, como se ha dicho, igual o inferior al TRESH. Los atributos de tipo «Old age», son atributos que variarán con el tiempo y el uso normal del disco. Indicarán «en-of-product life» cuando el valor de VALUE sea inferior o igual al TRESH, pero no será indicativo de que vaya a fallar. [Fuente: man opción –A, -atributes].
Otra sección en la que fijarse, es en la sección de errores ATA:
SMART Error Log Version: 1
ATA Error Count: 6 (device log contains only the most recent five errors)
Si el «ATA Error Count» es mayor que 0, entonces a continuación se mostrarán los últimos 5 errores encontrados, que podrían ser como el que sigue:
Error 6 occurred at disk power-on lifetime: 5198 hours (216 days + 14 hours)
When the command that caused the error occurred, the device was active or idle.After command completion occurred, registers were:
ER ST SC SN CL CH DH
— — — — — — —
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
— — — — — — — — —————- ——————–
60 00 80 ff ff ff 4f 00 28d+19:18:34.860 READ FPDMA QUEUED
ef 10 02 00 00 00 a0 00 28d+19:18:34.859 SET FEATURES [Reserved for Serial ATA]
27 00 00 00 00 00 e0 00 28d+19:18:34.859 READ NATIVE MAX ADDRESS EXT
ec 00 00 00 00 00 a0 00 28d+19:18:34.859 IDENTIFY DEVICE
ef 03 46 00 00 00 a0 00 28d+19:18:34.859 SET FEATURES [Set transfer mode]
El número de errores que nos muestra esta sección, es acumulativo, es decir, cuenta todos los errores encontrados a lo largo de la vida del disco. De igual manera, los 5 últimos errores que muestra, los muestra indicando además cuando sucedieron (Error 6 occurred at disk power-on lifetime: 5198 hours (216 days + 14 hours)). Anteriormente hemos podremos ver el valor «Power_On_Hours» en la columna «RAW_VALUE» para saber las horas de uso del disco, y poder así compararlo con cuando ocurrieron los últimos errores:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
9 Power_On_Hours 0x0032 094 094 000 Old_age Always – 5486
He leído aquí, que es normal que un disco tenga algún error a lo largo de su vida, como simple consecuencia del uso normal del mismo, y que no es extraño ver valores por debajo de 100 en este «ATA Error Count», sin que ésto signifique que hemos de reemplazar el disco. Imagino que si sumásemos los resultados de las horas de vida del disco, los atributos que han fallado (con valor en WHEN_FAILED) y/o atributos anómalos o contando un número de errores elevado, el propio SMART no nos devolvería un «PASSED»:
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Así pues, 6 errores en las 5471 horas de vida del disco (no llega a 8 meses), sin más problemas ni atributos con fallos, debería indicar que no hay ningún problema con el disco.
Fuentes:
https://wiki.archlinux.org/index.php/S.M.A.R.T.
http://www.linuxjournal.com/node/6983/print
http://forums.cpanel.net/f5/s-m-r-t-drive-failure-48627.html
Foto por Alpha six