Etiquetas
Aunque está cada vez más fiable y con menos fallas, al principio los fallos de sincronización del AutoScaler con el ElasticLoadBalancer eran bastante frecuentes. Aún así todavía pueden ocurrir errores de programas que ponen la CPU de un servidor al 100%, o que se cuelgue algún servicio, o que deje de responder y el LoadBalancer lo elimine de su lista pero aún así sigan ejecutándose y consumiendo vuestro dinero.
El AutoScaler también tiene otro problema derivado de la extrema simplicidad de las reglas (del CloudWatch) para escalar hacia arriba y hacia abajo, especialmente esta última. Supongamos que para minimizar los costes queréis mantener las instancias entre un 70 y 85% de uso de CPU (así lo tenemos en Menéame), para ello usareis las métricas agregadas del grupo del auto escalador, pero en éste no hay forma de indicar una regla que como:
Cuando la carga con una instancia menos sea menor al 70%, decrementar una instancia
Por ello, en 2009 implementé un programa que monitoriza la carga de cada instancia del grupo que implementa este tipo de reglas. Además este programa monitoriza que todas las instancias estén dentro del margen (entre 70 y 85% de CPU), si alguna se desvía mucho toma otras decisiones. Por ejemplo: si una está cercana al 100% y la diferencia con la media de carga es superior al 50%, asume que hay un fallo en esa instancia y la terminará. Lo mismo hará que para instancias que estén muy cercanas al 0% de CPU mientras las demás están bastante por encima (lo típico de instancias “descolgadas” del LoadBalancer, por ejemplo por fallo de hardware o de algún servicio.
La verdad es que además de ahorrarnos bastante dinero manteniendo a todas las instancias “saludables” y dentro de los márgenes de CPU, me quitó dolores de cabeza. Salvo catástrofes y cosas muy raras, no tenía que preocuparme para nada del estado de los servidores web.
Pero nunca liberé ese código, cuando lo programé (hace casi cuatro años) las librerías de Python y Perl estaban bastante mal documentadas, así que lo hice en PHP porque pude entender las clases muy rápidamente. Pero el código era infumable, y ni quería liberarlo. Ahora que las librerías de Python, las boto, tienen muy buena calidad, me decidí a portar el código a Python. Ya está funcionando, y ahora lo libero y explico brevemente (haced con el código lo que queráis).
Precondiciones
Tenéis que tener instalado el paquete boto. Está probado con la versión 2.14, podéis usar el que trae vuestra distribución si es al mínimo la versión 2, o bien instalar la última con el pip (pip install -U boto). Ya está, eso es suficiente, en principio no necesitáis nada más de software.
Lo que hay que hacer es poner la configuración con vuestras claves en el /etc/boto.cfg o ~/boto. En nuestro caso, que tenemos los servidores en Dublin, la configuración es la siguiente:
[Credentials] aws_access_key_id = XXXXXXXXXXXXXXXXXX aws_secret_access_key = YYYYYYYYYYYYYYYYYYY [Boto] ec2_region_name = eu-west-1 ec2_region_endpoint = ec2.eu-west-1.amazonaws.com autoscale_region_name = eu-west-1 autoscale_endpoint = autoscaling.eu-west-1.amazonaws.com elb_region_name = eu-west-1 cloudwatch_region_endpoint = monitoring.eu-west-1.amazonaws.com
El código
Consiste de tres ficheros Python, los dos primeros obligatorios para hacer los controles, el tercero es para visualizar información de las instancias:
ec2_watchdata.py: Define la clase WatchData que implementa los métodos para leer los datos de AWS, manipular datos y hla lógica de controles.
ec2_watch.py: Es el script que ejecuto desde el cron cada minuto y hace lo que he explicado antes. Intenté que la lógica quede muy sencilla, y se puede cambiar todo por argumentos en la línea de comandos (con -h sale una pequeña ayuda). Permite especificar el nombre del grupo del autoescalador, si se quiere que envíe un email de las “emergencias”, para cambiar los límites de CPU, y otra para que grabe los resultados en JSON en la base de datos de Menéame como “annotation” (usado para poder visualizar el estado vía web). Lo podéis ejecutar como queráis, incluso con la opción -d o –dry si sólo queréis ver qué es lo que va a hacer, yo lo tengo en el cron para que se ejecute cada minuto, que es lo que recomiendo:
* * * * * meneame/scripts/ec2_watch.py -g web -a -m gallir@gmail.com > $HOME/watch.log
ec_instances.py: Es un pequeño script (pero que lo usamos mucho) que también usa la clase WatchData, fudamentalmente para visualizar el estado de las instancias del grupo, y también permite cambiar manualmente el número de instancias deseadas (opción -i), o matar instancias (opción -k). La siguiente captura muestra varias ejecuciones de este script, con un par para cambiar el número de instancias deseadas:
Opcional: Si miráis el código, cuando se indica la opción -a llama a la función store_annotation() en el fichero utils.py. Esta es la que guarda los datos en formato JSON en la base de datos de Menéame y que me permite controlar desde la web y mi móvil:
Ejemplos de fallos (provocados)
Primero hice que una instancia se ponga al 100% de CPU (con el comando “yes > /dev/null”), así simulaba el fallo de algún programa. ec2_watch lo detectó y primero incrementó el número de instancias de 2 a 3. Como es una “emergencia”, me avisó por email de lo que pasaba, y lo que hizo:
Minutos después esa instancia seguía al 100%, por lo que la mató:
La siguiente es otra prueba, pero a la inversa. Desconecté manualmente una instancia del LoadBalancer, así el uso de CPU se pondría casi a cero, lo detectó a los pocos minutos, la terminó y el autoescalador levantó otra instancia nueva (al no cambiar el número de instancias deseadas):
Fin
Espero que os sea útil. No aceptaré sugerencias, pero sí parches 😉
