• Del autor
  • Principios y algoritmos de concurrencia

Ricardo Galli, de software

~ De software libre, internet, legales

Ricardo Galli, de software

Archivos de etiqueta: amazon aws

Monitorización y «self-healing» de AutoScaler/LoadBalancer de Amazon AWS

14 lunes Oct 2013

Posted by gallir in desarrollo, menéame, programación

≈ 3 comentarios

Etiquetas

amazon aws, autoscaler, elastic load balancer, self healing

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:

ec2_instances.py

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:

ec2_watch web

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:

100% de CPU, incrementa una instancia

Minutos después esa instancia seguía al 100%, por lo que la mató:

100% CPU, la mata

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):

0% de CPU, mata la instancia

Fin

Espero que os sea útil. No aceptaré sugerencias, pero sí parches 😉

«Particionado funcional» económico en Amazon RDS… y cachea todo ¡estúpido!

17 domingo Mar 2013

Posted by gallir in internet, píldoras, pijadas, programación

≈ 6 comentarios

Etiquetas

amazon aws, menéame, optimización, rds

El miércoles pasado di una charla de cómo tenemos Menéame en Amazon AWS. Iba a explicar, al final de la charla, un truco de «particionado» [ver nota al final] económico, pero que no pudo ser: me tocó vivir en directo una saturación de la base de datos, producida por el nombramiento del nuevo Papa. Ahora explico cuál es ese «truco» de «particionado» económico y sencillo que sirve para ahorrar costes en RDS, y luego qué pasó y cómo solucioné la saturación de una de las bases de datos (de allí la frase «cachea todo ¡estúpido!», el estúpido soy yo 😉 ).

La base de datos principal de Menéame está en MySQL sobre Amazon RDS, con Multi AZ, lo que significa que tenemos failback y failover over automático y desantendido si el master falla. Da mucha comodidad, pero también tiene su coste: se paga el doble (el tamaño que tenemos es el large).

Sigue leyendo →

La crisis con Amazon AWS

10 miércoles Ago 2011

Posted by gallir in personal

≈ 88 comentarios

Etiquetas

amazon aws, crisis, ebs, menéame

El viernes 5 de agosto  me voy con toda la familia a un pueblo de Extremadura cerca de la frontera con Portugal (Valencia de Alcántara) a visitar a unos amigos. Regresábamos el martes 9 a la tarde, ¿qué podía pasar en Menéame que no se pudiese solucionar con una navegador y la consola web de AWS si nunca habíamos tenido problemas graves? Si necesitaba algo más, podía instalar las herramientas de AWS en otro ordenador y solucionarlo en pocos minutos. Así que por primera vez viajo sin mi portátil, sólo mi tablet Android con conexión 3G Vodafone (además de mi teléfono también con 3G).

Pues ocurrió el desastre en Amazon, les falló todo lo que podía fallar, todos nuestros planes de contingencia no podía aplicarse (salvo el «rehacer desde cero» con los bakups) y yo sin mi portátil y con el 3G completamente inestable, prácticamente como si no tuviese conexión. Si no hubiese sido así Menéame no habría estado «off line» tanto tiempo, quizás sólo unas pocas horas. Fue una pesadilla.

Amazon tuvo varios fallos: primero el corte completo de la conectividad a todas las instancias, luego la desincronización del API de gestión, luego los EBS que quedaron totalmente inaccesibles y bloqueando la gestión de las instancias que los usaban, y para rematar un fallo en el software de creación de los «snapshots» (backups por bloques en S3) que borraba datos de algunos bloques (lo descubrieron durante la crisis, y nos afectó a nosotros).

Nota: es un relato rápido, ya corregiré erratas, ahora me voy a duchar, que la última vez fue en Valencia de Alcántara 😉

Sigue leyendo →

Dos podcasts dos: Amazon EC2 y #nolesvotes

17 jueves Mar 2011

Posted by gallir in internet

≈ 7 comentarios

Etiquetas

#nolesvotes, amazon aws, ec2, podcast

Ultimamente estoy aprovechando mis virtudes, entre ellas mi voz, mi tono pausado, mi atractivo acento.

Dabo publicó hoy «“Kernel Panic” especial Amazon EC2 con Ricardo Galli (Menéame, UIB) y Raúl Naveiras», un podcast de 1:47 horas dedicado exclusivamente a comentar detalles de los servicios de Amazon AWS. Propuse a David hacer este podcast debido a la cantidad de consultas sobre temas básicos de Amazon que recibía casi cada día. Así que lo hicimos conjuntamente con Raún Naveiras. Damos un repaso introductorio a casi todos los servicios, comento costes reales y algunas limitaciones que tuvimos con Menéame.

Por otro lado, en Luz de Gas me hicieron hoy una larga entrevista sobre la ley Sinde y #nolesvotes, el audio está disponible en el blog, también en ivoox.

Comprar el libro

Principios y algoritmos de concurrencia

gallir@twitter

  • RT @EduardoSaldania: Le han compartido un hilo en el que explican por qué en momentos puntuales tienen que pararse los molinos. El tweet es… 18 hours ago
  • RT @InternetMolaba: Second Life (2003) vs Metaverso Facebook (2021) >>> 18 años de diferencia <<< 💡Creíamos que el futuro sería otra co… 1 day ago
  • RT @iGeStarK: quien ríe último, ríe mejor 🫡 https://t.co/WY5W80KHPB 3 days ago
  • RT @diego_gon: @gallir El caso es que es un fake que se ha comido Errejón. No han dicho eso, es un tuit inventado por una cuenta que ya ha… 3 days ago
Follow @gallir

RSS Notas recientes

  • Se ha producido un error; es probable que la fuente esté fuera de servicio. Vuelve a intentarlo más tarde.

Archivos

Comentarios recientes

PM en Cuidado con las «clever soluti…
Me matan si no traba… en Cuando el periodismo cede el c…
surco en Cuando el periodismo cede el c…
pancho pérez (@lonch… en Cuando el periodismo cede el c…
Fernando en Cuando el periodismo cede el c…
@beoxman en Cuando el periodismo cede el c…
gallir en Cuando el periodismo cede el c…
Jan Smite en Cuando el periodismo cede el c…
Alejandro en Cuando el periodismo cede el c…
Galletor en Cuando el periodismo cede el c…

Meta

  • Registro
  • Acceder
  • Feed de entradas
  • Feed de comentarios
  • WordPress.com

Licencia

Creative Commons License
Esta obra está bajo una licencia de Creative Commons.

Crea un blog o un sitio web gratuitos con WordPress.com.

  • Seguir Siguiendo
    • Ricardo Galli, de software
    • Únete a 28.667 seguidores más
    • ¿Ya tienes una cuenta de WordPress.com? Accede ahora.
    • Ricardo Galli, de software
    • Personalizar
    • Seguir Siguiendo
    • Regístrate
    • Acceder
    • Denunciar este contenido
    • Ver sitio web en el Lector
    • Gestionar las suscripciones
    • Contraer esta barra
 

Cargando comentarios...