Preludio:
Soy un mono de código que cada vez asume más tareas de SysAdmin para mi pequeña empresa. Mi código es nuestro producto, y cada vez más proporcionamos la misma aplicación que SaaS.
Hace aproximadamente 18 meses, cambié nuestros servidores de un proveedor de alojamiento premium centrado a un impulsor de rack barebones en un centro de datos de nivel IV. (Literalmente al otro lado de la calle). Esto nos ayuda a hacer mucho más: cosas como redes, almacenamiento y monitoreo.
Como parte del gran movimiento, para reemplazar nuestro almacenamiento adjunto directo arrendado de la empresa de alojamiento, construí un NAS de dos nodos de 9 TB basado en chasis de SuperMicro, tarjetas RAID 3ware, Ubuntu 10.04, dos docenas de discos SATA, DRBD y. Todo está documentado con cariño en tres publicaciones de blog: Creación y prueba de un nuevo NAS SATA RAID10 NFSv4 de 9TB: Parte I , Parte II y Parte III .
También configuramos un sistema de monitoreo Cacit. Recientemente hemos estado agregando más y más puntos de datos, como los valores SMART.
No podría haber hecho todo esto sin los increíbles boffins en ServerFault . Ha sido una experiencia divertida y educativa. Mi jefe está contento (ahorramos mucho dinero de $$$) , nuestros clientes están contentos (los costos de almacenamiento están bajos) , yo estoy contento (diversión, diversión, diversión) .
Hasta ayer.
Interrupción y recuperación:
Algún tiempo después del almuerzo, comenzamos a recibir informes de rendimiento lento de nuestra aplicación, un CMS de medios de transmisión bajo demanda. Casi al mismo tiempo, nuestro sistema de monitoreo de Cacti envió una gran cantidad de correos electrónicos. Una de las alertas más reveladoras fue un gráfico de iostat en espera.
El rendimiento se degradó tanto que Pingdom comenzó a enviar notificaciones de "servidor inactivo". La carga general fue moderada, no hubo pico de tráfico.
Después de iniciar sesión en los servidores de aplicaciones, clientes NFS del NAS, confirmé que casi todo estaba experimentando tiempos de espera de E / S muy intermitentes e increíblemente largos. Y una vez que me subí al nodo NAS primario, los mismos retrasos fueron evidentes al intentar navegar por el sistema de archivos de la matriz problemática.
Hora de fallar, eso salió bien. En 20 minutos, se confirmó que todo volvería a funcionar perfectamente.
Post mortem:
Después de todos y cada uno de los fallos del sistema, realizo una autopsia para determinar la causa del fallo. Lo primero que hice fue volver a la caja y comenzar a revisar los registros. Estaba fuera de línea, completamente. Tiempo para un viaje al centro de datos. Restablecimiento de hardware, respaldo y ejecución.
En /var/syslogencontré esta entrada de aspecto aterrador:
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1 Short offline Completed: read failure 90% 6576 3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2 Short offline Completed: read failure 90% 6087 3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3 Short offline Completed: read failure 10% 5901 656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4 Short offline Completed: read failure 90% 5818 651637856
Nov 15 06:49:45 umbilo smartd[2827]:
Así que fui a verificar los gráficos de Cacti para los discos en la matriz. Aquí vemos que sí, el disco 7 se está escapando tal como lo dice syslog. Pero también vemos que los Erros de lectura SMART del disco 8 fluctúan.
No hay mensajes sobre el disco 8 en syslog. ¡Más interesante es que los valores fluctuantes para el disco 8 se correlacionan directamente con los altos tiempos de espera de E / S! Mi interpretación es que:
- El disco 8 está experimentando un extraño error de hardware que resulta en largos tiempos de operación intermitentes.
- De alguna manera, esta condición de falla en el disco está bloqueando toda la matriz
Quizás haya una descripción más precisa o correcta, pero el resultado neto ha sido que un disco está afectando el rendimiento de toda la matriz.
Las preguntas)
- ¿Cómo puede un solo disco en una matriz SATA RAID-10 de hardware detener toda la matriz?
- ¿Soy ingenuo al pensar que la tarjeta RAID debería haber tratado esto?
- ¿Cómo puedo evitar que un solo disco que se porta mal afecte a toda la matriz?
- ¿Me estoy perdiendo de algo?
fuente
Respuestas:
Odio decir "no use SATA" en entornos de producción críticos, pero he visto esta situación con bastante frecuencia. Las unidades SATA generalmente no están pensadas para el ciclo de trabajo que usted describe, aunque sí hizo especificaciones de unidades específicamente calificadas para operación 24x7 en su configuración. Mi experiencia ha sido que las unidades SATA pueden fallar de manera impredecible, a menudo afectando a toda la matriz de almacenamiento, incluso cuando se utiliza RAID 1 + 0, como lo ha hecho. A veces, las unidades fallan de una manera que puede detener todo el autobús. Una cosa a tener en cuenta es si está utilizando expansores SAS en su configuración. Eso puede marcar la diferencia en cómo los discos restantes se ven afectados por una falla de la unidad.
Pero puede haber tenido más sentido ir con unidades SAS de línea media / línea cercana (7200 RPM) en comparación con SATA. Hay una pequeña prima de precio sobre SATA, pero las unidades funcionarán / fallarán de manera más predecible. La corrección de errores y los informes en la interfaz / protocolo SAS son más sólidos que el conjunto SATA. Entonces, incluso con unidades cuya mecánica es la misma , la diferencia del protocolo SAS puede haber evitado el dolor que experimentó durante la falla de su unidad.
fuente
¿Cómo puede un solo disco derribar la matriz? La respuesta es que no debería, pero depende de qué está causando la interrupción. Si el disco muriera de una manera que se comportara, no debería desmontarlo. Pero es posible que esté fallando en una forma de "caso límite" que el controlador no puede manejar.
¿Eres ingenuo para pensar que esto no debería suceder? No, no lo creo. Una tarjeta RAID de hardware como esa debería haber manejado la mayoría de los problemas.
¿Cómo prevenirlo? No puedes anticipar casos extraños como este. Esto es parte de ser un administrador de sistemas ... pero puede trabajar en los procedimientos de recuperación para evitar que afecte a su negocio. La única forma de intentar solucionar esto en este momento es probar con otra tarjeta de hardware (probablemente no sea lo que quiera hacer) o cambiar sus unidades a unidades SAS en lugar de SATA para ver si SAS es más robusto. También puede contactar a su proveedor de la tarjeta RAID y decirles lo que sucedió y ver qué dicen; después de todo, son una compañía que se supone que se especializa en conocer los entresijos de la electrónica de unidades inestable. Es posible que tengan más consejos técnicos sobre cómo funcionan las unidades y la confiabilidad ... si puede comunicarse con las personas adecuadas para hablar.
¿Te has perdido algo? Si desea verificar que la unidad tiene una falla de caso de borde, extráigala de la matriz. La matriz se degradará, pero no debería tener más raras ralentizaciones y errores (aparte del estado de la matriz degradada). Estás diciendo que en este momento parece estar funcionando bien, pero si tiene errores de lectura de disco, debes reemplazar la unidad mientras puedas. Las unidades con alta capacidad a veces pueden tener errores de URE (la mejor razón para no ejecutar RAID 5, nota al margen) que no aparecen hasta que otra unidad ha fallado. Y si está experimentando un comportamiento de caso de borde de esa unidad, no desea migrar datos corruptos a las otras unidades de la matriz.
fuente
No soy un experto, pero voy a tomar una foto salvaje en la oscuridad en base a mi experiencia con controladores RAID y matrices de almacenamiento.
Los discos fallan de muchas maneras diferentes. Desafortunadamente, los discos pueden fallar, o pueden ser defectuosos, en formas en que su rendimiento se ve seriamente afectado, pero el controlador RAID no lo ve como una falla.
Si un disco falla de una manera obvia, cualquier software de controlador RAID debería ser bastante bueno para detectar la falta de respuesta del disco, eliminarlo del grupo y disparar cualquier notificación. Sin embargo, creo que lo que está sucediendo aquí es que el disco está sufriendo una falla inusual que, por alguna razón, no está provocando una falla en el lado del controlador. Por lo tanto, cuando el controlador realiza un vaciado de escritura o una lectura desde el disco afectado, tarda mucho tiempo en volver y, a su vez, cuelga todo el IO en funcionamiento y, por lo tanto, la matriz. Por alguna razón, esto no es suficiente para que el controlador RAID vaya "ah, disco fallido", probablemente porque los datos terminan volviendo eventualmente.
Mi consejo sería reemplazar inmediatamente el disco fallido. Después de eso, echaré un vistazo a la configuración de su tarjeta RAID (es 3ware, pensé que eran bastante buenas) y descubrí qué considera que es un disco defectuoso.
PD: buena idea importar SMART en cactus.
fuente
Necesita las características de los dispositivos de almacenamiento de clase empresarial. Específicamente, las unidades empresariales WD RE 4 tienen dos características necesarias para evitar este comportamiento en matrices RAID. La primera tecnología que se enumera a continuación evita que la vibración armónica rotacional provoque un desgaste innecesario en los componentes mecánicos del disco duro. La segunda tecnología es la que causó su problema, el protocolo SATA no tiene esta característica. Para obtener estas funciones, necesita SAS, y si insiste en unidades SATA, puede comprar tarjetas SAS a SATA Interposer, como la LSISS9252.
Tecnología RAFF mejorada La electrónica sofisticada monitorea el variador y corrige la vibración lineal y rotacional en tiempo real. El resultado es una mejora significativa del rendimiento en entornos de alta vibración con respecto a la generación anterior de unidades.
Recuperación de errores de tiempo limitado (TLER) específica de RAID Evita las caídas de la unidad causadas por los procesos extendidos de recuperación de errores del disco duro comunes a las unidades de escritorio.
http://en.wikipedia.org/wiki/Error_recovery_control#Overview
También vea el enlace a continuación:
http://en.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers
Ver también: Documento Western Digital TLER que explica en profundidad el proceso de recuperación de errores. Prevención de fallos de recuperación de errores en unidades de disco duro ATA serie WD Caviar RAID:
http://www.3dfxzone.it/public/files/2579-001098.pdf
fuente
Solo una suposición: los discos duros están configurados para volver a intentar errores de lectura en lugar de informar un error. Si bien este es un comportamiento deseable en una configuración de escritorio, es contraproducente en un RAID (donde el controlador debe reescribir cualquier sector que no pueda leer desde los otros discos, por lo que la unidad puede reasignarlo).
fuente
mi tiro en la oscuridad:
la unidad 7 está fallando. tiene algunas ventanas de falla donde no está disponible.
la unidad 8 también tiene algunos errores 'más ligeros'; corregido volviendo a intentarlo.
RAID10 suele ser "un RAID0 de varios pares RAID1", ¿son las unidades 7 y 8 miembros del mismo par?
si es así, entonces parece que te encuentras con el caso "no debería suceder" de falla de dos discos en el mismo par. casi lo único que puede matar a un RAID10. desafortunadamente, puede suceder si todas sus unidades son del mismo lote de envío, por lo que es un poco más probable que mueran simultáneamente.
Supongo que durante una falla de la unidad 7, el controlador redirigió todas las lecturas a la unidad 8, por lo que cualquier reintento de error causó grandes retrasos que causaron una avalancha de tareas congeladas, matando el rendimiento por un tiempo.
tienes suerte de que Drive 8 todavía no parezca muerto, por lo que deberías poder arreglarlo sin dataloss.
Comenzaría por cambiar ambas unidades, y no olvide verificar el cableado. una conexión floja podría causar esto, y si no se enruta firmemente, es más probable que suceda en unidades adyacentes. Además, algunas tarjetas multipuerto tienen varios conectores de dos puertos, si la unidad 7 y la unidad 8 están en la misma, podría ser la fuente de su problema.
fuente
Las tarjetas de interposición SATA son otra solución.
Recientemente experimenté exactamente el mismo destino y encontré este hilo. El tenor general es que el protocolo SAS es más adecuado para RAID que SATA, porque SATA carece de características. Es por eso que las mismas unidades físicas están equipadas con controladores SAS, que luego se venden como Nearline SAS.
Buscando más, encontré:
http://www.lsi.com/products/storagecomponents/Pages/LSISS9252.aspx
Estoy investigando la actualización de uno de mis almacenes con un lote de estos. En este momento, la diferencia de precio entre 3 TB SATA vs SAS es 400% (precio de vainilla, misma marca, especificaciones y tienda, Alemania). Obviamente no puedo decir si esta estrategia funciona bien, pero vale la pena intentarlo.
Comentarios muy bienvenidos :-)
fuente
He visto un disco SATA con componentes electrónicos rotos que bloquean el inicio del firmware de un Areca 12 de manera sólida, no había forma de acceder al BIOS y mucho menos arrancar la máquina desde cualquier medio hasta que se encontró el disco duro infractor sacando discos en un binario busca la moda.
fuente