Interrupción de energía no programada

La noche de hoy ocurrió en todo el datacentro de canadá una interrupción de la energía eléctrica no programada, después de varios minutos esto fue solucionado. Varios de nuestros servidores fueron afectados por esta interrupción y al momentos todos se encuentran funcionando normalmente.

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.

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.

Apagamos nuestro más viejo servidor

Bueno, con tristeza y alegría nos despedimos de nuestro más viejo servidor, era utilizado fundamentalmente por un usuario nuestro que alojaba ahi sus 140 sitios web. Es un usuario americano que tiene mucho temor al cambio y por tanto se había mantenido con su servidor durante muchos años.

Este servidor comenzó su vida de trabajo con nosotros en Abril del 2004 aproximadamente y durante 6 años se mantuvo funcionando con minúsculos problemas de desempeño. Era un Celerón de 1.8Ghz (o algo así) con 512MB de RAM y un disco de 80GB IDE.

Por favor, burlas aparte, era un servidor promedio en su época

Corría CentOS-3 con una versión de BlueQuartz para este sistema. Sinceramente durante sus 6 años de uso no tuvo ni un sólo problema de hardware, ni uno sólo! Y realmente es de ahí de donde admiramos los discos IDE.. casi nunca se dañaban, porque estos SATA nuevos a veces tienen graves problemas.

Respecto al sistema operativo, fue nuestro segundo servidor con CentOS, era por allá por el tiempo donde redhat había dejado de soportar RedHat Linux (RHL) a favor únicamente de RHEL y muchas empresas se fueron por la variante de Fedora sin analizar que fedora tenía un cortísimo tiempo de vida. Recuerdo que batallamos muy fuerte para que nos dejaran instalado CentOS en el sistema, con advertencias (no damos soporte a ese sistema) y es increíble, ahora todos usan CentOS, ofrecen CentOS y estudian CentOS.. nos sentimos gratificados por esto, por ser de los primerísimos en el mercado en ofrecer alojamiento basado en CentOS. Nunca hemos usado Fedora en servidores, solamente en escritorio que es muy bonito.

Por qué lo dejamos? No es porque fuera el único servidor de tan bajas specs que tuviéramos (cosa que era cierta, pues ahora todos nuestros servidores tienen de 4 a 32GB de RAM)… realmente le dejamos pues ya la versión 3 de CentOS va a pasar a EOL (End of Life) en el mes de Octubre, después de 7 años de continuo soporte por su grupo. Y por tanto es mejor migrar antes de que llegue este momento.

Como comentario adicional, todos nuestros servidores al momento están con CentOS-5, pues el último CentOS-4 lo dejamos hace varios meses. Y estamos a la espera de CentOS-6 para comenzar a realizar pruebas con él para valorar su correcto uso. Vendrá con muchas mejoras en la parte de virtualización.

Así que, como diría esa frase apócrifa de Quijote: Cuando los perros ladran Sancho…..

Migración a un 85%

Bueno, el proceso de migración hacia nuestros racks ha sido completado en su mayor parte. Al momento sólo quedan unos 3 servidoresnbsp; por migrar pero son de clientes que les manejan independientemente por lo que no afecta la migración de aquí en adelante a los usuarios propios nuestros. Podríamos decir que está concluído casi por completo el proceso de migración.br /Ahora comenzaremos a planificar la instalación de un SAN para alojar todo en servidores SAN e ir separando responsabilidades entre los servidores.br /br /div class=”zemanta-pixie”img class=”zemanta-pixie-img” alt=”" src=”http://img.zemanta.com/pixy.gif?x-id=ce0be374-d27f-8fc8-985c-128bcee29d98″ //div

Cambio de los servidores a rack

Cambios en los servidores.

Al fin hoy comenzaremos los cambios hacia nuestros propios Racks, el día de hoy durante la noche (después de las 6pm GMT-5) procederemos a cambiar los dos primeros servidores hacia nuestros racks. Durante el mes cambiaremos los otros 18 servidores poco a poco.

Hoy cambiaremos un servidor de radio y un servidor de telefonía IP. El cambio debe tomar menos de 15 minutos, primero migraremos el de voip tipo 6pm GMT-5, se les cambiará la IP y se actualizarán los DNS, esta actualización tomará una hora en propagarse. Tipo 8pm cambiaremos el servidor de radio, se le cambiará la IP y se actualizarán los dns, este cambio tomará menos de 5 minutos en propagarse.

Si todo marcha correctamente esperamos mañana estar cambiando un par de servidores más.

Preparemos un adiós a un veterano

A partir de mediados de este mes de Abril nos despedimos de nuestro viejo srv6, ha estado con nosotros ya desde el 2003 y es hora que se tome un descanso.

Todos los sitios que ahi habían ya han sido migrados y está solamente sirviendo algunas radios por internet. A inicios de Abril procederemos a sacar estas radios del servidor (será un cambio transparente) y le daremos el último adiós a este servidor.

Era un PIV con 512kb de caché L2, con 1GB de RAM y era nuestro único servidor de alojamiento compartido que no tenía RAID por hardware. Por favor parece máquina vieja, pero tengan en cuenta que hace 6 años que se adquirió.

Como curiosidad, fue nuestro primer servidor basado en CentOS y nunca hubo que reinstalarlo en 6+ años de servicio y de hecho así hubiera seguido funcionando si no fuera porque ya decidimos remplazarle el hardware por uno mejor. Bien por Linux! Y bien por nuestros cuidados al manejarlo bien que nos permitió usarlo de corrida por 6 años

Nuevo servidor

Consecuentes con nuestras políticas frente al crecimiento de la empresa, en el mes de Marzo del 2009 hemos contratado un nuevo servidor para alojar los sitios web de los clientes de nuestra empresa.

Es un servidor Intel Core2 Quad con 4MB de caché L2, 4GB de memoria RAM y discos duros SAS en RAID-1 por hardware. Es un servidor de 64bits lo que estimamos que nos permita ofrecer un excelente servicio en él.

Al momento hemos transferido una serie de sitios hacia él (aproximadamente 60) y pensamos ir poniendo en él los nuevos clientes que vayan llegando. Este movimiento de sitios ha permitido que la carga de los otros servidores nuestros de alojamiento compartido bajen su carga de trabajo.

El servidor corre con el panel de control Parallels lo que nos permite ofrecer una buena seguridad pues parallels se caracteríza por ser muy simple de manejar pero muy poderoso en el enjaulamiento de sitios lo que impide que un ataque afecte a todos los sitios.