Estoy ejecutando Ubuntu 12.04 LTS. Ayer encontré un mensaje en mi buzón que decía que mi servidor estaba cerrado. Procedí a reiniciar el sistema, pero no apareció después de muchos minutos y no tenía un sistema KVM de hardware para ver qué estaba imprimiendo el kernel en la terminal. Entonces reinicié el sistema con una imagen de rescate de Linux y vi que la matriz RAID 1 del software no estaba sincronizada. El sistema de rescate también comenzó a reconstruir la matriz RAID.
Hasta el momento no hay evidencia de que alguno de los discos tenga errores de hardware. Los estados SMART se ven bien hasta ahora.
Nunca recibí una notificación por correo electrónico de mdadm, a pesar de que la notificación por correo electrónico estaba activada en /etc/mdadm/mdadm.conf.
Este servidor también se configuró para reenviar todos los mensajes de syslog a un host de registro, así que verifiqué mi host de registro. Las partes relevantes son:
20 de mayo 15:38:40 kernel: [1.869825] md0: cambio de capacidad detectado de 0 a 536858624 20 de mayo 15:38:40 kernel: [1.870687] md0: tabla de particiones desconocida 20 de mayo 15:38:40 kernel: [1.877412] md: enlazar 20 de mayo 15:38:40 kernel: [1.878337] md/raid1:md1: no limpio - iniciando reconstrucción en segundo plano 20 de mayo 15:38:40 kernel: [1.878376] md/raid1:md1: activo con 2 de 2 espejos 20 de mayo 15:38:40 kernel: [1.878418] md1: cambio de capacidad detectado de 0 a 3000052808704 20 de mayo 15:38:40 kernel: [1.878575] md: resincronización de la matriz RAID md1 [recorte] 20 de mayo 15:52:33 kernel: Se detuvo el registro del kernel (proc). 20 de mayo 15:52:33 rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="845" x-info="http://www.rsyslog.com"] saliendo en la señal 15 .
Como puede ver, el sistema (el normal, no el sistema de rescate) ya detectó que algo andaba mal con la matriz RAID durante el inicio del sistema. Luego, poco después, algo (no yo) detuvo el sistema.
Entonces mis preguntas son:
- ¿Qué podría causar que los discos dejen de sincronizarse repentinamente?
- ¿Por qué no me avisaron por correo electrónico?
- ¿Por qué el error no se registró correctamente en syslog antes de detener el sistema? ¿Podría ser que el sistema intentó iniciar sesión en syslog, pero lo hizo después de detener el demonio syslog? Si es así, ¿qué puedo hacer para evitarlo?
- ¿Qué puedo hacer para saber qué pasó? O, si ahora no tengo forma de saber qué sucedió, ¿cómo puedo mejorar el registro y las notificaciones para que la próxima vez pueda hacer una mejor autopsia?
Mi pregunta esnosobre las prácticas de respaldo adecuadas. Ya sé que RAID no es una copia de seguridad, etc. Mi pregunta es únicamente sobre notificaciones y diagnóstico.
Respuesta1
¿Qué podría causar que los discos dejen de sincronizarse repentinamente?
Podría ser cualquier falla de hardware o software en la ruta entre los platos de la unidad y los datos en la memoria. Lo que podría significar, entre otros: cabezal de unidad, controlador de unidad, cabezal de conexión en el cable, el cable en sí (rotura de cable interno), el puerto al que se conecta el cable en la unidad, el puerto en la placa base o en la tarjeta secundaria. , el chip controlador de la placa base o de la tarjeta secundaria, o incluso una falla en el software (en alguna parte).
Historia real: una vez tuve un espejo RAID que estaba defectuoso y se me cayó una unidad sin motivo alguno. Las unidades funcionaron bien, los platos estaban limpios (las pasadas SMART repetidas no arrojaron nada) y todo funcionó bien, hasta que se descascaró una y otra vez. Reemplacé el cable SATA de $3 y los problemasinstantáneamentese fue. Moraleja de la historia: hay MUCHAS cosas que pueden salir mal y no siempre se puede asumir que "todo está bien" si no se verifican todos los componentes en la ruta de los datos.
¿Por qué no me avisaron por correo electrónico?
La notificación por correo electrónico solo ocurre cuando (a) se monitorea activamente la matriz, o (b) cuando se interroga la matriz.
Mi consejo es: debe hacer que mdadm supervise activamente la matriz de unidades como un proceso. Esto se puede lograr con algo similar a (pero no exactamente como):
mdadm --monitor --scan --syslog
Deberá ajustar la línea anterior a su instalación específica.
¿Por qué el error no se registró correctamente en syslog antes de detener el sistema? ¿Podría ser que el sistema intentó iniciar sesión en syslog, pero lo hizo después de detener el demonio syslog? Si es así, ¿qué puedo hacer para evitarlo?
Podría haber habido una variedad de problemas que provocaron que se cancelara el registro.
En primer lugar, está toda la cuestión de cómo funciona syslog en general; y aunque se han necesitado muchos años para hacerlo robusto y confiable, existen ciertos casos extremos en los que es posible que los datos no lleguen al disco. Este es un problema de diseño bien conocido y que se abordó activamente con la gestión de servicios de estilo supervisión (también conocido como daemontools y similares). La solución fue omitir syslog por completo y escribir la salida en un registrador que tuviera un descriptor de archivo abierto en todo momento, para que no se descartara nada y el registrador volcara la salida al disco lo más rápido posible; Si bien no es una solución 100% efectiva, mejora significativamente las probabilidades de que se escriban eventos en la unidad antes de que el kernel entre en pánico o se apague.
En segundo lugar, existe la posibilidad de que el núcleo haya entrado en pánico total, o que haya ocurrido algún otro evento que obligaría a la máquina a arrinconarse. Incluso el hardware defectuoso podría causar un problema: he visto máquinas con fuentes de alimentación con poca potencia que provocan apagados espontáneos en Windows 8. Un reemplazo de la fuente de alimentación solucionó el problema de apagado de forma permanente. Obviamente,nadalo que el kernel puede hacer es protegerse contra una máquina que simplemente decide "Ya he tenido suficiente de esto" y se aleja para reiniciar.
¿Qué puedo hacer para saber qué pasó? O, si ahora no tengo forma de saber qué sucedió, ¿cómo puedo mejorar el registro y las notificaciones para que la próxima vez pueda hacer una mejor autopsia?
Hay varios enfoques:
Coloque el registro en una partición separada. Si bien esto no es una garantía de que obtendrá registros intactos, sí ayuda a aislar problemas del sistema de archivos, como disco lleno que no puede escribir, corrupción que provoca que el reinicio sea de solo lectura, etc. Sin duda, ayuda en esos casos. casos específicos.
Mire el registro remoto de información vital del sistema. Nuevamente, esto no es una garantía, pero ayudará si el último paquete puede "salir por la puerta" antes de que ocurra un reinicio, y ese paquete tiene pistas críticas de por qué ocurrió el reinicio.
Para servicios críticos específicos, considere reemplazar la salida de syslog con algo más, como un registro de estilo de supervisión, donde un registrador dedicado intercepta la salida y la escribe en el disco lo antes posible. Esto aumenta la confiabilidad de la salida que llega al almacenamiento. Con un poco de trabajo, se puede lograr que coexista con otros acuerdos de gestión de servicios.
Respuesta2
¿Qué podría causar que los discos dejen de sincronizarse repentinamente?
Fallo de la unidad, fallo del controlador, algún otro fallo de hardware. Algún problema de software oscuro.
¿Por qué no me avisaron por correo electrónico?
Ubuntu tiene un cronjob /etc/cron.d/mdadmque hace que los volúmenes RAID se verifiquen una vez al día a las 00:57. Si su sistema no tenía problemas en ese momento, o ya había fallado, entonces no había forma de enviar un mensaje.
¿Por qué el error no se registró correctamente en syslog antes de detener el sistema?
Bueno, si las unidades fallan, realmente no tiene sentido intentar escribir en ellas, ya que cualquier escritura adicional podría destruir lo que quede. Sin conocer la naturaleza exacta de su falla, podría ser que su volumen o sistema de archivos haya pasado a ser de solo lectura. De forma predeterminada, Ubuntu está configurado para cambiar a un sistema de archivos de solo lectura si hay errores en el volumen raíz.
¿Cómo puedo mejorar el registro y las notificaciones para que la próxima vez pueda hacer una mejor autopsia?
Configure el registro en un host syslog remoto. De esa manera, una falla de almacenamiento no significa que no se pueda registrar nada.