Errores en disco de servidor de virtualización

hola, hoy realizando pruebas en el servidor de virtualización detectamos que un disco (el último del raid 1-0) está fallando. Esto provoca una demora en la escritura del sistema y estamos ordenando un cambio inmediato que debe ser realizado esta noche.

Problemas en autenticación en servidor compartido

Hoy recibimos varias quejas de que los usuarios estaban reportándose como desconocidos así como que se solicitaba usuario y clave continuamente para trabajar. Después de revisar, notamos que algunas tablas (fundamentalmente la de usuarios) estaba marcada como crasheada, por lo que procedimos a repararla. En estos momentos debe estar normalizada la situación.

Sólo ocurrió en un pequeño servidor, no fue una situación general.

Actualización a problemas con servidor de virtualización

El día de ayer los problemas de acceso a disco de este servidor persistían. Estos problemas provocaban situaciones evidentes a los usuarios que tenían sus servidores aquí alojados como eran:

1. Imposibilidad de forma aleatoria de acceder a su sitio web o bases de datos
2. Imposibilidad de forma alteatoria para recibir o enviar correos.

Esto se debía precisamente proque el acceso a disco fallaba de forma aleatoria. No se perdían datos sino que por momentos no se podía realizar tareas con los servidores.

En este servidor se alojan sitios web de bastante tráfico así como una cantidad pequeña, alrededor de 100 a 200 sitios web en modo de alojamiento compartido.

A todas las personas afectadas se les comunicó del problema o cuando llamaban se le explicó que estábamos trabajando en corregir la situación con la tarjeta controladora de RAID.

El servidor tiene una tarjeta controladora Adaptec 5405 para manejar un RAID-10 compuesto por cuatro discos de 1TB cada uno. Es una cantidad bastante grande de información.

Qué pasos tomamos y cómo llegamos a solucionarlo?

1. Se pensó en primera instancia que era un disco dañado en el arreglo, cuando un RAID se degrada, y en un RAID-10 es muy evidente esto, se pierde desempeño en la lectura y escritura. Se verificaron los discos y realmente no había problema alguno con los actuales discos. Esta es la causa más evidente de esta situación, pero en este caso no lo era.
2. Verificando en los logs notamos que había un error que decía: “kernel: aacraid: Host adapter reset request. SCSI hang ?“. Buscando en internet se indicaba que esto se debía a un problema en el firmware de la controladora de RAID, algunos lo asociaban con el hecho de que ocurría con un servidor que tenía más de 4GB de RAM, en fin, se sugería mantener actualizado el BIOS. En vez de actualizar el BIOS se optó por una situación que pudiera solucionar dos problemas en uno: Se optó por cambiar la tarjeta controladora por otra de forma tal que viniera con un nuevo BIOS pero además al ser un nuevo hardware se salía de la duda de que fuera problema físico de la controladora de disco.
3. Producto del paso anterior, al ponerse una nueva controladora, esta procedió a sincronizar los discos que componían al arreglo. Este proceso de sincronía duró una gran parte del día Lunes.
4. Al finalizar la sincronía de los discos, el error persistió, lo que claramente indicaba que no era problema en el hardware de la controladora de disco. Así que procedimos a tomar los siguientes pasos
5. Mientras planificábamos el siguiente paso, procedimos a sacar unas 3 máquinas virtuales hacia otro servidor de virtualización. Este procedimiento no se hizo antes pues mover una máquina virtual es un tema más complejo que decirlo. Sin embargo se realizó para tratar de ver si se disminuía el castigo a los discos. Esta solución aunque ayudó a esas 3 máquinas (pues salieron del hardware problemático) no contribuyó a mejorar el funcionamiento del servidor.
6. Se planificó que en el peor de los escenarios, si no funcionaban las siguientes medidas, nos tocaría migrar todas las máquinas hacia otro hardware, que es un tema complejo como indicábamos anteriormente.
7. Se procedió a mover la controladora hacia otro slot pci pues efectivamente hay veces en que en dependencia de un slot pci, pueden haber conflictos entre diferentes hardware. Aprovechando este momento, también se procedió a cambiar la RAM del servidor por si era problema de RAM. Todo este movimiento y cambio quedó demostrado horas después que no había sido de utilidad, igual el problema permanecía.
8. Mientras planificábamos las siguientes acciones encontramos que a veces apagando el acpi, el sistema puede volverse más resistente a estos problemas. Así que procedimos a apagar el acpi del servidor.
9. Encontramos en el sitio de adaptec y en otros sitios que había una situación en el kernel de linux que podia provocar este problema y era que el kernel de Linux había bajado el tiempo de recuperación cuando ocurría un problema en el RAID lo había bajado a 30 segundos. Pero el controlador de ADAPTEC tiene un tiempo de recuperación de 35 segundos. Como pasan 30 segs y linux no ve recuperación (pues el RAID se demora 35segs), vuelve a fallar y así se caía en un lazo bien complejo. Sugieren en el sitio que se suba el tiempo de espera de linux a 45segundos o un valor más alto. Le pusimos en 45 segundos y el error no solamente dejó de salir sino que mejoró evidentemente el acceso a disco de los sitios virtuales. Este punto lo realizamos alrededor de las 2 ó 3PM de ayer. Y realmente el servidor ya comenzó a trabajar mejor.
10. Sin embargo notábamos que el waiting time de los discos seguía siendo alto. El waiting time es como promedio cuánto demoran los datos en ser escritos a disco. En estos servidores normalmente tienen un waiting time alrededor de 10-15milisegundos. Bueno en realidad depende mucho del momento en que se intente la escritura. Sin embargo el waiting time estaba sobre los 70-80msegs (y anteriormente era más!) que definitivamente no era un valor ni medianamente cercano al promedio. Esto indicaba que aunque se había mitigado, se mantenían problemas de acceso a discos.
11. Procedimos entonces a planificar el siguiente paso que era cambiar la tarjeta madre, la motherboard, este es un paso un poco lento pues implica apagar el servidor, desarmar prácticamente toda la máquina para sacar la motherboard y volver a rearmar todo. Este proceso se planificó por la noche que es cuando menos afecta a los usuarios y se llevó a cabo a partir de las 9pm hora de Ecuador aproximadamente. Tomó un tiempo pues al finalizar de rearmar la nueva motherboard, el sistema no detectó las tarjetas de red o las detectó incorrectamente y tomó un tiempo el devolver la conectividad de red al servidor.

