Si un sistema RAID5 experimenta un URE durante la reconstrucción, ¿se pierden todos los datos?

23

Entiendo el argumento con respecto a la mayor probabilidad de que las unidades más grandes experimenten un URE durante una reconstrucción, sin embargo, no estoy seguro de cuáles son las implicaciones reales para esto. Esta respuesta dice que la reconstrucción completa falla, pero ¿significa esto que todos los datos son inaccesibles? ¿Por qué sería eso? Seguramente, un solo URE de un solo sector en la unidad solo afectaría los datos relacionados con algunos archivos, como máximo. ¿No se reconstruiría la matriz, solo con una pequeña corrupción en algunos archivos?

(Aquí estoy específicamente interesado en la implementación de RAID5 de ZFS, pero la lógica parece la misma para cualquier implementación de RAID5).

raid zfs zfsonlinux

— proceso91
fuente

1

En general, cuando se analiza "la probabilidad de experimentar un URE durante una reconstrucción " en el contexto de los riesgos RAID5, la suposición implícita es que ya se ha producido una corrupción anterior que hace que la reconstrucción sea necesaria. En otras palabras, el "URE durante la reconstrucción" es el segundo URE y, de hecho, TODOS los datos se perderán.

— Colt

1

@Colt: entiendo que esa es la implicación, pero lo que no entiendo es por qué una única URE (que, en el análisis de por qué no se recomienda RAID5, parece referirse a un sector defectuoso) significaría que todos los datos estar perdido. En general, si he perdido 1 unidad de una matriz RAID5, todavía tengo todos los datos. Si además pierdo un solo sector de cualquiera de las unidades restantes, es posible que haya perdido los datos almacenados en ese sector, pero si ese sector era (por ejemplo) espacio libre, entonces no me importa, y si ese sector si tenía datos, entonces solo puede afectar algunos archivos.

— proceso91

@Colt: según las respuestas a continuación, parece que no se pudo reconstruir la matriz en presencia de un único URE fue una elección realizada por los fabricantes de RAID de hardware. En mi opinión, esta fue la elección incorrecta, pero afortunadamente parece que ZFS lo hace de manera diferente.

— proceso91

Ver la respuesta de @ shodanshok para el proceso. En cuanto a por qué, RAID es para proporcionar continuidad de acceso a datos confiables para otros procesos, aplicaciones, etc., y no se trata de copias de seguridad. La razón por la cual muchos (¿la mayoría?) Controladores de hardware abortan una vez que se produce el URE en la reconstrucción es porque el RAID ya no puede hacer lo que se supone que debe hacer . En este punto, las copias de seguridad deben usarse para tener datos confiables. Otra forma de usar RAID es no hacer ninguna reconstrucción en absoluto, sino solo usar RAID para controlar el tiempo de recuperación de la copia de seguridad. Además, da tiempo para hacer la copia de seguridad final antes de la recuperación.

— Colt

Tenga en cuenta que la implementación de "ZFS 'de RAID5" se llama "raidz" o "zraid" y es diferente del hardware RAID5. Por lo general, obtendrá mejores respuestas sobre "ZFS RAID5" preguntando sobre "raidz"

— Josh

24

Realmente depende de la implementación RAID específica:

la mayoría de los RAID de hardware abortarán la reconstrucción y algunos también marcarán la matriz como fallida y la desactivarán. La razón es que si ocurre un URE durante una reconstrucción RAID5 significa que se pierden algunos datos , por lo que es mejor detener completamente la matriz en lugar de arriesgarse a la corrupción silenciosa de datos. Nota: algunos RAID de hardware (principalmente basados en LSI) perforarán la matriz, permitiendo que la reconstrucción continúe mientras se marca el sector afectado como ilegible (similar a cómo se comporta el RAID de software de Linux).
El software RAID de Linux puede recibir instrucciones de a) detener la reconstrucción de la matriz (el único comportamiento de las compilaciones "antiguas" MDRAID / kernels) o b) continuar con el proceso de reconstrucción marcando algunos LBA como defectuosos / inaccesibles. La razón es que es mejor dejar que el usuario haga su elección: después de todo, un único URE puede estar en el espacio libre, sin afectar los datos (o afectando solo los archivos sin importancia);
ZRAID mostrará algunos archivos como corruptos, pero continuará con el proceso de reconstrucción (vea aquí un ejemplo). Una vez más, la razón es que es mejor continuar e informar al usuario, lo que le permite tomar una decisión informada.

