Puede usar Nginx como equilibrador de carga frente a su aplicación web.
Por ejemplo, si su aplicación empresarial se ejecuta en Apache (o Tomcat), puede configurar una segunda instancia de su aplicación empresarial en Apache (o Tomcat) en un servidor diferente.
Y luego, puede poner Nginx en el front-end, lo que equilibrará la carga entre los dos servidores Apache (o Tomcat o JBoss).
Si es nuevo en Nginx, es importante comprender la diferencia entre Nginx y Apache y la arquitectura Nginx.
Nginx admite los siguientes tres tipos de equilibrio de carga:
- round-robin:este es el tipo predeterminado para Nginx, que utiliza el típico algoritmo de round-robin para decidir dónde enviar la solicitud entrante
- menos conectado:como sugiere el nombre, la solicitud entrante se enviará al servidor que tenga el menor número de conexiones.
- ip-hash:esto es útil cuando desea tener una conexión persistente o permanente de la solicitud entrante. En este tipo, la dirección IP del cliente se usa para decidir a qué servidor se debe enviar la solicitud.

1. Defina upstream y proxy_pass en el archivo de configuración de Nginx
Para el equilibrio de carga, debe agregar dos cosas al archivo de configuración de nginx:1) upstream 2) proxy_pass
Primero, aguas arriba: Especifique un nombre único (puede ser el nombre de su aplicación) y enumere todos los servidores cuya carga será balanceada por este Nginx.
En el siguiente ejemplo, "crmdev" es el nombre del upstream, que es el nombre de la aplicación que se ejecuta en el servidor web Apache individual (101.1 y 102.2, como se muestra a continuación). En lugar de "crmdev", puede especificar cualquier cosa que desee aquí.
Nota:El flujo ascendente debe definirse dentro de su contexto "http" de Nginx.
upstream crmdev { server 192.168.101.1; server 192.168.101.2; }
Nota:si los servidores individuales se ejecutan en un puerto diferente (que no sea el puerto 80), especifique el número de puerto como se muestra a continuación en el flujo ascendente
upstream crmdev { server 192.168.101.1:8080; server 192.168.101.2:8080; }
Segundo, proxy_pass: Especifique el nombre original único que se definió en el paso anterior como proxy_pass dentro de su sección de "ubicación", que estará en la sección "servidor" como se muestra a continuación.
server { listen 80; location / { proxy_pass http://crmdev; } }
Nota:En este ejemplo, nginx está escuchando en el puerto 80 como se muestra arriba con el parámetro de escucha.
Tenga en cuenta que también puede usar proxy_pass para configurar Nginx como proxy inverso para Apache/PHP.
2. Defina upstream y proxy_pass en el archivo de configuración predeterminado de Nginx
Nota:Por lo general, lo anterior debe estar en http o https como se muestra a continuación.
http { upstream crmdev { server 192.168.101.1:8080; server 192.168.101.2:8080; } server { listen 80; location / { proxy_pass http://crmdev; } } }
Pero, si está utilizando el archivo default.conf que viene con el archivo nginx.conf predeterminado, no necesita dar el "http", ya que ya está definido en el contexto http.
Nota:Para HTTPS, reemplace el contexto "http" (en la primera línea de arriba) con https. Además, en la línea proxy_pass, use https://{your-upstream-name}
En este caso, si usa "http" como se muestra arriba, es posible que obtenga el siguiente mensaje de error de directiva http no permitida:
Starting nginx: nginx: [emerg] "http" directive is not allowed here in /etc/nginx/conf.d/default.conf:1
Esta es la copia de mi archivo default.conf, donde agregué upstream en la parte superior (sin el http), y luego comenté la ubicación predeterminada y agregué la nueva ubicación usando proxy_pass.
# vi /etc/nginx/conf.d/default.conf upstream crmdev { server 127.0.0.1:4080; server 127.0.0.1:7080; } server { listen 3080; server_name localhost; #location / { # root /usr/share/nginx/html; # index index.html index.htm; #} location / { proxy_pass http://crmdev; } .. .. }
3. Configurar el algoritmo menos conectado para Nginx Load Balancer
En este algoritmo, la solicitud entrante se envía al servidor que tiene el menor número de conexiones activas existentes.
Para esto, agregue la palabra clave "least_conn" en la parte superior de la secuencia ascendente como se muestra a continuación.
upstream crmdev { least_conn; server 192.168.101.1:8080; server 192.168.101.2:8080; }
Si tiene varios servidores enumerados en less_conn, y si varios servidores tienen un número bajo similar de conexiones activas existentes, entonces, entre esos servidores, se elegirá uno en función de la rotación ponderada.
4. Configurar la persistencia o el algoritmo Sticky para Nginx Load Balancer
La desventaja del método round-robin y menos conectado es que la conexión subsiguiente del cliente no irá al mismo servidor en el grupo. Esto puede estar bien para una aplicación que no depende de la sesión.
Pero si su aplicación depende de la sesión, una vez que se establece una conexión inicial con un servidor en particular, desea que todas las conexiones futuras de ese cliente en particular vayan al mismo servidor. Para esto, use el algoritmo ip_hash como se muestra a continuación.
upstream crmdev { ip_hash; server 192.168.101.1:8080; server 192.168.101.2:8080; }
Para el hash, para la dirección IPv4, se utilizan los primeros tres octetos. Si es una dirección IPv6, se utiliza la dirección completa.
5. Opciones de peso para los servidores individuales
También puede especificar un peso para un servidor en particular en su grupo. Por defecto, todos los servidores tienen la misma prioridad (peso). es decir, el valor predeterminado de peso es 1.
Pero puede cambiar este comportamiento asignando un peso a un servidor como se muestra a continuación.
upstream crmdev { server 192.168.101.1:8080; server 192.168.101.2:8080; server 192.168.101.3:8080 weight 2; server 192.168.101.4:8080; server 192.168.101.5:8080; }
En este ejemplo, tenemos un total de 5 servidores. Pero el peso en el 3er servidor es 2. Esto significa que por cada 6 solicitudes nuevas, 2 solicitudes irán al 3er servidor y el resto del servidor recibirá 1 solicitud.
Por lo tanto, esto es útil para distribuir más carga en un servidor específico que tiene más potencia.
Aunque en el ejemplo anterior, el peso se usa con el algoritmo de turno rotativo predeterminado, también puede usar el peso para less_conn e ip_hash.
6. Opciones de tiempo de espera para servidores individuales:max_fails y fail_timeout
También puede especificar max_fails y fail_timeout para un servidor en particular, como se muestra a continuación.
upstream crmdev { server 192.168.101.1:8080 max_fails=3 fail_timeout=30s; server 192.168.101.2:8080; server 192.168.101.3:8080 weight 2; server 192.168.101.4:8080; server 192.168.101.5:8080; }
En lo anterior:
- El fail_timeout predeterminado es de 10 segundos. En este ejemplo anterior, esto se establece en 30 segundos. Esto significa que dentro de los 30 segundos si hubo una cantidad x de intentos fallidos (según lo definido por max_fails), el servidor no estará disponible. Además, el servidor no estará disponible durante 30 segundos.
- El max_fails predeterminado es 1 intento. En el ejemplo anterior, esto se establece en 3 intentos. Esto significa que después de 3 intentos fallidos de conectarse a este servidor en particular, Nginx considerará que este servidor no está disponible durante la duración de fail_timeout, que es de 30 segundos.
7. Asigne un servidor de respaldo en Nginx LoadBalancer Pool
En el siguiente ejemplo, el quinto servidor se marca como respaldo usando la palabra clave "respaldo" al final del parámetro del servidor.
upstream crmdev { server 192.168.101.1:8080 max_fails=3 fail_timeout=30s; server 192.168.101.2:8080; server 192.168.101.3:8080 weight 2; server 192.168.101.4:8080; server 192.168.101.5:8080 backup; }
Lo anterior hará que el quinto servidor (192.168.101.5) sea un servidor de respaldo. La solicitud entrante no se pasará a este servidor a menos que los otros 4 servidores estén caídos.