RAID 1 y RAID 5 (y sus hermanos 10 y 50) logran la redundancia de datos respectivamente a través de la duplicación y la verificación de paridad. Esto permite que una matriz RAID siga accediendo a datos cuando un sector en un disco (o un disco completo) se vuelve ilegible. RAID 6 (o 60) utiliza una verificación adicional para permitir fallas dobles.
Pero, ¿cómo puede una matriz RAID manejar datos que no son completamente ilegibles, sino simplemente inconsistentes?
Si se produce un error tal que los datos de fe en una banda se cambian en un disco pero el cambio no se propaga a la (s) otra (s), la banda completa se volvería inconsistente. Si en un conjunto reflejado un disco dice "este bit es 0" mientras el otro disco dice "este bit es 1", ¿cómo puede un controlador RAID saber cuál es el correcto? El mismo razonamiento podría aplicarse a una banda RAID-5, con la complejidad adicional de que no puede saber fácilmente qué sector está realmente mal en la banda. Además, ¿RAID 6 mitiga este problema con sus dobles verificaciones, o aún puede tener problemas para recuperarse de la corrupción de datos cuando los datos son realmente legibles pero están mal en alguna parte, especialmente porque las matrices RAID 6 tienden a tener muchos discos?
En teoría, esto podría resolverse mediante sumas de verificación, para garantizar qué copia de los datos (o paridad) es la correcta; pero, ¿algún controlador RAID implementa realmente este tipo de suma de verificación (que por supuesto ocuparía espacio adicional)? ¿O necesita ser manejado a nivel del sistema operativo, donde la mayoría de los sistemas de archivos pueden y sumarán su contenido? Y si este es el caso, ¿cómo pueden decirle al controlador RAID que "los datos en el sector X en el disco Y en la banda Z son incorrectos", cuando el enfoque general de un controlador RAID es abstraer el sistema operativo de la capa de almacenamiento subyacente tanto como sea posible? ¿posible?
fuente
Respuestas:
En los controladores Areca que utilizamos (y todos los controladores RAID de hardware modernos) durante una comprobación de coherencia, el controlador puede detectar si la corrupción está relacionada con los datos de paridad, los datos físicos en el disco o ambos. La mayoría de los controladores logran esto con simples bits de suma de verificación para los datos de paridad y los datos en el disco.
En el caso de que los datos de paridad estén dañados, el controlador notará el problema cuando ejecute una comprobación de consistencia y vuelva a leer el disco físico para los bits correctos y vuelva a escribir la banda de paridad. Los usuarios no verán problemas porque están leyendo datos en el disco al abrir los archivos. Volver a guardar cualquier cosa que haga que se vuelva a escribir la banda de paridad corrupta también solucionará el problema.
Si ocurre lo contrario, y un poco se voltea en sus datos reales en el disco, entonces su controlador observará la franja de paridad durante una verificación de consistencia para ver si ha cambiado. En este caso, el controlador sobrescribirá los datos en el disco para que coincidan con los datos de paridad, lo que puede confirmar que no ha cambiado / es bueno. Los usuarios recibirán un error de CRC o un archivo dañado dependiendo de los datos hasta que se ejecute una comprobación de coherencia y corrija el error.
Dado que los datos de paridad para datos específicos en el disco nunca se almacenan en la misma unidad que los datos reales, un solo fallo en la unidad no debería causar ningún problema de corrupción de datos. O dos discos para RAID6, etc.
Las verificaciones de consistencia mantienen sus datos lo más precisos posible y si deja que los datos corruptos se asienten en su volumen durante el tiempo suficiente, podrían escribirse en datos de paridad, lo que significa que el archivo está dañado para siempre y deberá restaurarse desde una copia de seguridad. Si una unidad se encuentra en un estado previo al fallo donde muestra errores durante las comprobaciones de coherencia, reemplace la unidad inmediatamente en lugar de esperar a que el controlador la marque como fallida. Realizamos comprobaciones de consistencia diariamente en volúmenes más pequeños y semanalmente en volúmenes más grandes.
El controlador / firmware del disco duro puede corregir el problema. Si esto no es posible, el controlador RAID tendrá dificultades para solucionar el problema. En este caso, probablemente tendría que leer las unidades individualmente para recuperar los datos.
Ejecute comprobaciones de coherencia en el intervalo recomendado por su tarjeta RAID mfg. Si realmente le preocupa la corrupción, también puede apilar un sistema de archivos resistente sobre un volumen RAID. Los sistemas de archivos resistentes modernos pueden corregir muchos de estos problemas de integridad de datos y apilar un FS resistente sobre RAID6 le ofrecería un excelente tiempo de actividad de datos, sin corrupción. E incluso con 2 fallas simultáneas en la unidad, aún tendría datos de paridad FS disponibles para evitar presentar datos corruptos al usuario.
fuente
Describe efectivamente la situación, donde un disco escribe (o lee) un error. El controlador RAID no tiene una forma práctica (por ejemplo, escribir y volver a leer mataría su rendimiento) para protegerse contra esta situación. Tiene que confiar en que los discos puedan detectar este tipo de error y utilizar un bloque diferente o rescatar el volumen, lo que provocará una degradación del RAID.
Si piensa en la situación de un solo disco, la única protección contra escrituras (o lecturas) inconsistentes es el propio disco. RAID se basa en eso, pero no introduce una protección adicional.
Nota: sé por experiencia que XFS reacciona de forma bastante sensible a discos erróneos en una matriz. Por lo tanto, al menos mis controladores de gama baja y el sistema operativo reconocieron pero no protegieron contra esa inconsistencia (un disco con fallas conocidas se agregó con fuerza a un volumen).
fuente