Este domingo, tras una increible fiesta mexicana la noche anterior, se me ocurre echar un vistazo al mail y me encuentro con un correo de Amazon indicándome que tienen problemas con el servidor anfitrión que alberga una de mis instancias de servidores virtuales, por cierto la que conseguí de forma gratuita.
We have noticed that one or more of your instances are running on a host degraded due to hardware failure.
i-55624c22
The host needs to undergo maintenance and will be taken down at 12:00 GMT on 2010-11-22. Your instances will be terminated at this point.
The risk of your instances failing is increased at this point. We cannot determine the health of any applications running on the instances. We recommend that you launch replacement instances and start migrating to them.
Feel free to terminate the instances with the ec2-terminate-instance API when you are done with them.
Sincerely,
The Amazon EC2 Team
El correo me dice que mi instancia está funcionando en un host degradado debido a un problema de hardware y que mi instancia será terminada en una operación de mantenimiento esta misma noche… al principio ni siquiera me lo podía creer ¿dónde quedó lo de la ubicuidad de la nube y el abstraerse de los problemas físicos? Dado que la instancia dispone de un almacenamiento persistente EBS, no podrían simplemente migrarla en vivo a otro servidor y santas pascuas. ¿Tendrá algo que ver con que se trata de una micro instancia, que está paravirtualizada o a que estemos en el pool de servicio gratuito? Igual han dedicado todos los servidores a punto de romperse a esta campaña de marketing… quién sabe.
Anteriormente cuando no disponíamos de imágenes con el almacenamiento directamente sobre EBS si una instancia era terminada todos los datos de la instancia que no salvaras explicitamente en un bloque EBS especialmente montado para ese propósito eran eliminados, ahora cuando terminas una instancia con EBS simplemente el EBS se queda almacenado para que lo anexes a otra instancia o para que lo borres si ya no vas a hacer uso de él. Así que bastaría con esperar a que pararan la imagen y levantar una nueva con ese EBS, pero al ir a conectarme comprobé que la instancia ya ni si quiera estaba en funcionamiento y no podía acceder a ella por web o por ssh, así que me lanzé ¡AL RESCATE!
El primer paso era parar la instancia que estaba fallando para poder liberar el EBS, pero sorpresa… la instancia no se para por mucho que se lo pidas, supongo que debido a los temibles problemas de hardware. Tras esperar veinte minutos decidí buscar un plan alternativo. Y aquí es dónde sacamos provecho de la potencia de los snapshots, así que simplemente hacemos un snapshot, es decir una copia, de nuestro EBS y creamos un nuevo EBS a partir del snapshot con lo que tendremos una copia exacta de nuestro almacenamiento disponible.
El siguiente paso es arrancar una instancia y asignarle el nuevo EBS que hemos sacado del snapshot. Me parecía recordar que podías hacer eso en un sólo paso pero a través del API y la línea de comando pero no encontré forma de hacerlo a través de la consola web así que hubo que hacerlo en varios pasos. Arrancamos la nueva instancia con un EBS por defecto, luego la paramos, desligamos el EBS de la instancia y lo borramos para a continuación enlazar el EBS que sacamos del snapshot con la instancia en la ubicación /dev/sda1 y ya estamos listos para arrancar una instancia clonada desde la original que estaba fallando.
Por otro lado, es posible que tengas que hacer alguna adaptación interna de tu servidor ya que tu dirección ip pública y privada en Amazon habrán cambiado, en mi caso a este nivel tuve que cambiar el /etc/hosts del servidor. Si dispones de una ip elástica para ofrecer los servicios te bastará con cambiar la instancia a la que apunta esta a la nueva instancia que hemos creado y tu servicio debería volver a la vida y responder de forma correcta a los dominios que la apunten. Cómo yo no dispongo a día de hoy de ip elástica, no entraba en el pack gratuito de Amazon, estaba usando la ip pública de Amazon cómo entrada a mis servicios y alguno de ellos cómo wordpress dependen de ella me tocó arreglarlos en la base de datos:
update wp_options set option_value=»http://minuevaippublicaamazon/miwordpress» where option_name=»stieurl»;
update wp_options set option_value=»http://minuevaippublicaamazon/miwordpress» where option_name=»home»;
La verdad es que se destapan dos temas igualmente de importantes respecto al servicio de Amazon: la fiabilidad de la nube y la felxibilidad de la que nos provee. Cada uno que saque sus conclusiones y vea hacia dónde se inclina la balanza.
Saludos,
Tengo una duda, la ip elastica que debe ser reasignada a la nueva instancia como lo propone el mismo Amazon en este articulo.
http://www.turegano.net/2010/11/22/rescatando-una-instancia-con-ebs-en-amazon/
s.’Si’una’instancia’falla,’o’si’simplemente’no’se’está’comportando’tal’y’como’usted’desea,’puede’
ejecutar’otra’basada’en’la’misma’plantilla.’A’fin’de’minimizar’los’tiempos’de’inactividad,’puede’incluso’mantener’en’
ejecución’una’instancia’de’respaldo,’lista’para’entrar’en’funcionamiento’en’caso’de’producirse’un’fallo.’Esto’puede’
hacerse’de’un’modo’eficiente’utilizando’direcciones*IP*elásticas.’Podrá’conmutar’por’error’fácilmente’a’una’instancia’de’
sustitución’o’una’instancia’de’recambio’en’ejecución’reasignando’su’dirección’IP’elástica’a’la’nueva’instancia.
Crees que esa reasignación podría llevarse a cabo automáticamente una vez se produzca el fallo, en una instancia de respaldo ya ejecutada ?
Gracias por la informacion,