Balanceo de carga con nginx: upstream, métodos y comprobaciones de salud
Balanceo de carga con nginx
Balanceador de carga nginx: upstream, métodos, pesos y salud | We.Inc
Configura nginx como balanceador de carga: el bloque upstream, round robin, least_conn, ip_hash y hash, pesos, max_fails y fail_timeout, servidores de respaldo y un generador de configuración.
Para balancear carga con nginx, enumera tus servidores de aplicación en un bloque upstream y apunta proxy_pass a su nombre. Las peticiones se reparten en round robin salvo que añadas least_conn, ip_hash, hash o random. Cada línea server puede llevar weight, max_fails y fail_timeout para comprobaciones de salud pasivas, además de los flags backup o down.
Métodos de balanceo de carga de nginx
Directiva
Cómo elige un servidor
Ideal para
(ninguna)
Round robin ponderado, el valor por defecto
Servidores parecidos y peticiones cortas
Menos conexiones activas, teniendo en cuenta los pesos
Peticiones de duración muy distinta
Hash de la dirección del cliente (los tres primeros octetos en IPv4, la dirección completa en IPv6)
Mantener a un visitante en un mismo servidor
hash key
Hash de cualquier valor, como $request_uri
Afinidad de caché; añade consistent para limitar las reasignaciones
Servidor aleatorio, o el mejor de dos con random two
Varios balanceadores compartiendo un mismo pool
Repartir el tráfico entre varias copias de una aplicación es una de las tareas más antiguas de nginx, y toda la configuración cabe en una docena de líneas. El generador de abajo escribe el bloque upstream a partir de una lista de servidores, avisa de las combinaciones que nginx rechaza y muestra la parte de peticiones de cada servidor cuando se aplican pesos. La referencia que sigue cubre cada parámetro de server con su valor por defecto.
Añade en el generador la dirección y el puerto de cada servidor de aplicación, con un peso si algunas máquinas son más potentes que otras.
Elige un método. Déjalo en round robin salvo que las peticiones varíen mucho de duración o los visitantes deban quedarse en un mismo servidor.
Copia el resultado en el contexto http, por ejemplo en un archivo de conf.d, y ejecuta nginx -t.
Recarga con nginx -s reload, luego detén un servidor de aplicación y observa cómo las peticiones pasan a los demás.
Un único servidor en un upstream ignora max_fails y fail_timeout, así que las comprobaciones pasivas solo importan con dos o más.
Marca un servidor como down en lugar de borrar la línea cuando uses ip_hash. Así el hash de la dirección de cada otro cliente sigue apuntando adonde apuntaba antes.
Los servidores backup solo reciben tráfico cuando todos los principales están caídos, y no se pueden combinar con hash, ip_hash ni random.
Qué fallos cuentan para max_fails lo decide proxy_next_upstream. Por defecto cuentan los errores y los timeouts; un HTTP 500 no cuenta salvo que lo incluyas.
Añade keepalive con proxy_http_version 1.1 y una cabecera Connection vacía para reutilizar las conexiones con los backends en lugar de abrir una por petición.
Preguntas frecuentes
¿nginx de código abierto tiene comprobaciones de salud activas?
No. La directiva health_check pertenece al producto comercial NGINX Plus. nginx de código abierto depende de comprobaciones pasivas: si una petición a un servidor falla max_fails veces dentro de fail_timeout, el servidor se omite durante fail_timeout y luego se vuelve a probar con tráfico real.
¿Cuáles son los valores por defecto de max_fails y fail_timeout?
max_fails vale 1 por defecto y fail_timeout 10 segundos. Por tanto, un solo intento fallido saca a un servidor durante diez segundos. Con max_fails=0 se desactiva el recuento para ese servidor.
¿Cómo hago sesiones persistentes en nginx?
Usa ip_hash para mantener cada dirección de cliente en un servidor, o hash con una variable de cookie como $cookie_session para un control más fino. Las directivas sticky basadas en cookies solo existen en la edición comercial.
¿Qué hace el parámetro weight?
Cambia cuántas peticiones recibe un servidor en relación con los demás. Con pesos 3, 1 y 1, el primer servidor recibe unas tres de cada cinco peticiones en round robin. El peso por defecto es 1.
¿Puede nginx balancear conexiones WebSocket?
Sí. Apunta proxy_pass al upstream y reenvía las cabeceras Upgrade y Connection. least_conn encaja mejor que round robin con sockets de larga duración, porque cuenta cuántas conexiones tiene ya cada servidor.
Dónde va cada pieza
El bloque upstream vive en el contexto http, junto a tus bloques server. Solo da nombre a un pool; no pasa nada hasta que un location dice proxy_pass http://name. El mismo pool lo pueden usar muchos location y muchos bloques server.
Comprobaciones de salud pasivas, paso a paso
Cuando una petición a un servidor falla de una forma que proxy_next_upstream cuenta, nginx la reintenta en el siguiente servidor y anota el fallo. En cuanto un servidor alcanza max_fails fallos dentro de la ventana fail_timeout, nginx deja de elegirlo. Pasado fail_timeout, vuelve a enviarle con cuidado peticiones reales de clientes, y un éxito lo devuelve a la rotación.
Como las comprobaciones viajan sobre tráfico real, un visitante puede toparse con el primer intento fallido. Unos timeouts cortos en proxy_connect_timeout mantienen pequeño ese retraso.
Parámetros de server y sus valores por defecto
Parámetros de una línea server dentro de upstream
Parámetro
Por defecto
Efecto
weight=n
Parte relativa de las peticiones
max_fails=n
Intentos fallidos dentro de fail_timeout antes de omitir el servidor; 0 lo desactiva
fail_timeout=time
Ventana para contar fallos y tiempo durante el que se omite el servidor
max_conns=n
0 (sin límite)
Tope de conexiones activas simultáneas a este servidor
Solo se usa cuando todos los servidores principales están caídos
Marca el servidor como no disponible de forma permanente
Ejemplos completos
Round robin con un servidor de reserva
Dos principales se reparten la carga; el tercero solo responde si los dos están caídos.
least_conn con conexiones reutilizadas
keepalive guarda en caché las conexiones inactivas con los backends; las dos líneas de proxy hacen que funcione.
Afinidad de caché por URL
Cada URL sigue llegando al mismo servidor de caché; consistent mantiene intactas la mayoría de las asignaciones al añadir o quitar un servidor.
Nombre del upstream
Método
Round robin (por defecto)
Clave de hash
Conexiones keepalive inactivas (0 para ninguna)
Servidores
Dirección y puerto
Peso
fail_timeout (s)
Parte
Quitar servidor {n}
Añadir servidor
nginx rechaza los servidores backup con hash, ip_hash y random. Quita el flag backup o cambia el método.
Todos los servidores principales están marcados como down, así que ninguno puede recibir tráfico.