NGINX se usa comúnmente como servidor web, pero también hace un gran trabajo al actuar como proxy inverso y equilibrador de carga: un dispositivo de red diseñado para manejar la mayor parte de su tráfico y enrutar solicitudes a múltiples servidores web diferentes.
Cómo funciona el equilibrio de carga de NGINX
El principio básico de un Load Balancer es que se ubica entre el usuario y un conjunto de servidores, y representa las solicitudes de ellos. Normalmente esto se hace con dos o más servidores, para que el tráfico se pueda distribuir más fácilmente entre ellos.
La mayor parte de la configuración ocurre en cómo NGINX selecciona a qué servidor enrutar. El valor predeterminado es el round-robin, que enviará solicitudes a cada servidor en orden, asegurando una distribución equitativa de la carga.
Sin embargo, no siempre es tan sencillo. Muchas aplicaciones web requieren algún tipo de persistencia de la sesión, lo que significa que el usuario debe acceder al mismo servidor durante toda la sesión. Por ejemplo, un carrito de compras podría almacenarse localmente en un servidor de aplicaciones y, si el usuario cambia de servidor a mitad de sesión, la aplicación podría fallar. Por supuesto, muchos de estos escenarios se pueden solucionar con una mejor infraestructura de aplicaciones y almacenes de datos centralizados, pero muchas personas requieren la persistencia de la sesión.
En NGINX, el conjunto de servidores al que se enruta se conoce como upstream y se configura como una lista enumerada de direcciones:
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com;
}
Estos aguas arriba tener muchas opciones; aquí, hemos establecido un peso, que priorizará este servidor con mayor frecuencia (particularmente útil si tiene diferentes tamaños). También puede configurar las conexiones máximas y varios tiempos de espera. Si estas usando NGINX Plustambién puede configurar comprobaciones de estado para que las conexiones no se enruten a servidores en mal estado.
La forma más básica de persistencia de la sesión es utilizar un hash de IP. NGINX utilizará la IP para identificar a los usuarios y luego se asegurará de que estos usuarios no cambien de servidor a mitad de la sesión:
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
}
El hash de IP es necesario para aplicaciones basadas en sockets y cualquier cosa que requiera persistencia. Si no desea utilizar la dirección IP, puede personalizar este hash:
upstream backend {
hash $scheme$request_uri consistent;
server backend1.example.com;
server backend2.example.com;
}
Si no necesita ningún tipo de persistencia de sesión, puede hacer que la selección por turnos sea un poco más inteligente seleccionando qué servidor tiene menos conexiones:
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
O, según cuál esté respondiendo más rápido actualmente:
upstream backend {
least_time (header | last_byte);
server backend1.example.com;
server backend2.example.com;
}
NGINX Plus tiene algunas otras formas de persistencia de sesiónpero el hash de IP funcionará para la mayoría de las aplicaciones.
Proxy al backend
Una vez que haya configurado su backend, puede enviarle solicitudes desde sus bloques de ubicación, usando proxy_pass con un URI al backend.
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
}
}
Por supuesto, si utiliza HTTPS, deberá enviar la solicitud con HTTPS:
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/certs/server.crt;
ssl_certificate_key /etc/ssl/certs/server.key;
ssl_client_certificate /etc/ssl/certs/ca.crt;
location /{
proxy_pass https://backend;
}
}
