Blog

Cómo fue la resiliencia en Hostingfacil.co 30 Enero 2017

2017.02.01

El 30 de Enero 2017 Hostingfacil.co afrontó una falla que desde su fundación jamás había enfrentado. Aquí contamos abiertamente que sucedió y que hicimos para prevenir volviera a pasar.

Cómo fue la resiliencia en Hostingfacil.co 30 Enero 2017

En este artículo vamos a contar el detalle de lo sucedido el 30 de Enero 2017 en Hostingfacil.co y que hicimos para prevenir vuelva a pasar.

Un poco de historia, en 2015 Hostingfacil.co surgió gracias a una oportunidad de brindar una solución de Hosting específica para alojar un software desarrollado para el distribuidor más grande de DirecTV en Colombia (Comunicate LTDA), donde pudimos dar una solución a un problema que no solucionó Hostgator, Godaddy ni Amazon Web Services (AWS), la optimización. Con Hostingfacil.co dicho software pasó de tener múltiples caídas por semana y tiempos absurdamente lentos de respuesta, a no tener caídas y la velocidad que necesita un entorno corporativo que opera cientos de técnicos, asesores, administradores con decenas de miles de clientes.

Desde 30 de Junio 2015 que salimos al público hemos tenido un crecimiento acelerado de clientes, donde nos vimos avocados  a mejorar nuestra infraestructura para hacerla más controlada por nosotros, pasamos de contratar servidores VPS a usar servidores dedicados con control del cabinet, routers, peers y ahora implementando nuestras propias VPS. Esto sucedió en Agosto 2015. Desde nuestra fundación hemos trabajado fuerte en desarrollar soluciones de software que permitan hacer el Hosting más eficiente, haciendo que este sea más rápido con los mismos recursos de hardware.

Ahora, 18 meses después, el hardware ha mejorado, nuevos procesador de Intel Xeon, RAM DDR4 más rápida, Discos SSD más rápido, mejores controladoras RAID, aunque nuestra meta siempre ha sido optimizar con software no podemos quedarnos atrás con el hardware, que siempre es una buena ayuda, por eso decidimos invertir en servidores más robustos y con hardware moderno, planeamos por un mes realizar esta migración. Nosotros tomamos ventaja de la virtualización KVM  y el almacenamiento LVM para hacer todo más fácil de administrar, ampliar, migrar. 

Debíamos migrar decenas de VPS de clientes, y VPS con servicios de Hosting / DNS de nosotros, migramos todas las VPS sin problema, cada VPS tomó 5 -10 minutos en migrar. Faltaba una de las más importantes, una VPS con más de 400 cuentas de Hosting. Esta VPS estaba especialmente configurada, una de esas configuraciones era tener acceso directo al procesador, al migrar esta VPS que inició 2:15 AM del 30 de Enero, y terminó 4:07 AM en el nuevo servidor, la CPU era diferente - último modelo, de acuerdo a la documentación no debía haber problema, era una migración de Intel Xeon 64 bits a Intel Xeon 64 bits: http://www.linux-kvm.org/page/Migration Pero sucedió que al tener acceso directo a la CPU entró en un estado de demencia en palabras coloquiales, como si de un momento a otro le hubieran cambiado el cerebro, es un bug (una falla) que no siempre sucede: https://bugs.launchpad.net/nova/+bug/1337264 en este estado ocurrió una corrupción en los archivos, había más del 30% corrupto, lo grabamos: https://goo.gl/photos/G8rdJwuKMg2unASe6 sin embargo tratamos de reparar el sistema de archivos, reinstalar componentes afectados (Reinstalar cPanel, Yum, RPM, archivos específicos), por 5 horas intentamos esto, hasta 8:57AM que encontramos que era irreparable y decidimos lo que comúnmente se conoce como formatear.

Durante este periodo, atendimos sus solicitudes de chat por hostingfacil.co, llamadas al fijo, celular, correos, Skype,  mensajes por Facebook Messenger tanto en la Página (incluso en los perfiles personales de nuestro equipo); siendo claros con nuestros usuarios que había ocurrido un error grave en el servicio de Hosting y estábamos en proceso de recuperación. Siendo 12:45 PM se terminó  la instalación y configuración del sistema, algunas de nuestras optimizaciones súper personalizadas cPanel no realizó el backup de las mismas, mucho trabajo manual fue requerido de hacer, por eso tomó casi 4 horas.

Nosotros realizamos Backups diarios con retención a 30 días, esto les permite a los usuarios desde cPanel restaurar por archivo, carpeta, cuenta de correo, base de datos, de cualquiera de los 30 días anteriores. Para realizar este backup en forma eficiente, lo realizamos en forma incremental, es decir, solo se copian los cambios. Pero este backup no fue el más apropiado para una pérdida total de datos, ya que se copia en servidores externos y aun cuando la red es de 1000 Mb/s (En Colombia la conexión promedio es de 3 Mb/s para hogares, y el datacenter más grande - en Bogotá - ofrece hasta 100 Mb/s), copiar casi 4 millones de archivos no es algo que sea rápido por una red, algunas cuentas tomaron hasta 27 minutos en restaurarse, cuentas con más de 200000 archivos. Es por esto que la restauración que inició 12:45 PM 30 Enero terminó 4:48 PM del 31 de Enero, el backup más antiguo que se restauró fue del 28 de Enero 12:53 AM - 25 horas 28 minutos antes del fallo. La información en ese periodo de tiempo no se pudo restaurar, aunque hubieron cuentas que el backup fue de tan solo unos minutos antes del fallo, lo que no les significó mayor pérdida de datos.

En el último mes habíamos trabajado en muchas mejoras que hicimos del servicio, automatizaciones, e igualmente planeando la migración. Durante el día 29, 30, 31 no descansamos ni un solo minuto, fue trabajo continuo en solucionar tan pronto como fuera posible (hasta lo imposible), incluso implementamos una cola con prioridad, clientes que se comunicaron con nosotros los pusimos siguientes en la restauración, de hecho tenemos alojadas aplicaciones muy críticas, por ejemplo clínicas que dependen del sistema para atender pacientes (cirug…), debido a la exigencia de disponibilidad de cuentas como estas se les dio prioridad.

Finalmente hoy 1 de Febrero, en las horas de la mañana después de dejar todo en orden preparamos todo lo necesario para prevenir que estos problemas que identificamos volvieran a pasar:

  1. Usar la virtualización en mejor forma, sin dar acceso directo a la CPU para una mejor compatibilidad entre migraciones, que ocurren cada 1 - 2 años, pero para la próxima ya no esperamos tener una corrupción de disco como la que tuvimos esta vez.
  2. Implementar un backup adicional para ocasiones como estas, un backup que hace copia a nivel de bloques del disco (una LVM Snapshot), que se puede usar para restaurar el sistema como un todo en unos 70 minutos (447 GB en una red 1Gb/s con velocidad efectiva de transferencia de 910 Mb/s - debido las checksum de TCP y la encriptación de OpenSSL) y no 28 horas 3 minutos que se tardó en restaurar el backup incremental.

En unas palabras más sencillas, implementamos medidas para que no vuelva a ocurrir una corrupción de disco, y de volver a ocurrir, podremos restablecer todo alrededor de una hora y muy probablemente si pasara, será en un día domingo madrugada, horas de poco tráfico.

Es nuestro mayor compromiso que nuestro servicio permanezca siendo el más rápido, con tiempos de carga de sitios Web inferior a un segundo, con seguridad y cerca del 100% de disponibilidad.

Buzon Sugerencias Hosting Fácil