Implantación de un balanceador de carga NGINX

Las nuevas tecnologías de arquitectura de software, han evolucionado hasta un punto que le permiten realizar tareas que antes eran imposibles de realizar tanto por el hombre como las maquinas que existían en ese momento.

En este trabajo trataremos de explicar el funcionamiento de un balanceador de carga y lo importante que este sería implementarlo dentro de la organización.

¿Qué es un balanceador de carga?
Para contextualizar un balanceador de carga no es más que aquel que se encarga de distribuir las peticiones de diferentes nodos dentro del servidor de clúster, con el objetivo de optimizar el rendimiento del sistema, lo cual da como resultado alta disponibilidad y escalabilidad.

Implantación del balanceador de carga NGINX

Lo primero que debemos de hacer es descargar de la página oficial de NGINX el software es esta ocasión utilizaremos el siguiente http://nginx.org/download/nginx-1.10.2.zip.

Después de haber descargado el software lo descomprimimos y ejecutamos el siguiente comando para verificar que este se encuentra corriendo:


E:\nginx-1.10.2>start nginx.exe


Luego verificamos que los procesos estén corriendo con el siguiente comando:


E:\nginx-1.10.2>tasklist /fi "imagename eq nginx.exe"


Nos debe aparecer algo como lo siguiente verificando que se encuentra corriendo el servicio:



Nginx es un software capaz de realizar el balanceo de carga entre diversos servidores de aplicación.

Este posee tres estrategias para balancear la carga entre los diferentes clúster que son:

Round-robin: Cada petición que llega del usuario a un servidor es distribuida cíclicamente peticiones son distribuidas entre los servidores de forma cíclica

Least-connected: La petición que llegue de un usuario al servidor es atendida por el que tenga menos conexiones activas.

Ip-hash: En esta se atienden las peticiones en base a algún dato como por ejemplo la IP donde se está realizando la petición.

Para el caso de nuestro ejercicio utilizaremos la estrategia Round-robin.

¿Configuración necesaria?


Configurar el archivo nginx.conf en el cual se agregaran los diferentes servidores a los cuales se realizara el balanceo:

En mi caso utilizare Windows como el servidor maestro y los nodos donde se encuentran alojadas las aplicaciones son Debian en las cuales se encuentra instalado Apache HTTP como servidor de aplicaciones.

La configuración es la siguiente:

http {

include mime.types;

default_type application/octet-stream;

#log_format main '$remote_addr - $remote_user [$time_local] "$request" '

# '$status $body_bytes_sent "$http_referer" '

# '"$http_user_agent" "$http_x_forwarded_for"';

#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
upstream MiAplicacion {
server 192.168.0.3;
server 192.168.0.5;
server 192.168.0.7;
}
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
proxy_pass http://MiAplicacion;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443 ssl;
# server_name localhost;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}

La primera máquina Debían quedo con la siguiente dirección IP:





La segunda máquina Debían quedo con la siguiente dirección IP:



La tercera máquina Debían quedo con la siguiente dirección IP:



Para verificar el tráfico se utilizara la herramienta WireShark.

En la primera petición se fue por el servidor de aplicación numero dos como se evidencia en el navegador.



El WireShark capturo el siguiente tráfico

Como vemos en la imagen primero se le envía un acuse de recibido al servidor para establecer la conexión, el cual le contesta con un mensaje 200 con una petición correcta y después le avisa al servidor que este ya no tiene más peticiones para enviar

En la segunda petición se fue por el servidor de aplicación numero dos como se evidencia en el navegador y solicita el cierre de la conexión que se está llevando a cabo.


El WireShark capturo el siguiente tráfico

Como vemos en la imagen primero se le envía un acuse de recibido al servidor para establecer la conexión, el cual le contesta con un mensaje 200 con una petición correcta y después le avisa al servidor que este ya no tiene más peticiones para enviar.

En la segunda petición se fue por el servidor de aplicación número tres como se evidencia en el navegador y solicita el cierre de la conexión que se está llevando a cabo.

En la tercera petición se fue por el servidor de aplicación numero dos como se evidencia en el navegador.




El WireShark capturo el siguiente tráfico



Como vemos en la imagen primero se le envía un acuse de recibido al servidor para establecer la conexión, el cual le contesta con un mensaje 200 con una petición correcta y después le avisa al servidor que este ya no tiene más peticiones para enviar.

En la segunda petición se fue por el servidor de aplicación número uno como se evidencia en el navegador y solicita el cierre de la conexión que se está llevando a cabo.

Como conclusión se puede apreciar que la estrategia Round-robin va asignando una petición a cada servidor a medida que va llegando, es decir va llamando uno a la vez en un orden ya establecido.



Realizamos la prueba apagando el servidor numero dos identificado con ip: 192.168.0.5, y vemos que Wireshark no los marca de color rojo porque este no responde, después de pasado un tiempo Nginx le asigna la conexión a otro servidor que si este disponible para que este responda la petición.

Como podemos observar la conexión ha sido interrumpida y no se puede establecer la conexión con el servidor identificado con la IP 192.168.0.5 y después de pasados varios segundos Nginx se encarga de entregarle la conexión a otro servidor para que la atienda.

Bibliografía

Nginx. (n.d.). Nginx Documentation. Retrieved 11 01, 2016, from http://nginx.org/en

O'REILLY. (n.d.). Load Balancing Web Applications. Retrieved 10 31, 2016, from Cornell University Department of Computer Science: http://www.cs.cornell.edu/courses/cs530/2004sp/papers/V01.pdf