Al momento, varias horas después de haber sido realizado el anterior cambio, notamos un waiting time por debajo del promedio normal, no notamos mensajes de demoras en accesos a disco ni mensajes de problemas con la controladora. Notamos además que la carga del sistema está absolutamente baja (comparada con los valores antes de los cambios es increíblemente baja). Seguiremos monitoreando el sistema y les avisamos si hay algún inconveniente adicional a futuro aunque todos esperamos que no lo haya.

Es de notar que un problema en el hardware muchas veces no son evidentes ni fáciles de corregir. Estos cambios se hicieron siguiendo una lógica progresiva para detectar precisamente cuál cambio iba a ayudar a eliminar el problema. Se comenzó evidentemente por los problemas más comunes que ocurren al RAID y llegamos a los más infrecuentes (cambiar una motherboard no es un cambio típico realmente). Estos cambios se realizaron además pausadamente pues no aparecían inmediatamente después de realizado el anterior cambio, sino que el problema volvía a reaparecer de 40 a 60 minutos después de encendido el sistema y lógicamente después había que planificar el siguiente paso. Incluso ya los últimos pasos demoraron más porque sincronizar un RAID no es inmediato o rápido y al final el problema ya demoraba más en reaparecer que no al inicio.

La parte feliz es que no se perdieron datos en ningún momento al igual que estuvimos totalmente alertas y pegados al sistema buscando y generando soluciones al problema. Esto es importante de destacar.

Este servidor curiosamente, estuvo durante aproximadamente un año sin ningún tipo de inconveniente, incluso ya no tenemos que reinciarle para que tome un nuevo kernel, por tanto no es un servidor que acostumbramos a apagar o reiniciar y para nosotros fue una situación bastante preocupante el tener que apagar este equipo unas cuantas veces durante estos días.

¿Qué hicimos durante la rebelión policial?

Este artículo publiqué en mi blog personal:

http://www.ernestoperez.com/2010/10/¿que-hicimos-durante-la-rebelion-policial/

Problemas en servidor de virtualización

Hola, anoche se nos presentó un problema en uno de los servidores de virtualización que consistía en errores que surgían en la controladora del RAID 1+0 de este servidor.

Realizamos el cambio de la tarjeta controladora por una más actualizada pero este cambio implica que se tengan que resincronizar los datos nuevamente, esta sincronía hace que el acceso a disco sea un poco lento hasta que ella termine. Este proceso puede durar varias horas.

Durante este tiempo nos mantendremos monitoreando el estado del servidor pero advertimos a los usuarios que estén en este servidor que presentarán algunas demoras producto del acceso a disco.