balanceo - nginx detrás de balanceadores de carga
balanceador de carga linux (3)
¿Puedes por favor señalar la entrada del blog?
Los balanceadores de carga balancean la carga. Supervisan el estado de los servidores web (tiempo de respuesta, etc.) y distribuyen la carga entre los servidores web. En implementaciones más complejas, es posible generar nuevos servidores automáticamente si hay un pico de tráfico. Por supuesto, debe asegurarse de que haya una consistencia entre los servidores. Pueden compartir las mismas bases de datos, por ejemplo.
Así que creo que el equilibrador de carga se ve afectado y decide a qué servidor enrutará el tráfico de acuerdo con el estado del servidor. . Nginx es un servidor web que es extremadamente bueno en la entrega de gran cantidad de contenido estático para usuarios simultáneos. Las solicitudes de páginas dinámicas se pueden descargar a un servidor diferente usando cgi. O los mismos servidores que ejecutan nginx también pueden ejecutar phpfpm. . Muchas posibilidades. Estoy en mi teléfono celular en este momento. Mañana puedo escribir un poco más. Atentamente.
Hola, mejor colega,
Descubrí que Instagram comparte su implementación de tecnología con otros desarrolladores a través de su blog. Tienen algunas grandes soluciones para los problemas que se encuentran. Una de esas soluciones que tienen es un equilibrador de carga elegante en Amazon con 3 instancias de nginx detrás. Mi pregunta es ¿cuál es la tarea de esos servidores nginx? ¿Y cuál es la tarea de los equilibradores de carga elástica y cuál es la relación entre ellos?
¿Alguien puede explicarme la idea detrás de esta solución?
Tnx por adelantado.
Soy consciente de que llego tarde a la fiesta, pero creo que el uso de instancias NGINX detrás de ELB en la publicación de blog de Istagram es proporcionar un equilibrador de carga de alta disponibilidad como se describe here .
Las instancias de NGINX no parecen usarse como servidores web en el blogpost. Para ese rol mencionan:
A continuación vienen los servidores de aplicaciones que manejan nuestras solicitudes. Ejecutamos máquinas Djangoon Amazon High-CPU Extra-Large
Entonces, ELB se usa solo como un reemplazo para su solución anterior con DNS Round-Robin entre instancias de NGINX que no ofrecía alta disponibilidad.
Disclaim: no soy experto en esto de ninguna manera y estoy en el proceso de aprender sobre el ecosistema de AWS.
El ELB (equilibrador de carga elástico) no tiene ninguna funcionalidad por sí solo, excepto que recibe las solicitudes y las envía al servidor correcto. Los servidores pueden ejecutar nginx, IIS, Apache, lighthttpd, lo que quieras.
Te daré un caso de uso real.
Tuve un servidor nginx ejecutando un blog de wordpress. Este servidor fue, como dije, alimentado por nginx que sirve contenido estático y "upstreaming" .php solicitudes a phpfpm ejecutándose en el mismo servidor. Todo iba bien hasta un día. Este blog fue presentado en un programa de televisión. Tenía un montón de usuarios y el servidor no podía seguir con el tráfico. Mi primera reacción sería usar la AMI (imagen de máquina de Amazon) para girar una copia de mi servidor en una instancia más poderosa como m1.heavy. El problema era que sabía que el tráfico aumentaría con el tiempo en los próximos días. Pronto tendría que girar una máquina aún más poderosa, lo que significaría más tiempo de inactividad y problemas. En su lugar, lancé un ELB (balanceador de carga elástico) y actualicé mi DNS para dirigir el tráfico del sitio web al ELB en lugar de hacerlo directamente al servidor. El usuario no sabe la IP del servidor ni nada, solo ve el ELB, todo lo demás sucede dentro de la nube de Amazon. El ELB decide a qué servidor va el tráfico. Puede tener ELB y solo un servidor encendido en ese momento (si el tráfico es bajo en este momento), o cientos. Los servidores pueden crearse y agregarse a la matriz de servidores (grupo de servidores) en cualquier momento, o puede configurar la escala automática para generar nuevos servidores y agregarlos al grupo de servidores ELB usando la línea de comandos de amazon, todo de forma automática.
Amazon Cloud Watch (otro producto y parte importante del ecosistema de AWS) siempre está vigilando la salud de su servidor y decide a qué servidor enrutará a ese usuario. También sabe cuándo todos los servidores se están cargando demasiado y es el agente que da la orden de generar otro servidor (utilizando su AMI). Cuando los servidores ya no están bajo una gran carga, se destruyen automáticamente (o se detienen, no recuerdo).
De esta manera, pude atender a todos los usuarios en todo momento, y cuando la carga era liviana, tendría ELB y solo un servidor nginx. Cuando la carga era alta, la dejaría decidir cuántos servidores necesito (según la carga del servidor). Mínimo tiempo de inactividad. Por supuesto, puede establecer límites a la cantidad de servidores que puede pagar al mismo tiempo y cosas así para que no se le facture sobre lo que puede pagar.
Verán, los chicos de Instagram dijeron lo siguiente: "solíamos ejecutar 2 máquinas nginx y DNS Round-Robin entre ellas". Esto es IMO ineficiente en comparación con ELB. DNS Round Robin es dns enrutando cada solicitud a un servidor diferente. Así que primero va al servidor uno, el segundo va al servidor dos y así sucesivamente. ELB realmente mira los servidores HEALTH (uso de la CPU, uso de la red) y decide a qué tráfico del servidor se basa en eso. ¿Ves la diferencia? Y dicen: "La desventaja de este enfoque es el tiempo que tarda el DNS en actualizarse en caso de que una de las máquinas deba ser clausurada". DNS Round robin es una forma de equilibrador de carga. Pero si un servidor se queda sin conexión y necesita actualizar el DNS para eliminar este servidor del grupo de servidores, tendrá un tiempo de inactividad (el DNS requiere tiempo para actualizarse a todo el mundo). Algunos usuarios serán enrutados a este mal servidor. Con ELB, esto es automático: si el servidor tiene una mala salud, no recibe más tráfico, a menos que, por supuesto, todo el grupo de servidores tenga mala salud y no tenga ningún tipo de configuración de escalado automático.
Y ahora, los chicos de instagram: "Recientemente, pasamos a utilizar el Elastic Load Balancer de Amazon, con 3 instancias de NGINX detrás que pueden intercambiarse (y se eliminan automáticamente de la rotación si fallan una comprobación de estado)".
El escenario que ilustré es ficticio. En realidad es más complejo que eso, pero nada que no pueda resolverse. Por ejemplo, si los usuarios cargan imágenes a su aplicación, ¿cómo puede mantener la coherencia entre todas las máquinas en el grupo de servidores? Deberá almacenar las imágenes en un servicio externo como Amazon s3. En otro post sobre ingeniería de Instagram: "Las fotos van directamente a Amazon S3, que actualmente almacena varios terabytes de datos de fotos para nosotros". Si tienen 3 servidores nginx en el equilibrador de carga y todos los servidores sirven páginas html en las que los enlaces de las imágenes apuntan a S3, no tendrá ningún problema. Si la imagen se almacena localmente en la instancia, no hay forma de hacerlo. Todos los servidores en el ELB también necesitarían una base de datos externa. Para eso Amazon tiene RDS: todas las máquinas pueden apuntar a la misma base de datos y se garantizaría la consistencia de los datos. En la imagen de arriba, puede ver una "Réplica de lectura" de RDS, que es la forma de equilibrio de carga de RDS. No sé mucho sobre eso en este momento, lo siento.
Intenta leer esto: http://awsadvent.tumblr.com/post/38043683444/using-elb-and-auto-scaling
Atentamente.