— shodanshok
fuente

@ process91 Solo para elaborar un poco más. Si la implementación de RAID no tiene las estructuras de datos adicionales necesarias para marcar sectores individuales como defectuosos, tiene que fallar la reconstrucción o introducir corrupción silenciosa. Marcar sectores individuales como malos es mejor, pero aún podría poner en riesgo a otros sectores debido a que comparten un sector de paridad con el sector malo.

— Kasperd

@kasperd Claro, supongo que asumí que la mayoría de las implementaciones RAID tenían la capacidad de alertar al usuario sobre sectores defectuosos. Entiendo si hay un sector defectuoso en una unidad que conducirá a un sector incorrecto en la nueva unidad después de una reconstrucción. Dicho esto, incluso si la implementación de RAID no hizo más que alertar al usuario "He reconstruido la unidad lo mejor que pude, pero experimenté 1 URE en el proceso" y luego seguí permitiendo intentos de escritura en ese sector. ver cómo otros sectores podrían estar en riesgo. Los únicos sectores incorrectos posibles serían el original, el nuevo y la paridad.

— proceso91

Una aclaración, basada en los comentarios de @Colt anteriores: en el caso de RAID de hardware, cuando marca la matriz como fallida, ¿todavía permite el acceso a los datos? ¿Incluso, digamos, acceso de solo lectura para el intento de recuperación?

— proceso91

@ process91 Permitir que un sector se corrompa no se considera una buena idea, incluso si ese hecho se registró en un archivo de registro. No tendría idea de qué archivo podría estar dañado. El RAID debería garantizar que, al leer ese archivo, obtenga un error. Además, claramente no desea sobrescribir el sector defectuoso, porque eso significaría que acaba de perder su última oportunidad de recuperar los datos. Por lo tanto, tiene un sector ilegible en un disco y un sector en el nuevo disco donde no sabe qué escribir. Eso podría ser dos archivos diferentes dañados.

— Kasperd

1

@ process91 Agregué una nota sobre las matrices basadas en LSI. Dale un vistazo.

— shodanshok

8

Si ocurre URE, experimentará cierta corrupción de datos en el bloque, que generalmente tiene un tamaño de 256 KB-1 MB, pero esto no significa que TODOS los datos en su volumen se perderían. Lo que no es tan bueno de RAID5 es algo totalmente diferente: la reconstrucción en sí misma es estresante y hay muchas posibilidades de que se produzca una segunda falla consecutiva en el disco. En tal caso, todos los datos se perderían.

— BaronSamedi1958
fuente

2

¿Cómo es más estresante una reconstrucción RAID5 en una sola unidad que una reconstrucción RAID1? Veo que es más estresante para la CPU, pero para cualquier unidad específica simplemente estamos leyendo todos los datos de ella. Normalmente, el peligro que las personas citan con unidades más grandes es que probablemente se encontrarán con un URE durante la reconstrucción, pero eso está bien para mí si eso solo significa que un solo sector se dañará.

— proceso91

3

