Varias veces en mi carrera me he encontrado con conjuntos RAID mdadm (RAID1+0, 5, 6, etc.) en varios entornos (por ejemplo, cajas CentOS/Debian, NAS Synology/QNAP) que parecen simplemente incapaces de manejar discos defectuosos. Se trata de un disco que no está totalmente muerto, pero tiene decenas de miles de sectores defectuosos y simplemente no puede manejar E/S. Pero no está totalmente muerto, todavía está funcionando. El registro del kernel suele estar lleno de errores UNC.
A veces, SMART identificará que el disco está fallando, otras veces no hay otros síntomas aparte de una E/S lenta.
La E/S lenta en realidad hace que todo el sistema se congele. La conexión a través de ssh lleva una eternidad, la webGUI (si es un NAS) normalmente deja de funcionar. Ejecutar comandos a través de ssh también lleva una eternidad. Eso es hasta que desconecto / "fallo" deliberadamente el disco fuera de la matriz, luego las cosas vuelven a la "normalidad"; eso es lo más normal que puede ser con una matriz degradada.
Me pregunto, si un disco tarda tanto en leerse o escribirse, ¿por qué no simplemente sacarlo de la matriz, colocar un mensaje en el registro y continuar? Parece que todo el sistema se detiene porque un disco está un poco loco y anula por completo uno de los principales beneficios de usar RAID (tolerancia a fallas: la capacidad de seguir funcionando si un disco falla). Puedo entender que en un escenario de un solo disco (por ejemplo, su sistema tiene un único disco SATA conectado y no puede ejecutar lectura/escritura correctamente) esto es catastrófico, pero en un conjunto RAID (especialmente las "personalidades" tolerantes a fallas) Parece no sólo molesto sino también contrario al sentido común.
¿Existe una muy buena razón por la que el comportamiento predeterminado de mdadm es básicamente paralizar la caja hasta que alguien accede de forma remota y la repara manualmente?
Respuesta1
En general, el propósito de unaREDADA, dependiendo del nivel de Raid elegido, proporciona un equilibrio diferente entre los objetivos clave redundancia de datos, disponibilidad, actuaciónycapacidad.
Según los requisitos específicos, es elresponsabilidad del propietario del almacenamientodecidir qué equilibrio de los diversos factores es el adecuado para el propósito dado, para crear unconfiablesolución.
La función de la solución Raid elegida (en este caso hablamos del software mdadm) es garantizar ante todo la protección de los datos. Teniendo esto en cuenta, queda claro que no es tarea de la solución raid darle más importancia a la continuidad del negocio que a la integridad de los datos.
Para decirlo en otras palabras: el trabajo de mdadm es evitar una incursión fallida. Mientras un "disco de comportamiento extraño" no esté completamente roto, seguirá contribuyendo al ataque.
Entonces, ¿por qué no simplemente sacar de la matriz un disco que se comporta de manera extraña, colocar un mensaje en el registro y continuar?Porque hacerlo aumentaría el riesgo de perder datos.
Quiero decir, tienes razón, por el momento, desde una perspectiva empresarial, parece que la mejor solución es simplemente continuar. En realidad, sin embargo, es posible que el mensaje que se ha dejado caer en el registro no se detecte, por lo que el estado degradado del raid no se detecta. Algún tiempo después, finalmente falla otro disco en el mismo raid, como resultado, los datos almacenados en el raid fallido finalmente desaparecen.
Además de eso: es difícil definir exactamente qué es un "disco que se comporta de manera extraña". Expresado de otra manera: ¿Cuál sigue siendo un comportamiento operativo aceptable de un solo disco, operado dentro de una matriz de discos?
Algunos de nosotros podemos responder "el disco muestra algunos errores". Otros pueden responder: "Mientras los errores puedan corregirse, todo estará bien". Otros pueden responder: "Mientras el disco responda a todos los comandos en un momento dado, todo estará bien". Otros dicen "en caso de que la temperatura del disco difiera más de 5°C en comparación con la temperatura promedio de todos los discos dentro de la misma matriz". Otra respuesta podría ser "siempre que una limpieza no revele errores" o "siempre que SMART no muestre errores".
Lo que está escrito no es una lista larga ni completa.
El punto es que la definición de "comportamiento aceptable de un disco" es una cuestión de interpretación y, por lo tanto, también es responsabilidad del propietario del almacenamiento, y no es algo que se supone que mdadm debe decidir por sí solo.
Respuesta2
El problema clave es que una unidad de disco SATA defectuosa puede en algún momento congelar todo el bus mientras dure el procedimiento de recuperación de errores internos. Por esta razón, se debe utilizarhabilitado para TLERunidades solo en matrices RAID (y preferiblemente un modelo de nivel empresarial).
Las unidades SAS sufren menos este problema, pero tampoco están completamente libres de él.
Respuesta3
Además de lo dicho, quiero aportar mi granito de arena, pero ésta es una consideración importante.
Quéuna vuelta¿Qué hace cuando el sector tarda en leer?
Supuestamente, las unidades diseñadas para funcionar solas, por ejemplo las típicas unidades de "escritorio", suponen que no hay otra forma de recuperar los datos almacenados en ese sector defectuoso. Intentarán recuperar datos a toda costa, repitiéndolos una y otra vez, durante un período prolongado de tiempo. Por supuesto, también marcarán ese sector como fallido, por lo que lo reasignarán la próxima vez que escribas en él, pero debes escribir para eso. Hasta que lo reescribas, se ahogarán cada vez que leas desde ese lugar. En una configuración RAID, esto significa que para RAID la unidad aún funciona y no hay razón para expulsarla, pero para la aplicación la matriz se ralentizará.
Por otro lado, las unidades "empresariales", especialmente las "de marca", a menudo suponen que siempre se utilizan en configuración RAID. Un controlador "de marca", al ver una unidad "de marca", en realidad podría inclusonotificarsu firmware sobre la presencia de RAID. Por lo tanto, la unidad se detendrá antes de tiempo e informará un error de E/S, incluso si fuera posible realizar varios intentos más y leer el sector. Luego, el controlador tiene la oportunidad de responder más rápido, reflejando las instrucciones de lectura en una unidad hermana (y expulsando la mala de la matriz). Cuando sacas y exploras/pruebas a fondo el disco pateado, no encuentras problemas aparentes: solo se ralentizó por un momento y eso fue suficiente para dejar de usarlo, según la lógica del controlador.
Especulo que esto puede serel únicodiferencia entre unidades de "escritorio" y unidades NL-SAS y SATA "de marca"/"empresariales". Probablemente esta sea la razón por la que paga tres veces más cuando compra una unidad "HPE" que en realidad fue fabricada por Toshiba, en comparación con la compra de una unidad de marca "Toshiba".
Sin embargo, algunas unidades admiten algunos controles genéricos de esto. Se llama SCT ERC y se encarga deControl de recuperación de errores de transporte de comandos SMART. Así se ve en smartctl:
sin apoyo
# smartctl --all /dev/sda
=== START OF READ SMART DATA SECTION ===
SCT capabilities: (0x3037) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
soportado
=== START OF READ SMART DATA SECTION ===
...
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
Si tienes suerte, puedes controlar esta característica con smartctl. Puede recuperar o establecer dos tiempos de espera, cuánto tiempo intentar volver a leer y cuánto tiempo intentar volver a escribir:
# smartctl -l scterc /dev/sda
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
# smartctl -l scterc /dev/sde
SCT Error Recovery Control:
Read: Disabled
Write: Disabled
# smartctl -l scterc /dev/sdd
Warning: device does not support SCT Error Recovery Control command
smartctl -l scterc,120,60 /dev/sde
Lo que significa: 120 décimas de segundo para reintentar la lectura; 60 décimas de segundo para volver a intentar escribir. Cero significa "reintentar hasta que mueras". Diferentes unidades tienen diferentes configuraciones predeterminadas para esto.
Por lo tanto, si utiliza solo la unidad de "edición RAID", es mejor establecer los tiempos de espera de ERC en cero, o puede perder datos. Por otro lado, si utiliza unidades en RAID, es mejor establecer una configuración razonable baja distinta de cero.
Fuente por amarao @ Habrahabr, en ruso.
PD: Y una nota sobre SAS. Utilice sdparm, admite más controles de esto.
Respuesta4
He tenido situaciones en las que un disco no funcionó, pero se quitó el controlador de alguna manera.
Históricamente, esto era posible con PATA, donde las unidades maestra y esclava estaban en el mismo cable, y la falla de una unidad podía interferir con el acceso a la otra unidad que aún estaba en buen estado. Quitar la unidad defectuosa podría volver a habilitar el acceso a la unidad restante, o podría necesitar un ciclo de energía, pero la incursión podría aparecer degradada y luego podría comenzar la recuperación.
SATA es menos vulnerable a esto, pero aún es posible que el controlador se vea afectado. Según mi experiencia con raids de software, hay más entrañas sangrientas expuestas que quedarían ocultas por un controlador de raid dedicado más sofisticado.
No he experimentado esto con SAS o NVME, pero SAS a menudo significa controladores raid de hardware que tienen más inteligencia en el manejo de discos internamente.