Vamos a actualizar nuestra Política de privacidad próximamente. Te recomendamos consultar el avance.

Amazon Web Services para profesionales IT

Crear un balanceador de carga

¡Prueba gratis durante 10 días

nuestros 1288 cursos !

Prueba gratis Mostrar modalidades de suscripción
Si disponemos de múltiples instancias para atender todas las peticiones que va a recibir nuestra aplicación, necesitaremos un componente que se encargue de repartirlas entre todas las instancias disponibles. Este componente es el ELB o Elastic Load Balancer de Amazon, que nos permite balancear la carga que recibimos por un punto, entre uno o más destinos detrás del balanceador.

Transcripción

Si queremos conseguir una alta disponibilidad en nuestras aplicaciones, no necesitaremos únicamente múltiples servidores para recibir todas las peticiones sino que además, necesitaremos delante una aplicación, un servicio que nos reparta las peticiones de Internet entre los servidores que estén disponibles y activos. Lo que utilizaremos es lo que se llama un balanceador de carga. Dentro de EC2 tenemos un servicio que es el ELB, que es un balanceador de carga muy sencillo de poner en marcha. Lo encontraremos en la sección "Load Balancers" y desde aquí podremos crear uno. En principio, tenemos dos tipos disponibles: el balanceador de carga clásico, que es tanto un balanceador TCP, es decir, que simplemente reparte las conexiones entre un servidor y otro, sin hacer nada de por medio, y un HTTP, HTTPS, es decir, que se encarga de gestionar el SSL, las peticiones HTTP, etc. Va a una capa más arriba y después reenvía a otro servidor web el TCP sería, por ejemplo, para algo que no sea web, para cualquier tipo de conexión que quieres balancear que no sea web y para todo lo que sea web deberíamos usar esto porque nos ahorra muchos dolores de cabeza. El balanceador más moderno que tenemos ahora, sería una ALB un "Application Load Balancer". Esto es, igual que un balanceador de carga es única y exclusivamente para tráfico HTTP y HTTPS y tiene, entre otras ventajas, la facilidad de poder redireccionar conforme a la ruta a través de la cual le llegan las peticiones. Es decir, si a ti te llega una petición de dominio que sea ".com/aplicacion1" y otra de "dominio.loquesea.com/aplicacion2" esas dos peticiones las podríamos redireccionar a dos grupos diferentes de servidores solo por la URL, por la dirección desde la que llegan. Nos interesa este que es más moderno y tiene más facilidades para la web. Deberemos asignar un nombre para nuestro balanceador de carga, un identificador. Después, decidir si va a estar en Internet o va a ser interno, es decir, si las peticiones van a llegar desde usuarios que están fuera en Internet o si solo va a responder a peticiones que estén dentro de su VPC. Después podemos seleccionar si va a ser IPV4. Es decir, que va a utilizar las direcciones IP estándares de Internet de toda la vida o si vamos a ponerlo en "dualstack", que es que va a responder y usar peticiones tanto IPV4 como IPV6, que eso nos permitiría estar preparados en el caso de intentar utilizar IPV6. Como protocolo, por defecto, viene el HTTP sin cifrar, por defecto, en el puerto 80. Yo os recomiendo y es lo más interesante, que agreguéis a HTTPS conectado con un certificado que tengáis para que todas las conexiones, todos los datos que van a través de este balanceador vayan cifrados. Después seleccionaremos las zonas de disponibilidad donde va a responder. Esto es, no solo es necesario que tengamos múltiples servidores para dar alta disponibilidad, sino que, además, tendrán que estar en sitios diferentes. Si colocamos todos nuestros servidores en la misma zona de disponibilidad, y en algún momento, aunque sea una opción muy remota por algo, falla esa zona de disponibilidad entera todos los servidores que tengamos ahí, van a fallar. Y si todos están ahí, nos vamos a quedar sin servicio por mucho que tengamos múltiples servidores. Así que lo conveniente es que lo repartamos en múltiples zonas de disponibilidad. Yo voy a seleccionar todas, que en este caso en Frankfurt ahora mismo son dos. Como configuración de seguridad vamos a utilizar un certificado SSL que tenemos ya creado en nuestro "Certificate Manager de AWS". Podríamos crear un certificado, que hemos gestionado con otra entidad certificadora, y subir los datos de nuestro certificado, aquí. Pero aquí está mucho más integrado y es mucho más fácil crearlo. Ahora mismo, solo tengo un certificado creado, que corresponde con el dominio de la aplicación que quiero instalar y después las políticas de seguridad. Las políticas de seguridad se refieren a cómo el balanceador negocia las conexiones que lleguen hasta él por SSL. Se pueden permitir mas o menos protocolos con mas o menos seguridad para que toda la conexión que se produce sea mas o menos segura. Con la versión más antigua de todas, nos aseguramos de que muchos más navegadores vayan a funcionar a la hora de conectar a nuestra página, pero la conexión va a ser más insegura. Cuanto más moderna sea la versión de la política de seguridad que utilicemos, menos protocolos y más modernos serán los que utiliza y, por lo tanto, no todos, todos, todos los navegadores que intenten conectar podrán hacerlo. Los navegadores más antiguos como Internet Explorer 6, 7, 8, 9 o Android muy antiguos o iPhones muy antiguos, no podrían conectar a una web que solo tiene como política de seguridad TLS-1-2. Vamos a dejarla por ejemplo en la de 2016 como compromiso para salir del paso; luego la podréis cambiar en cualquier momento. Configuramos los grupos de seguridad. Yo voy a agregarlo en dos grupos: uno que es el grupo por defecto y otro que es el grupo HTTP mas HTTPS. Tenemos que configurarlo de tal manera que los grupos de seguridad en los que esté configurado este balanceador le permitan dos cosas: una, recibir conexiones en el puerto 80 y en el 443 desde el exterior que es desde donde se van a conectar nuestros clientes y dos, que a las máquinas que nos estemos conectando, por el grupo de seguridad en el que está este balanceador, permitan hacer una conexión a los puertos 80 o al que sea que están respondiendo en esas máquinas. Ahora configuramos el enrutado. Para enrutar, en este caso, en el ALB lo que se utilizan son "target groups", como grupos objetivos. Lo que le damos es, como un grupo de máquinas en el que todas las peticiones que recibamos las vamos a reenviar a ese conjunto de máquinas, de instancias que tenemos corriendo. Ahora mismo, no tengo ningún grupo creado, así que, crearé un nuevo grupo de objetivos. Le daré un nombre. Le diré en qué puerto quiero que conecte, que va a ser el HTTP, el 80. Hay que tener en cuenta que el balanceador directamente me ofrece la conexión 443 a los clientes, pero que desde el balanceador hasta la aplicación final que tenéis en la instancia, utilizáis solo el puerto 80. Ese trozo de la conexión se produce en una zona que es segura, que esta dentro de vuestro VPC, que nadie está escuchando ahí y ya lo podéis realizar en el puerto 80. Descargamos todo el proceso de cifrado que es intensivo y es más complejo de hacer para que lo haga el balanceador de carga. Por lo tanto, de momento solo utilizamos el puerto 80 o si tuvieres algún tipo de aplicación que corre en "rails" o en un puerto especial que tuvieres que usar el 3000 o el 80 80 aquí pondríais vuestro servidor de aplicaciones qué puerto es el que está utilizando para servir las páginas. Los "Health Checks" que serían los checks de salud de cómo están las máquinas Lo que hacen es, verificar si el servidor está respondiendo de bajo. Lo que hacemos es, o dejamos, por defecto, el protocolo HTTP, que lo único que hace es conectarse y probar si está abierto ese puerto y disponible y hacer una petición HTTP y luego podríamos decirle si queremos que lo pruebe mas o menos a menudo, es decir, el "Healthy threshold" es cuantas veces tiene que responder "OK" un puerto configurado para darlo como válido y el "Unhealthy threshold" serían cuantas veces tiene que fallar la petición a un puerto de una máquina para que se dé como que no está disponible. Cuando algo se marca como no disponible como "unhealthy" se sacan del balanceador y se dejan de hacer peticiones a ese servidor se dejan de enviar las peticiones allí. Solo estarán conectadas las máquinas que sean "healthy". Y luego las peticiones tienen un "time out" de diez segundos. Lo siguiente, seleccionar los objetivos de este grupo. Ahora mismo, no hay ningún objetivo, no hay ninguna instancia registrada. Yo tengo una aplicación que está corriendo en esta instancia de aquí. Es un blog, con un software que se llama "Ghost" que es un software libre; yo puedo crearlo al grupo de objetivos de este balanceador de carga. Puede ser una máquina o puede ser dos o pueden ser diez. En este caso, yo tengo una. Vamos a "review", revisamos por encima que toda la configuración está correcta creamos y nuestro balanceador de carga se pone en marcha. Puede tardar unos minutos en ponerse activo, ya que tiene que crear una instancia que balancee, tiene que conectarse a las instancias que tenemos configuradas para ver que están funcionando correctamente; va a hacer todos los "Health Checks" y se va a asegurar de que todo funciona y está listo para recibir peticiones. Si vamos a nuestro balanceador, vemos que tiene un nombre DNS, que sería parecido a los nombres DNS que recibimos en nuestras máquinas ES2, que es balanceador 1, identificador, mas una serie de identificadores internos de Amazon o AWS. Si vamos a los "listeners" podemos ver en qué puerto se escucha y con qué políticas. Podemos ver las políticas de seguridad y podremos esperar un rato a que el estado de "provisioning" pase a estar listo y podamos usar nuestro balanceador. Cuando nuestro balanceador de carga pasa al estado de activo, ya podemos pasar a utilizarlo. Vemos que está conectado a las dos zonas de disponibilidad y si buscamos, junto a los "Load Balancers" la sección "Target Groups", vemos el grupo de objetivos que hemos creado antes; podemos ver cuántos objetivos hay dentro de ese grupo. Vemos que tenemos una instancia registrada, que es la que hemos creado antes y que está como "Healthy". Ya ha pasado a estar disponible, esto quiere decir, que tenemos una instancia disponible para recibir peticiones dentro de nuestro balanceador. Si tomáramos la dirección que tiene nuestro balanceador y la pusiéramos en un navegador vemos que accedemos ya a la aplicación que tenemos detrás en nuestra instancia. Ya está disponible. A partir de aquí ya es cuestión de replicar como sea correspondiente el número de instancia que tenemos dentro de nuestro balanceador para que sea de alta disponibilidad. Y en el momento que una de las instancias deje de funcionar, ya bien por problemas en la zona de disponibilidad, problemas en la instancia o por algún problema que haya podido salir, el balanceador repartirá las conexiones entre todas las instancias que queden disponibles y las que están dando problemas las sacará del balanceo.

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.