Es la teoría de la probabilidad. Con N (donde es # de unidades) sus posibilidades de fallar son N veces mayores.

— BaronSamedi1958

1

Así no es exactamente cómo funcionaría el cálculo, en realidad querrías calcular 1- probabilidad de no tener una falla, pero entiendo esa parte. Parece que he interpretado incorrectamente su declaración como una sugerencia de que el acto de reconstruir un RAID5 es de alguna manera más estresante en el disco (que he leído en otro lugar), lo que aumenta las posibilidades de una URE, pero si eso no es lo que usted ' estoy diciendo entonces estoy de acuerdo.

— proceso91

2

Lo explicaría al revés;

Si el controlador RAID no se detiene en URE, ¿qué podría pasar?

Lo viví en un servidor, el RAID nunca notó el URE y después de la reconstrucción comenzó a acumularse un daño en todo el volumen RAID.

El disco comenzó a tener más sectores defectuosos después de la reconstrucción y los datos comenzaron a estar corruptos.

El disco nunca se arrancó del volumen RAID, el error del controlador es un trabajo para proteger la integridad de los datos.

Ese ejemplo está escrito para hacerle pensar que un controlador no puede empujar un volumen con URE en absoluto, es por la integridad de los datos, ya que el volumen no está destinado a ser una copia de seguridad sino una resistencia a una falla de disco

— yagmoth555 - GoFundMe Monica
fuente

1

Veo que los nuevos moderadores están constantemente revisando el sitio, buscando cosas que hacer ...

— Ward - Restablece a Monica

1

¿Por qué una sola URE generaría corrupción en todo el volumen RAID?

— proceso91

2

Lo siento, releí tu respuesta. Parece que tuvo un único URE malo durante la reconstrucción, pero este no fue el problema. El problema era que los sectores continuaron yendo mal después de la reconstrucción, y la unidad nunca lo informó. Sin embargo, esto parece un problema separado de si el controlador RAID nota o no un URE durante una reconstrucción. El controlador RAID podría notar el URE durante la reconstrucción y alertarlo, pero aún así proceder a finalizar la reconstrucción. Algunos datos siempre serían mejores que ningún dato.

— proceso91

2

Solo me interesa analizar por qué RAID5 se consideró "muerto" en 2009, lo que se basa en la probabilidad de una única URE. Ahora entiendo que este análisis fue matemáticamente incorrecto y realmente no se aplica de la misma manera a, por ejemplo, ZFS.

— proceso91

1

@RobMoir Supongo que su última declaración es donde no estoy de acuerdo. Obtener casi todos mis datos de la matriz podría ser útil, incluso si tuviera otra copia de seguridad. Tal vez ese archivo no era importante o (en el caso de RAID de hardware) el error ocurrió en un área de espacio libre. Creo que la decisión correcta, para RAID de hardware (donde no sabe específicamente qué archivos se vieron afectados) sería alertar al usuario, completar la reconstrucción y cambiar la matriz al modo de solo lectura. No veo ningún inconveniente en esto. (Obviamente, sistemas de ficheros, como ZFS incluso puede hacer mejor, ya que pueden reportar los archivos afectados.)

— process91

1

Sugeriría leer esta pregunta y respuestas para obtener un poco más de información. Luego ve y vuelve a leer la pregunta que vinculaste nuevamente.

Cuando alguien dice acerca de esta situación que "el RAID falló", significa que perdió el beneficio del RAID: perdió el acceso continuo a los datos que fue la razón por la que configuró la matriz RAID en primer lugar.

No ha perdido todos los datos, pero la forma más común de recuperarse de una unidad muerta más (algunas) URE en (algunas de) las unidades restantes sería reconstruir completamente la matriz desde cero, lo que significará restaurar todos sus datos de respaldo.

— Ward - Restablece a Monica
fuente

1

Generalmente, usa RAID cuando su objetivo es minimizar el tiempo de inactividad. Hacer que la matriz continúe con corrupción desconocida y sin reparar generalmente es contrario a ese objetivo.

— David Schwartz

1

Gracias, esa primera pregunta que vinculaste fue muy informativa. ¿Por qué habría perdido el acceso continuo a los datos? La matriz aún estaría activa durante la reconstrucción, y si encuentra un URE durante la reconstrucción, entonces esperaría que continúe, aunque este sector de datos ahora está dañado. ¿No es este el caso?

— proceso91