Esta sección trata sobre la vida con un sistema RAID por software, veremos como podemos comunicarnos con los arrays y cómo podemos trastear con ellos.
Es importante seņalar que cuando se trata de manipular dispositivos RAID, deberíais siempre de tener presente que estáis trabajando con sistemas de archivos enteros. Ante eso siempre hay que extremar las precauciones.
Sin misterios. Basta con echar un vistazo rápido a los logs habituales
para percatarse de que ha fallado un disco.
Cuando un disco falla, /var/log/messages revelará varios
errores del núcleo. Algunos ejemplos, para los masocas:
kernel: scsi0 channel 0 : resetting for second half of retries. kernel: SCSI bus is being reset for host 0 channel 0. kernel: scsi0: Sending Bus Device Reset CCB #2666 to Target 0 kernel: scsi0: Bus Device Reset CCB #2666 to Target 0 Completed kernel: scsi : aborting command due to timeout : pid 2649, scsi0, channel 0, id 0, lun 0 Write (6) 18 33 11 24 00 kernel: scsi0: Aborting CCB #2669 to Target 0 kernel: SCSI host 0 channel 0 reset (pid 2644) timed out - trying harder kernel: SCSI bus is being reset for host 0 channel 0. kernel: scsi0: CCB #2669 to Target 0 Aborted kernel: scsi0: Resetting BusLogic BT-958 due to Target 0 kernel: scsi0: *** BusLogic BT-958 Initialized Successfully ***Y más frecuentemente,
kernel: sidisk I/O error: dev 08:01, sector 1590410 kernel: SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 28000002o también
kernel: hde: read_intr: error=0x10 { SectorIdNotFound }, CHS=31563/14/35, sector=0
kernel: hde: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Y, como es de esperar, /proc/mdstat revelará la presencia de problemas,
Personalities : [linear] [raid0] [raid1] [translucent] read_ahead not set md7 : active raid1 sdc9[0] sdd5[8] 32000 blocks [2/1] [U_]Luego aprenderemos a monitorizar RAID con mdadm de forma que nos envíen informes de alerta sobre fallos en disco. Ahora lo que procede es aprender más sobre el formato de
/proc/mdstat.
Podéis mirar siempre lo que hay en /proc/mdstat. No duele. Aprendamos a
interpretar sus contenidos. Por ejemplo.
Personalities : [raid1]
read_ahead 1024 sectors
md5 : active raid1 sdb5[1] sda5[0]
4200896 blocks [2/2] [UU]
md6 : active raid1 sdb6[1] sda6[0]
2104384 blocks [2/2] [UU]
md7 : active raid1 sdb7[1] sda7[0]
2104384 blocks [2/2] [UU]
md2 : active raid1 sdc7[1] sdd8[2] sde5[0]
1052160 blocks [2/2] [UU]
unused devices: none
Para identificar los dispositivos libres, buscad el primer valor [#/#]
de una línea. El primer número es el número que define el número de
dispositivos para un RAID completo. Digamos que es "n".
El numero de posición [#] que viene a después de cada uno de los
dispositivos integrantes indica la situación que ocupa dentro del
conjunto. Los dispositivos con "n" o más son los discos libres,
mientras que 0,1,...,n-1 son los dispositivos que están trabajando
en el array.
Si hay un dispositivo erróneo, el disco roto estará marcado con una (F) después del [#]. El disco libre que reemplace a este disco erróneo será el dispositivo con el número de posición n o superior que no esté marcado como defectuoso (F). Una vez la operación de resincronización se termina, los números de posición de los dispositivos cambian.
Ah, y el orden en que aparecen los dispositivos RAID en /proc/mdstat
no importa.
Por último, recordad que siempre podéis usar las raidtools o mdadm para consultar con detalle los arrays:
mdadm --detail /dev/mdx
lsraid -a /dev/mdx
Estos comandos dejan bien claro en que situación se encuentra cada
dispositivo en todo momento.
Si estáis planeando usar RAID para obtener tolerancia a fallos, es buena idea que comprobéis que vuestra configuración funciona correctamente, no sea que tengáis alguna sorpresa desagradable en el momento menos oportuno. El tema es, ¿cómo se las apaņa uno para simular el fallo de un disco?
Pues mirad, uno no se las apaņa. No se puede simular el fallo de un disco si no es dándole al pobre trasto un buen hachazo mientras rueda.
Esto puede parecer de locos, pero la verdad es que no es posible saber qué es exactamente lo que pasará cuando un disco duro se nos muere de la misma forma que no es posible saber qué es exactamente lo que pasará cuando un coche deje de funcionar. El fallo de un chisme tan complicado como es un disco duro moderno puede deberse a miles de motivos distintos (calor, erosión mecánica, exceso en las presiones magnéticas soportadas, fallo en el suministro de intensidades eléctricas... todo a la vez...) y adoptar miles de comportamientos distintos. Podría ser que un fallo eléctrico se propagara a través de todo el bus, alcanzando a todos los dispositivos conectados a él. Y también podría ser que el dispositivo sencillamente informara a la controladora de un error de entrada/salida, lo cual pondría en marcha los resortes que hacen que la capa RAID gestione estas situaciones correctamente. Y eso es lo que pretendemos al usar RAID, y eso es lo que suele suceder, afortunadamente.
En fin, que se han tomado medidas y realizado esfuerzos para que todo salga bien cuando un miembro de vuestros conjuntos RAID falle, pero RAID no es La Virgen de Lourdes. RAID no hace milagros y no puede resolver situaciones catastróficas. Es vuestra decisión apostar por RAID o no cuando os enfrentéis a la necesidad de aportar un determinado nivel de tolerancia a errores, y deberéis de asumir las consecuencias de vuestros actos por vosotros mismos.
Dicho esto, vamos con lo de simular fallos. Recordad, solamente RAID 1,5 y 5 aportan tolerancia a errores. Los modos 0 y lineal no sobreviven cuando un disco se rompe.
Si queréis simular el fallo de un disco, podéis, sencillamente, desenchufarlo. Sólo hay que apagar el equipo y desconectar los cables que alcanzan el dispositivo que queráis usar como cobaya. Ni se os ocurra hacer esto mientras el sistema está funcionando, podríais quemar varios componentes de vuestro ordenador. Sólo apagad la máquina, desenchufadla, desconectad ese disco y entonces, si, arrancáis de nuevo.
Cuando hayáis arrancado el sistema, observad los logs y echad un
vistazo a /proc/mdstat para ver cómo le va al array. ¿Ha funcionado?
¿Tenéis ahora un array "cojo"?
Los discos erróneos deberían de aparecer marcados con un (F)
mi miráis /proc/mdstat. Además, los usuarios de mdadm veréis al dispositivo
marcado con un faulty. Repasad lo que hemos dicho aquí en la
sección de consultas de estado, hace sólo unas pocas líneas.
Bien, y ahora apagad el ordenador, volved a conectar el disco y
arrancad de nuevo. Podréis, entonces, aņadir de nuevo el disco
cobaya usando el comando raidhotadd.
Aquí es donde vamos a divertirnos. Las nuevas versiones de las raidtools
incorporan el comando raidsetfaulty, que nos permitirá simular
el fallo de un disco sin tener que desenchufar nada ni reiniciar el
sistema.
Hale, forzamos el fallo de un disco sin más,
raidsetfaulty /dev/md1 /dev/sdc2
y eso hace el disco /dev/sdc2 falle en el array /dev/md1.
El equivalente a esto en mdadm es
mdadm --manage --set-faulty /dev/md1 /dev/sdc2
Ahora veréis esto el los logs del sistema,
kernel: raid1: Disk failure on sdc2, disabling device.
y esto si tenéis algún disco libre en la reserva
kernel: md1: resyncing spare disk sdb7 to replace failed disk
Si miráis ahora /proc/mdstat veréis cómo le va al array, que ahora es un
array degradado. Y ahí también veréis si ha empezado la reconstrucción
en algún disco libre que tengáis.
Otra herramienta maja de las nuevas raidtools es lsraid.
Probad esto,
lsraid -a /dev/md1
los que tengáis mdadm, el equivalente a ese comando es esto de aquí,
mdadm --detail /dev/md1
y ahora es cuando tanto los unos como los otros podéis disfrutar de
la visión de vuestro sistema soportando un fallo en disco.
Y ahora que hemos visto cómo es cuando falla un disco, vamos a arreglar las cosas y dejarlo todo como estaba.
Lo primero es sacar el disco erróneo del conjunto RAID. Al fin y al cabo, en este estado no aporta nada al array. Ejecutad este comando
raidhotremove /dev/md1 /dev/sdc2
Es importante no perder de vista el hecho de que raidhotremove
no es capaz de sacar un disco válido de un array en marcha. Por
razones obvias, sólo los discos erróneos pueden arrancarse del
array (¡ejecutar raidstop o similares en el array y desmontar
entonces el dispositivo no os ayudará!).
Bien, lo que tenéis ahora es un /dev/md1 en el que falta un dispositivo. Terminamos ya, devolviendo ahora a /dev/sdc2 de vuelta a casa.
raidhotadd /dev/md1 /dev/sdc2
o, con mdadm,
mdadm /dev/md1 -a /dev/sdc2
y podemos ver, ahora, como el hijo pródigo vuelve a casa, tal vez
reincorporándose a /dev/md1 cómo un elemento activo del conjunto o
(si su antiguo lugar ya fue ocupado por un disco de reserva en su
momento y después de ejecutar raidsetfaulty) tal vez como
un disco libre.
Un sistema RAID (ya sea hardware o software) asume que si una escritura en disco no devuelve un error, entonces es que ha tenido éxito. Por tanto, si vuestro disco corrompe datos (escribe algo diferente a lo que le han pedido que escriba) sin devolver un error, los datos del array se verán comprometidos también. Es muy improbable que algo así os ocurra, pero es posible, y la verdad es que como resultado, os quedaría un lamentable sistema de ficheros corrupto.
Un sistema RAID no puede y no está pensado para garantizar la integridad de datos de vuestro medio de almacenaje. Por tanto, tampoco tiene ningún sentido corromper a propósito los datos de un disco (usando dd, por ejemplo) para ver cómo resolverá el sistema RAID esa situación. Es más probable (¡a menos que corrompáis el superbloque del RAID!) que la capa RAID no descubra nunca que sus ficheros se han intervenido, vulnerando así la integridad de datos del sistema. Al final de todo eso os quedáis con que el sistema de ficheros contenido en el dispositivo RAID cuya integridad habéis violado queda corrupto. Simplemente.
Así es como se supone que funcionan las cosas. Un RAID, insistimos, no es una garantía para la integridad de datos, simplemente os permite conservar vuestros datos si un disco muere (naturalmente, con RAIDs de niveles iguales o superiores a 1).
Podéis ejecutar mdadm como demonio, solo hay que usar el modo de
seguimiento (follow-monitor). Si se tercia la ocasión, eso
hará que mdadm envíe alertas al administrador del sistema cuando los
arrays detecten errores o fallen. Además, el modo de seguimiento
puede utilizarse para desatar planes de contingencia en caso de que
un disco falle.
Veamos un ejemplo básico.
mdadm --monitor --mail=root@localhost --delay=1800 /dev/md2Esto pone a un demonio mdadm a vigilar a /dev/md2. Las alertas administrativas se librarán contra root@localhost. Los chequeos se sucederán en intervalos de 1800 segundos.
También tenéis que recordar a los parámetros como --program
o --alert, que se usan para especificar el programa que
queráis ejecutar en caso de que suceda un evento.
También es importante mencionar que el demonio mdadm no terminará su ejecución mientras hayan arrays que monitorizar, así que deberiáis de ejecutarlo como un proceso de fondo... estáis lanzando un demonio, no un comando del shell. Usad el ampersand final y un bonito nohup:
nohup mdadm --monitor --scan --daemonise --mail=root@localhost /dev/md0 /dev/md1 &Usar mdadm para monitorizar un array RAID es simple y efectivo. Aun así, es evidente que es una forma de monitorizar que también tiene sus problemas. ¿Qué pasa, por ejemplo, si el demonio mdadm se detiene? Para poder sacar adelante problemas como ese, es buena idea que consultéis soluciones de monitorización "reales". Hay varias soluciones (tanto libres como comerciales) disponibles que podéis usar para monitorizar vuestros arrays de RAID por software sobre Linux. Una búsqueda en FreshMeat basta para encontrar varios ejemplos.