Los arreglos RAID5 pueden fallar gravemente: un ejemplo

De vez en cuando, en alguna conversación técnica casual tengo que dar el consejo "los arreglos RAID pueden fallar", y me encuentro con la respuesta habitual de "usamos RAID5 / RAID6, es infalible". Y ahí suelo contar que según había visto largo tiempo atrás en varios posteos en la red y algun libro por ahí, argumentar que un arreglo RAID5 incluso un RAID6 como infalible está lejos de la realidad. 

Pero casi siempre que no estoy explicando este caso puntual en relación con mis propios servers / infraestructura (caso en el que típicamente ya dí un buen repaso al background técnico por cierto), se me escapa la explicación detallada y/o el posteo puntual (largo tiempo atrás perdido en mis bookmarks). Así que al final les dejo un ejemplo (de la vida real al parecer), paso a paso cómo puede ocurrir una falla grave en arreglos RAID5 (y también qué pasaría en un RAID6 en el mismo ejemplo). 


Tips extrapolados del artículo/ejemplo

Tip 1: los RAID5 o 6 con discos de más de 2-3 años de uso no son fiables para los rebuild que ocurren en el evento de falla de un disco, y pueden desencadenar un falla en cascada del arreglo completo.

Tip 2: los discos de un arreglo RAID5 en un servers suelen ser del mismo fabricante y de similar fecha de fabricación, por ende sus tiempos estimados de fallas son muy similares, es decir, hay una probabilidad inusualmente alta - para un RAID - de que fallen varios discos simultáneamente.

Tip 3: es un tanto espeluznante leer cómo el autor - con cierta experiencia - comenta sobre la realidad de las particularidades técnicas - cuasi-aleatorias en su comportamiento incluso - de las controladoras RAID de nivel industrial, y cómo pueden manejar determinados eventos - fallos - técnicos, yendo tanto a "izquierda" como a "derecha" según la visión del fabricante en su implementación del RAID. Leer las especificaciones técnicas y manuales de las controladoras RAID es mandatorio (para conocer y tunear parámetros que tiendan a la mayor resiliencia del arreglo en nuestro escenario puntual de implementación).

Tip 4: La "solución" para solventar el problema de haber montado un RAID5 (o 6 inclusive recordemos), en discos viejos de la misma marca y similar fecha de fabricación (y con chance elevada de fallo simultáneo), es ir reemplazandolos con discos nuevos, es decir, provocar rebuilds del arreglo (justamente lo que sabemos dispara las probabilidades de fallo del RAID en discos viejos).

Tip 5: Luego del #4 es momento de conocer ahora la estrategia técnica ganadora que implementan las organizaciones que prefieren - a mayor costo claro - garantizar (difiere de "elevar"), la resiliencia de los datos: hacer que estos sean res/guardados en filesystems distribuídos y/o tener réplicas - automáticas, continuas, de algun modo, en alguna capa de la infraestructura, configuradas - de los datos en otro medio físico, por ej. otro replicando hacia un arreglo en otro server físico, un volúmen de una SAN atachado a otro server ( o al mismo que tiene el RAID5), etc. etc.
En la wikipedia se explayan un poco al respecto también:
http://en.wikipedia.org/wiki/RAID#Problems_with_RAID_5_in_enterprise_environments

Vale la pena citar este comentario de la misma entrada y su link asociado:

"As of August 2012, Dell, Hitachi, Seagate, Netapp, EMC, HDS, SUN Fishworks and IBM have current advisories against the use of RAID 5 with high capacity drives and in large arrays"

^ Mikko Peltoniemi (2012-08-07) "New RAID level recommendations from Dell".


Conclusiones
Como dije al principio, los RAID5 ( y los RAID6 en circunstancias graves similares, también) pueden fallar, de hecho la probabilidad de un fallo catastrófico es alta dados ciertos parámetros (discos viejos especialmente).

La recomendación técnica realista es apuntar a deployar arreglos RAID6 (este con cierta menos chance de fallos respecto al 5), o RAID10 (muchas mejores chances de evitar fallos masivos).


RAID10
http://en.wikipedia.org/wiki/Nested_RAID_levels#RAID_1.2B0


En lo particular, siempre intento planificar suficientes medidas DR (Disaster Recovery), para no tener que depender de ningun RAID5 (ni 6, ni 10 si fuera el caso), que puede esta funcionando perfectamente hoy (sin ningun tipo de alertas en los monitores de hardware configurados), pero mañana puede desaparecer sin previo aviso (y no solamente hay que recurrir a los backups para restaurar los datos, sino que hay que "conseguir" otro espacio de storage donde poder volcarlos, inclusive otro server).

Tip 6 (conclusivo): Aprende a apegarte al uso de replicación y clustering (y filesystems distribuídos si tu arquitectura te lo permite) - independientemente de en qué capa de la infraestructura se implemente - donde sea que tu última salvaguarda - un SPOF por cierto - para mantener activo un servicio sea un arreglo RAID (5/6/10). El mediano/largo plazo devuelven la inversión con creces. Incluso una implementación progresiva - primero el RAID+backup, solo; luego +replicación/clustering), es mucho más positiva que dejar el RAID a su suerte a largo plazo.


El ejemplo prometido:

How multi-disk failures happen

http://sysadmin1138.net/mt/blog/2012/12/how-multi-disk-failures-happen.shtml