A continuación se presenta un resumen detallado de las causas del corte de servicio que ocurrió el 18 y 19 de marzo, así como nuestra respuesta ante el problema y las acciones a adoptar para garantizar que un corte de servicio no vuelva a ocurrir. En total hubo alrededor de 8 horas de tiempo de inactividad para los sitios web de nuestros clientes y 2 horas de tiempo de inactividad para la parte del CRM de EasyBroker. La última vez que tuvimos una interrupción imprevista fue el 14 de febrero de 2012, hace ya más de un año. Durante este último año hemos mantenido un tiempo activo de más de 99%. Sin embargo, entendemos que EasyBroker es fundamental para su negocio por lo cual planeamos tomar medidas para garantizar una respuesta rápida y adecuada en una situación similar.
El problema y los varios intentos para solucionarlo
El 18 de marzo nuestro servidor principal de producción empezó a comportarse de forma extraña. Después de reiniciarlo y hacer algunos ajustes -los cuales tomaron alrededor de una hora- éste volvió a estar en línea. Durante el día estuvimos investigando con nuestro host Rackspace sin poder encontrar la causa de lo sucedido.
Lamentablemente en la mañana del 19 el problema reapareció; esta vez no logramos que el servidor volviera a estar en línea. Tratamos de cambiar a un servidor virtual, pero desafortunadamente, mientras migrábamos el servidor, Rackspace tuvo un corte con su servidor de Cloud Files que causó que nuestra migración se congelara. Al tratar de resolver el problema de la migración con Rackspace lanzamos un nuevo servidor con una dirección IP diferente. Dentro de poco tiempo el CRM de EasyBroker estaba funcionando de nuevo. Por desgracia, todos los nombres de dominio de los sitios web de nuestros clientes estaban apuntando a la dirección IP del servidor antiguo. Probablemente tomaría de 4 a 8 horas para migrar a la nueva IP. Por otro lado, Rackspace nos comentó que tardaría unos 30 minutos en arreglar el problema con el servicio de Cloud Files así que decidimos que sería mejor esperar.
Desafortunadamente, después de que el servicio Cloud Files regresó, Rackspace no pudo descongelar el proceso de migración. Después de 5 horas de trabajo Rackspace se dio cuenta de que había un problema con el hardware, lo más probable con el disco duro, el cuál también era la causa principal de los problemas ocurridos hasta ahora. Rackspace hizo un cambio de hardware después de lo cual se pudo completar la migración del servidor.
Medidas para mitigar interrupciones futuras
El mayor problema que tuvimos con este corte es que no se podía hacer el cambio a un nuevo servidor porque la dirección IP estaba “atada” al servidor actual. Esto no habría sido un factor si se hubieran utilizado registros CNAME en lugar de registros A para cada uno de los dominios de nuestros clientes. Un simple cambio de DNS habría solucionado todo. Ya hemos actualizado todos los nombres de dominio de todos los dominios de nuestros clientes que gestionamos para usar CNAME.
Otra manera en que se podría haber resuelto el problema es mediante el uso de un “equilibrador de carga” de modo que fácilmente se pudiera cambiar a un nuevo servidor sin tener que desmontar EasyBroker. Un equilibrador de carga nos permitiría utilizar una sola dirección IP para múltiples servidores. Actualmente estamos en el proceso de agregar un equilibrador de carga para que en el futuro podamos resolver este problema sin, o con al menos muy poco, tiempo de inactividad.
Conclusión
Lamentamos mucho el tiempo de inactividad ya que sabemos afecta a cada uno de nuestros clientes. En los últimos años hemos mantenido un tiempo activo de más de 99%, sin embargo, seguiremos tomando medidas adicionales para reducir la posibilidad de cortes de este tipo en el futuro.