Amazon Web Services para profesionales IT

Lanzar instancias EC2 automáticamente tras un balanceador

¡Prueba gratis durante 10 días

nuestros 1266 cursos !

Prueba gratis Mostrar modalidades de suscripción
Ya bien para soportar un alto nivel de tráfico, o para mantener la alta disponibilidad de una aplicación, necesitaremos múltiples instancias detrás de nuestro balanceador de carga. En este capítulo aprenderemos a adjuntarlas manualmente al balanceador y a mantener un grupo de escalado para que se crean automáticamente.

Transcripción

La alta disponibilidad no consiste solo en tener un balanceador de carga, con dos, cuatro, ocho máquinas detrás; y que si una de ellas falla, puedan seguir trabajando el resto, sino que también consiste en poder aguantar una gran carga de usuarios repentina para la que no estábamos preparados. Para ello hay que crear reglas en nuestros balanceadores para que automáticamente, en caso de alta carga, de las instancias que hay unidos a ellos, puedan arrancar instancias automáticamente. Ahora mismo tenemos un balanceador funcionando, que no tiene ninguna máquina detrás. Lo hemos dejado vacío, pero esta configurado y listo para servir si pusiéramos alguna aplicación detrás. Si entramos... Vemos que nos devuelve un "error 503", de servicio temporalmente no disponible, que nos da "awselh", el balanceador. ¿Por qué? Porque no hay máquinas detrás. No pasa nada, ahora las ponemos. ¿Qué es lo que necesitamos? Dos cosas. Una, una configuración de lanzamiento, que configura qué tipo de máquinas y cómo se van a lanzar automáticamente; y, el grupo "autoescalado", que dice cuándo se van a lanzar esas máquinas que hemos configurado. En el grupo autoescalado, si no tenemos ninguna configuración de lanzamiento lista, cuando creemos uno, automáticamente nos la va a pedir. Así que no tenemos porqué realizarla antes. Directamente la podemos hacer desde aquí. Seleccionaremos la máquina que queremos que se lance automáticamente. Obviamente no sera una instancia Linux o Windows vacía por defecto, porque no va a servir nuestra aplicación, sino que necesitamos que automáticamente se lance nuestra aplicación. Para lo cual hemos hecho una AMI con la aplicación lista para funcionar, que se llama "ghost_base". Ghost es un software de blog. Seleccionamos... Seleccionamos el tamaño de la instancia que queremos que vaya a arrancar automáticamente... Configuramos los detalles: cómo queremos que se lance, con qué nombre... Y activamos la monitorización detallada. Esto lo que hace es hacer monitorización del estado de nuestras máquinas una vez por minuto, en vez de una vez cada cinco minutos. Esto nos permite tener más detalle y responder más rápido a las peticiones extras que tenemos y poder lanzar máquinas adicionales. Si no, por defecto, no tendríamos notificación del tráfico hasta que no pasen cinco minutos de tener este, digamos, ataque o cantidad extra de accesos y podríamos perder cinco o diez minutos muy importantes para ponerlo todo en marcha. Seleccionamos "grupos de seguridad"... Con éste, en principio, si nuestro balanceador esta dentro de este grupo de seguridad sería suficiente, porque los clientes no se conectan directamente a los servidores, a las instancias, sino que se conectan al balanceador y es el balanceador el que se conecta a nuestras instancias. Por lo tanto, conque el balanceador tenga acceso es suficiente. Pero como voy a lanzar unas cosas dentro voy a pedirle acceso SSH y web desde afuera. Por supuesto, se me queja, dice que hay reglas de seguridad que están abiertas a todo el mundo, y me dice que mi instancia no entra dentro del tramo gratuito de Amazon. Seleccionamos un clave de acceso. Y ya tenemos la configuración de lanzamiento. Ahora creamos el grupo de autoescalado. Le damos un nombre... Le decimos con cuantas instancias queremos que empiece siempre, el mínimo de instancias; la red en la que queremos colocar este grupo y en cuantas subredes queremos que lance máquinas. Por lo menos, lo suyo sería que en dos. Ya que si no, no vamos a tener alta disponibilidad. Cargamos una y agregamos otra. En las políticas de "autoescalado" seleccionamos cuándo queremos que se lancen estas máquinas. Seleccionamos un política que dice que podemos escalar entre uno y cinco, por ejemplo. Es conveniente poner un número razonable máximo, ya que si por algun "bug" se empieza a consumir CPU y se empiezan a lanzar muchas instancias, no queremos encontrarnos de repente con que tenemos doscientas instancias lanzadas en nuestra cuenta. Para incrementar el grupo de autoescalado, creamos una regla que se llama "subida", aunque le podéis poner el nombre que queráis, y agregamos una alarma, que puede ser enviada por SMS. Cuando la media de uso de la CPU de las máquinas que están en el grupo de autoescalado, sube por encima del 80 %, es decir, es mayor o igual al 80 %, durante al menos un periodo de cinco minutos, se crea una alarma. ¿Qué hace esta alarma? Agregar dos instancias al grupo. Siguiente, sería el grupo de "desescalado". Lo que hacemos es crear un grupo que se llama "bajada" o el nombre que os guste, creamos una alarma nueva y pensamos en qué es lo conveniente para nuestra aplicación. Para la prueba, lo que haremos será, que cuando la media de uso de CPU sea menor o igual al 50 %, durante al menos un periodo de cinco minutos, se crea una alarma y quitamos una instancia. Por lo tanto, si la CPU sube más de un 80 %, se arrancan dos instancias de golpe; y, cada cinco minutos que la CPU media de todo este grupo baje por debajo de 50, se van eliminando una instancia hasta que llegue al mínimo. Si tocara, podemos hacer notificaciones por SNS. También podemos configurar "tags"... Revisamos... Y lo lanzamos. Tenemos nuestro grupo de autoescalado. De momento, tenemos cero instancias, porque lo acabamos de arrancar. Nos dice que deseamos o que, más bien, el grupo de autoescalado lo que que quiere es tener una instancia, que es el mínimo, ya que ahora no tenemos carga extra; hasta un máximo de cinco. Si esperamos unos minutos, se estarán lanzando ahora mismo la instancia que queremos mínimo que tenga el grupo, y podremos verla en la lista. Pasados unos minutos, ya tenemos nuestra primera instancia disponible. Que podemos ver en nuestra lista de instancias. Lo que vamos a intentar hacer es forzar la CPU de esta máquina, poner la CPU al cien por cien para que el grupo de autescalado reaccione y empiece a lanzar automáticamente más instancias. Tomamos los datos de conexión. Y nos vamos a un terminal. Conectamos por SSH. Y lanzamos el "sofware" Stress para poner la CPU al cien por cien. Ahora tendremos que esperar cinco minutos para que salten las alertas. Cuando vemos que hemos llegado a los cinco puntos, es decir, cinco minutos de alta carga de la CPU... Podemos bajar en nuestro grupo de autoescalado... Y ver que en la lista de instancias deseadas ya tenemos tres. Y que están las tres lanzadas. Vamos a mirar en la lista... Y ya tenemos tanto de instancia inicial, más las dos siguientes, que veis que se acaban de lanzar, que se están inicializando, corriendo dentro de nuestro grupo de autoescalado y, por lo tanto, detrás de nuestro balanceador. Si abrimos el balanceador, lo más probable es que ya nos esté sirviendo páginas. Ya podemos refrescar con libertad y estamos preparados para muchísima más carga. Si canceláramos nuestro "estresador" de CPU, por decirlo de alguna manera, o, en un caso real, si dejáramos de recibir visitas tan fuertemente, al cabo de cinco minutos, bajarían la cantidad de instancias que tenemos lanzadas. Como veis, estar preparado para una llegada imprevista de gran cantidad de visitas es muy sencillo. Con esto no tenéis que estar tan preocupados de la infraestructura y sabéis que podéis arrancar desde una instancia más pequeña y que, en el caso de subida repentina de usuarios, de carga, de proceso, vais a estar preparados para ello y no tendréis que tener siempre arrancadas muchas máquinas o, ya bien, encontraros con el problema de que no tenéis suficiente capacidad de cálculo.

Amazon Web Services para profesionales IT

Empieza a administrar Amazon Web Services, consiguiendo el mejor rendimiento y la disponibilidad continuada en estos servicios, y aprende a realizar diferentes procesos en la nube.

3:26 horas (44 Videos)
Actualmente no hay comentarios.
 
Fecha de publicación:28/04/2017

Este curso video2brain está disponible como descarga y para ser visualizado online. ¡Pero no hace falta que decidas entre las dos opciones! Al comprar el curso, disfrutarás de ambas posibilidades.

La descarga te permite ver las lecciones sin estar conectado/a a internet y supone una navegación fácil y ágil entre capítulo y capítulo. Si vas a trabajar en diferentes ordenadores o si no quieres descargarte el curso completo, entra en la web con tus datos de acceso y disfruta directamente de tus vídeos online. Te deseamos que disfrutes de este curso y te resulte de mucha utilidad.

Estamos a tu disposición si tienes cualquier tipo de duda o pregunta.