Redimensionamiento de disco en shx2, shx3 y shx13

Sobre las 01:00 del 14 de Mayo CET (horario Madrid), vamos a redimensionar el disco de los servidores shx2, shx3 y shx13.

Este procedimiento requiere apagar el servidor, por lo que todos los servicios alojados en el servidor dejarán de funcionar mientras dure el proceso, aproximadamente 30 minutos.

La razón es el incremento de consumo de espacio por varios de los usuarios alojados, lo cual nos obliga a aumentar el tamaño de disco para disponer de espacio suficiente.

Redimensionamiento de disco en shx7

Sobre las 01:00 del 3 de Abril CET (horario Madrid), vamos a redimensionar el disco del servidor shx7.

Este procedimiento requiere apagar el servidor, por lo que todos los servicios alojados en el servidor dejarán de funcionar mientras dure el proceso, aproximadamente 30 minutos.

La razón es el incremento de consumo de espacio por varios de los usuarios alojados, lo cual nos obliga a aumentar el tamaño de disco para disponer de espacio suficiente.

Mantenimiento en el Panel DNS

El próximo lunes, 30 de Marzo, entre las 8:00 y 10:00 de la mañana ( horario Madrid ), realizaremos tareas de mantenimiento en nuestro Panel DNS, por lo este estará inoperativo durante unos minutos.

El Panel DNS es la herramienta integrada en nuestro área de cliente que permite gestionar los registros DNS, redirecciones y página de parking de aquellos dominios registrados en guebs.

Redimensionamiento de disco en shx10 y shx12

Esta noche, sobre las 01:00 del 28 de Marzo CET (horario Madrid), vamos a redimensionar el disco de los servidores shx10 y shx12.

Este procedimiento requiere apagar el servidor, por lo que todos los servicios alojados en el servidor dejarán de funcionar mientras dure el proceso, aproximadamente 30 minutos.

La razón es el incremento de consumo de espacio por varios de los usuarios alojados, lo cual nos obliga a aumentar el tamaño de disco para disponer de espacio suficiente.

Redimensionamiento de disco en shx20

Esta noche, sobre las 01:00 del 25 de Marzo CET (horario Madrid), vamos a redimensionar el disco del servidor shx20.

Este procedimiento requiere apagar el servidor, por lo que todos los servicios alojados en el servidor dejarán de funcionar mientras dure el proceso, aproximadamente 30 minutos.

La razón es el incremento de consumo de espacio por varios de los usuarios alojados, lo cual nos obliga a aumentar el tamaño de disco para disponer de espacio suficiente.

Mantenimiento en sh20 y sh34

Esta noche, sobre las 0:30 del 3 de Enero, vamos a realizar una serie de mantenimientos en los servidor sh20 y sh34.

Los trabajos a realizar requerirán apagar los servidores, que estará fuera de servicio entre 20 y 30 minutos.

Lamentamos las molestias que os podamos ocasionar, pero son trabajos necesarios para garantizar la seguridad de los sistemas.

Redimensionamiento de disco en sh29

Esta noche, sobre las 01:00 del 25 de Noviembre CET (horario Madrid), vamos a redimensionar el disco del servidor sh29.

Este procedimiento requiere apagar el servidor, por lo que todos los servicios alojados en el servidor dejarán de funcionar mientras dure el proceso, aproximadamente 30 minutos.

La razón es el incremento de consumo de espacio por varios de los usuarios alojados, lo cual nos obliga a aumentar el tamaño de disco para disponer de espacio suficiente.

Análisis de la incidencia de hoy

Resumén de lo ocurrido

Hoy, 12 de Noviembre, hemos sufrido una nueva incidencia en nuestra plataforma, el cual ha provocado que varios servidores hayan estado fuera de servicio entre 2 y 7 horas.

El origen de la incidencia ha sido un bug o error de software en el sistema operativo de uno de nuestros sistemas de almacenamiento, el cual ha provocado un kernel panic y el reinicio del mismo.

Tras el reinicio, el sistema de almacenamiento ha perdido parte de los volúmenes de datos que contenía. Hemos corregido la situación importando los datos del sistema en espejo, el cual contenía los datos intactos.

Una vez restaurados los datos, hemos tenido problemas en la conexión iSCSI entre el sistema de almacenamiento y los servidores. Inicialmente hemos pensando en la posibilidad de una perdida de datos completa, por lo que hemos iniciado el procedimiento de restauración de backups. Hemos puesto online algunos servidores a partir de backups.

En cualquier caso, hemos continuado tratando de resolver el mencionado problema de conexión iSCSI y tras reconfigurar algunos aspectos y hacer una restauración de la estructura LVM de los volúmenes, hemos podido reestablecer las conexiones.

Tras ello hemos empezado a reiniciar los servidores fallidos, pero ha fallado el reinicio de todos ellos, viéndonos obligados a hacer un fsck de los discos. Tras el fsck todos los servidores han arrancado.

Qué vamos a hacer

Entendemos las consecuencias que las incidencias de larga duración tienen para nuestros clientes y queremos evitarlo a toda costa.

De hecho, tenemos nuestra infraestructura montada para minimizar incidencias de larga duración y hace años que no sufrimos ninguna, desgraciadamente estas últimas semanas se han juntado varias.

Nuestro objetivo es que esto no vuelva a suceder y vamos a tomar medidas a corto y medio plazo.

Como medidas a corto plazo, vamos a migrar servidores fuera del sistema de almacenamiento que ha fallado y a migrar clientes a nuestra otra plataforma. Nos pondremos en contacto según vayamos programando estás migraciones.

En cuanto a las medidas a medio plazo, vamos a construir una nueva plataforma de hosting que será mucho más tolerante a fallos, con los diferentes servicios totalmente aislados y donde este tipo de incidencias sean imposibles. Os informaremos al respecto en breve.

Migración de sh22, sh23 y sh24 a un nuevo sistema de almacenamiento

Esta noche, entre las 1:00 y 3:00 del 13 de Noviembre CET (horario Madrid) vamos a migrar los servidores sh22, sh23 y sh24 a un nuevo sistema de almacenamiento.

Esta migración supone que los mencionados servidores estarán fuera de servicio alrededor de 30 minutos.

La migración se hace con objeto de reducir la carga en el sistema de almacenamiento actual y minimizar el riesgo de una incidencia. En general, las posibilidades de que surja cualquier incidencia siempre es mayor en sistemas con elevada carga de trabajo.