Reemplazo de disco de RAID en servidor de virtualización

Les informamos que el procedimiendo fue realizado rápidamente en el horario esperado, en menos de 10 minutos estaba arriba.
Al momento el servidor está sincronizando el nuevo disco.

En la noche de hoy estaremos reemplazando uno de los discos de un servidor de virtualización. Debido a este proceso deberemos apagar el servidor de virtualización por unos minutos hasta que el disco sea reemplazado. Algunos clientes de virtualización notarán una caída de aproximadamente 15 a 30 minutos en la noche.

Luego de que el proceso acabe, lo avisaremos por este medio. Y verificaremos que todas las máquinas virtuales arranquen como hasta ahora.

Problemas con servidor de virtualización

hola
uno de los servidores de virtualización ha dado un error en el filesystem, y dejó de responder al reiniciarle.. estamos al tando del problema y monitoreando que levante… esperamos sea lo más pronto posible
Actualización 1
En estos momentos el servidor levantó, en efecto hay un disco con daño que debe ser reemplazado, como es un proceso que toma tiempo seguramente planificaremos el reemplazo del disco para la noche de hoy.

Al momento estamos revisando una por una las máquinas virtuales por si debe revisarse el disco. Hay unas 10 máquinas en lista para ser revisadas.

Actualización 2:
ya están revisadas todas las máquinas. En la noche posiblemente apaguemos este equipo para reemplazar el Hardware dañado.

Ya estamos con CentOS-6 en nuestro sitio web

Desde mediados de esta semana, ya nuestro sitio web www.nuestroserver.com fue transferido a un nuevo servidor con CentOS-6, así como una serie de sitios que están en el mismo servidor.

Después de pequeños ajustes que hubo que realizar en la configuración del servicio de correos, estamos funcionando sin inconvenientes con CentOS-6.

Cualquier servidor que tengan con nosotros y no corra ningún panel de control, si desean nos avisan para reinstalarle con CentOS-6. A los productores de los paneles de control les tomará seguramente un tiempo acomodar el panel a CentOS-6

CentOS-6

Bueno, ya desde anteayer tenemos CentOS-6 disponible para instalar. El mismo Domingo realizamos pruebas de instalación y funciona de maravillas en los servidores y máquinas virtuales.

Al momento hemos instalado un servidor de un cliente con CentOS-6 (porque era nuevo y no tuvimos que migrar).

Los nuevos clientes vendrán ya con CentOS-6 excepto que usen panel de control, los paneles de control todavía no han sacado la versión para CentOS-6. Los viejos clientes aplicaría más o menos la misma idea, si no usan panel de control les podemos reinstalar, pero previamente sugerimos que saquen un respaldo de toda su información para proceder con la reinstalación.

Y ya tenemos ipv6!

Bueno, desde hace mucho tiempo tenemos activo el servicio de IPv6 para nuestros clientes dedicados y dedicados virtuales. Pero increíblemente no lo habíamos implementado en nuestro propio servicio. En casa de herrero cuchillo de palo.

Pero eso se arregló hoy, desde hoy en adelante tenemos IPv6 activa en nuestro servicio, si tienes ipv6 activa en tu red local puedes de momento acceder a nuestro servicio via ipv6 entrando a: http://ipv6.nuestroserver.com o a http://www.ipv6.nuestroserver.com o a www6.nuestroserver.com lo mismo se podrá hacer con nuestros otros sitios web. Si no tienes IPv6 activa en tu red local, preocúpate y llama ya a tu proveedor de internet.

Hemos de notar que somos el primer proveedor en el país en ofrecer el servicio de IPv6 para nuestros clientes. Y no es poca cosa… las IPv4 ya se agotaron y en pocos meses se comenzará a notar la escasez de ellas.. por lo que es bueno prevenir, por responsabilidad con los clientes.

A mediano plazo comenzaremos también a ofrecer este servicio a los clientes compartidos.

Si deseas obtener tu propia IPv6 con nosotros, mira nuestros planes de servidores dedicados virtuales

Mantenimiento planificado: Xen2

Durante el día de hoy hemos detectado que uno de los discos del RAID-10 de uno de nuestros servidores de virtualización está fallando.

Por tanto les informamos que tarde en la noche del sábado 19 de Febrero (después de las 10pm) procederemos a reemplazar este disco del raid. No se preveé pérdida de información, solamente un pequeño downtime.

Antes de reemplazar el disco, procederemos a realizar un respaldo completo del servidor por precaución.

Levante la mano Epe!

Sí, él mismo fue… hace haciendole un pequeño ajuste a uno de los servidores de virtualización dejó a las máquinas sin conectividad. El inconveniente duró aproximadamente 9 minutos. de 2100 a 2109 aproximadamente.

Problemas inesperados con sorbs

hola, en la madrugada de hoy, el sistema de listas negras de SORBS catalogó incorrectamente a una de nuestras redes como parte de un proveedor de internet que no conocemos (acamac.net) y por tanto nos incluyó en una lista llamada de dialup (DUHL):

Problem host/IP: 67.204.0.0/15
DNS Record: dsl-67-204-0-0.acanac.net.

Estos datos no son ciertos, pues este rango no pertenece a acamac y estamos viéndonos afectados pues los mails que salen de este rango de redes nuestras (67.205.107.160 – 67.205.107.191 y silimares) están siendo catalogados como redes de dialup que no se supone que tendrían que enviar mails.

Lamentablemente es un hecho que no hemos provocado, hemos sido incorrectamente catalogados en esta red y ya hemos presentado el reclamo a sorbs, mientras tanto tenemos que esperar a que arreglen el problema cosa que indican que puede tardar varias horas. Ya les hemos demostrado que no pertenecemos a esta red y que deben eliminarnos, ahora sólo resta esperar a que nos eliminen en un futuro cercano.

Desde ya, mil disculpas por esta situación en la que involuntariamente nos hemos visto involucrados.

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.

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.