Upstream

Proporciona un contexto para describir grupos de servidores que pueden utilizarse en las directivas proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass y grpc_pass.

Ejemplo de configuración

upstream backend {
    zone backend 1m;
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server backend3.example.com       service=_example._tcp resolve;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

resolver 127.0.0.53 status_zone=resolver;

server {
    location / {
        proxy_pass http://backend;
    }
}

Directivas

backup_switch (PRO)

Added in version 1.9.0: PRO

Syntax	backup_switch permanent[=time];
Predeterminado	—
Context	upstream

La directiva habilita la capacidad de iniciar la selección de servidores no desde el grupo principal, sino desde el grupo activo, es decir, aquel donde se encontró un servidor con éxito la última vez. Si no se puede encontrar un servidor en el grupo activo para la siguiente solicitud, y la búsqueda se mueve al grupo de respaldo, entonces este grupo se convierte en activo, y las solicitudes posteriores se dirigen primero a los servidores de este grupo.

Si el parámetro permanent se define sin un valor time, el grupo permanece activo después de la selección, y no se produce una verificación automática de grupos con niveles inferiores. Si se especifica time, el estado activo del grupo expira después del intervalo especificado, y el balanceador vuelve a comprobar los grupos con niveles inferiores, volviendo a ellos si los servidores funcionan normalmente.

Ejemplo:

upstream my_backend {
    server primary1.example.com;
    server primary2.example.com;

    server backup1.example.com backup;
    server backup2.example.com backup;

    backup_switch permanent=2m;
}

Si el balanceador cambia de los servidores principales al grupo de respaldo, todas las solicitudes posteriores son manejadas por este grupo de respaldo durante 2 minutos. Después de que transcurran 2 minutos, el balanceador vuelve a verificar los servidores principales y los hace activos nuevamente si están funcionando normalmente.

bind_conn (PRO)

Syntax	bind_conn value;
Predeterminado	—
Context	upstream

Permite vincular una conexión de servidor a una conexión de cliente cuando el value, especificado como una cadena de variables, se vuelve diferente de "" y "0".

Advertencia

La directiva bind_conn debe usarse después de todas las directivas que establecen un método de balanceo de carga, de lo contrario no funcionará. Si se usa junto con la directiva sticky, entonces bind_conn debe ir después de sticky.

Advertencia

Al usar la directiva, la configuración del módulo Proxy debe permitir el uso de conexiones persistentes, por ejemplo:

proxy_http_version 1.1;
proxy_set_header Connection "";

Un caso de uso típico para la directiva es el proxy de conexiones con autenticación NTLM, donde es necesario asegurar la vinculación cliente-servidor al inicio de la negociación:

map $http_authorization   $ntlm {
    ~*^N(?:TLM|egotiate)  1;
}

upstream ntlm_backend {
    server 127.0.0.1:8080;
    bind_conn $ntlm;
}

server {
    # ...
    location / {
        proxy_pass http://ntlm_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        # ...
    }
}

feedback (PRO)

Added in version 1.6.0: PRO

Syntax	feedback variable [inverse] [factor=number] [account=condition_variable] [last_byte];
Predeterminado	—
Context	upstream

Configura un mecanismo de balanceo de carga basado en retroalimentación en el upstream. Ajusta dinámicamente las decisiones de balanceo multiplicando el peso de cada servidor proxy por el valor promedio de retroalimentación, que cambia con el tiempo dependiendo del valor de la variable y está sujeto a una condición opcional.

Se pueden especificar los siguientes parámetros:

variable	La variable de la que se toma el valor de retroalimentación. Debe representar una métrica de rendimiento o salud; se asume que el servidor la proporciona en cabeceras o de otra manera. El valor se evalúa con cada respuesta del servidor y se incorpora al promedio móvil según los ajustes de inverse y factor.
inverse	Si se establece este parámetro, el valor de retroalimentación se interpreta de manera inversa: valores más bajos indican mejor rendimiento.
factor	El factor por el cual se considera el valor de retroalimentación al calcular el promedio. Los valores válidos son enteros de 0 a 99. El valor predeterminado es 90. El promedio se calcula utilizando la fórmula de suavizado exponencial. Cuanto mayor sea el factor, menos afectan los nuevos valores al promedio; si se especifica 90, entonces se tomará el 90% del valor anterior y solo el 10% del nuevo valor.
account	Especifica una variable de condición que controla qué respuestas se consideran en el cálculo. El valor promedio se actualiza con el valor de retroalimentación de la respuesta solo si la variable de condición de esa respuesta no es igual a "" o "0". Nota Por defecto, las respuestas durante las comprobaciones activas no se incluyen en el cálculo; combinar la variable $upstream_probe con account permite incluir estas respuestas o incluso excluir todo lo demás.
last_byte	Permite procesar datos del servidor proxy después de recibir la respuesta completa, no solo la cabecera.

Ejemplo:

upstream backend {

    zone backend 1m;

    feedback $feedback_value factor=80 account=$condition_value;

    server backend1.example.com;
    server backend2.example.com;
}

map $upstream_http_custom_score $feedback_value {
    "high"                      100;
    "medium"                    75;
    "low"                       50;
    default                     10;
}

map $upstream_probe $condition_value {
    "high_priority" "1";
    "low_priority"  "0";
    default         "1";
}

Esta configuración categoriza las respuestas del servidor por niveles de retroalimentación basados en puntuaciones específicas de los campos de cabecera de respuesta, y también añade una condición en $upstream_probe para considerar solo las respuestas de la comprobación activa high_priority o las respuestas a solicitudes regulares de clientes.

hash

Syntax	hash key [consistent];
Predeterminado	—
Context	upstream

Especifica un método de balanceo de carga para un grupo de servidores donde la asignación cliente-servidor se basa en el valor hash de la clave. La clave puede contener texto, variables y sus combinaciones. Tenga en cuenta que añadir o eliminar un servidor del grupo puede resultar en la reasignación de la mayoría de las claves a diferentes servidores. El método es compatible con la biblioteca Perl Cache::Memcached.

Si se especifica el parámetro consistent, se utilizará el método de hash consistente ketama. Este método garantiza que solo unas pocas claves serán reasignadas a diferentes servidores cuando se añade o elimina un servidor del grupo. Esto ayuda a lograr una mayor tasa de aciertos de caché para los servidores de caché. El método es compatible con la biblioteca Perl Cache::Memcached::Fast con el parámetro ketama_points establecido en 160.

ip_hash

Syntax	ip_hash;
Predeterminado	—
Context	upstream

Especifica un método de balanceo de carga para el grupo donde las solicitudes se distribuyen entre servidores basándose en las direcciones IP de los clientes. Se utilizan los primeros tres octetos de la dirección IPv4 o la dirección IPv6 completa como clave de hash. El método garantiza que las solicitudes del mismo cliente siempre se pasarán al mismo servidor, excepto cuando este servidor se considere no disponible. En este caso, las solicitudes del cliente se pasarán a otro servidor, que probablemente también será el mismo servidor para ese cliente.

Si uno de los servidores necesita ser eliminado temporalmente, debe marcarse con el parámetro down para preservar el hash actual de direcciones IP de clientes:

upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
    server backend4.example.com;
}

keepalive

Syntax	keepalive connections;
Predeterminado	—
Context	upstream

Activa la caché para conexiones a servidores upstream.

El parámetro connections establece el número máximo de conexiones keepalive inactivas a servidores upstream que se conservan en la caché de cada proceso de trabajo. Cuando se excede este número, se cierran las conexiones menos utilizadas recientemente.

Nota

Cabe destacar especialmente que la directiva keepalive no limita el número total de conexiones a servidores upstream que un proceso worker de Angie puede abrir. El parámetro connections debe establecerse a un número lo suficientemente pequeño para permitir que los servidores upstream procesen también nuevas conexiones entrantes.

Advertencia

La directiva keepalive debe usarse después de todas las directivas que establece el método de balanceo de carga; de lo contrario, no funcionará.

Ejemplo de configuración de un upstream de memcached con conexiones keepalive:

upstream memcached_backend {
    server 127.0.0.1:11211;
    server 10.0.0.2:11211;

    keepalive 32;
}

server {
    #...

    location /memcached/ {
        set $memcached_key $uri;
        memcached_pass memcached_backend;
    }

}

Para HTTP, la directiva proxy_http_version debe establecerse a "1.1" y el campo de cabecera Connection debe eliminarse:

upstream http_backend {
    server 127.0.0.1:8080;

    keepalive 16;
}

server {
    #...

    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    #    ...
    }
}

Nota

Alternativamente, se pueden usar conexiones persistentes HTTP/1.0 pasando el campo de cabecera "Connection: Keep-Alive" a un servidor upstream, aunque este método no es recomendado.

Para FastCGI, es necesario establecer fastcgi_keep_conn para que funcionen las conexiones keepalive:

upstream fastcgi_backend {
    server 127.0.0.1:9000;

    keepalive 8;
}

server {
    #...

    location /fastcgi/ {
        fastcgi_pass fastcgi_backend;
        fastcgi_keep_conn on;
    #    ...
    }
}

Nota

Los protocolos SCGI y uwsgi no definen una semántica para conexiones keepalive.

keepalive_requests

Syntax	keepalive_requests number;
Predeterminado	keepalive_requests 1000;
Context	upstream

Establece el número máximo de peticiones que pueden ser servidas a través de una conexión keepalive. Después de alcanzar el número máximo de peticiones, la conexión se cierra.

Cerrar conexiones periódicamente es necesario para liberar las asignaciones de memoria por conexión. Por lo tanto, usar un número máximo de peticiones demasiado alto podría resultar en un uso excesivo de memoria y no es recomendable.

keepalive_time

Syntax	keepalive_time time;
Predeterminado	keepalive_time 1h;
Context	upstream

Limita el tiempo máximo durante el cual las peticiones pueden ser procesadas a través de una conexión keepalive. Después de alcanzar este tiempo, la conexión se cierra tras el procesamiento de la petición subsiguiente.

keepalive_timeout

Syntax	keepalive_timeout timeout;
Predeterminado	keepalive_timeout 60s;
Context	upstream

Establece un tiempo de espera durante el cual una conexión keepalive inactiva a un servidor upstream permanecerá abierta.

least_conn

Syntax	least_conn;
Predeterminado	—
Context	upstream

Especifica que un grupo debe usar un método de balanceo de carga donde una petición se pasa al servidor con el menor número de conexiones activas, teniendo en cuenta los pesos de los servidores. Si hay varios servidores de este tipo, se prueban por turnos utilizando un método de balanceo round-robin ponderado.

least_time (PRO)

Syntax	least_time header | last_byte [factor=number] [account=condition_variable];
Predeterminado	—
Context	upstream

Especifica que el grupo debe usar un método de balanceo de carga donde la probabilidad de que un servidor activo reciba la petición es inversamente proporcional a su tiempo medio de respuesta; cuanto menor sea, más peticiones recibe un servidor.

header	La directiva tiene en cuenta el tiempo medio para recibir las cabeceras de respuesta.
last_byte	La directiva utiliza el tiempo medio para recibir la respuesta completa.

Added in version 1.7.0: PRO

header	La directiva tiene en cuenta el tiempo promedio para recibir los encabezados de respuesta.
last_byte	La directiva utiliza el tiempo promedio para recibir la respuesta completa.

Added in version 1.7.0: PRO

factor

Sirve para el mismo propósito que response_time_factor (PRO) y lo anula si el parámetro está establecido.

account

Especifica una variable de condición que controla qué respuestas se incluyen en el cálculo. El promedio se actualiza solo si la variable de condición para la respuesta no es "" o "0". Nota Por defecto, las respuestas durante comprobaciones de salud activas no se incluyen en el cálculo; combinar la variable $upstream_probe con account permite incluir estas respuestas o incluso excluir todo lo demás.

Los valores actuales se presentan como header_time (solo encabezados) y response_time (respuestas completas) en el objeto health del servidor entre las métricas de upstream en la API.

queue (PRO)

Added in version 1.4.0: PRO

Syntax	queue número [timeout=tiempo];
Predeterminado	—
Context	upstream

Si no es posible asignar un servidor proxy a una solicitud en el primer intento (por ejemplo, durante una breve interrupción del servicio o cuando hay un aumento de carga que alcanza el límite max_conns), la solicitud no se rechaza; en su lugar, Angie intenta ponerla en cola para su procesamiento.

El parámetro número de la directiva establece el número máximo de solicitudes en la cola para un proceso de trabajo. Si la cola está llena, se devuelve un error 502 (Bad Gateway) al cliente.

Nota

La lógica de la directiva proxy_next_upstream también se aplica a las solicitudes en cola. Específicamente, si se seleccionó un servidor para una solicitud pero no se puede entregar a él, la solicitud puede devolverse a la cola.

Si no se selecciona un servidor para procesar una solicitud en cola dentro del tiempo establecido por timeout (por defecto es 60 segundos), se devuelve un error 502 (Bad Gateway) al cliente. Las solicitudes de clientes que cierran prematuramente la conexión también se eliminan de la cola; hay contadores para los estados de las solicitudes que pasan por la cola en la API.

Advertencia

La directiva queue debe usarse después de todas las directivas que establecen el método de balanceo de carga; de lo contrario, no funcionará.

random

Syntax	random [two];
Predeterminado	—
Context	upstream

Especifica un método de balanceo de carga para el grupo donde una solicitud se pasa a un servidor seleccionado aleatoriamente, teniendo en cuenta los pesos de los servidores.

Si se especifica el parámetro opcional two, Angie selecciona aleatoriamente dos servidores, luego selecciona uno de ellos usando el método least_conn, donde una solicitud se pasa al servidor con el menor número de conexiones activas.

response_time_factor (PRO)

Syntax	response_time_factor número;
Predeterminado	response_time_factor 90;
Context	upstream

Establece el factor de suavizado para el valor anterior al calcular el tiempo de respuesta promedio para el método de balanceo de carga least_time (PRO) utilizando la fórmula de media móvil ponderada exponencialmente.

Cuanto mayor sea el número especificado, menos afectarán los nuevos valores al promedio; si se especifica 90, se tomará el 90% del valor anterior y solo el 10% del nuevo valor. Los valores permitidos van de 0 a 99, inclusive.

Los resultados de cálculo actuales se presentan como header_time (solo encabezados) y response_time (respuestas completas) en el objeto health entre las métricas de upstream en la API.

Nota

Solo las respuestas exitosas se incluyen en el cálculo; lo que se considera una respuesta no exitosa está definido por las directivas proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, memcached_next_upstream, y grpc_next_upstream. Además, el valor header_time se recalcula solo si todos los encabezados son recibidos y procesados, y response_time se recalcula solo si se recibe la respuesta completa.

server

Syntax	server dirección [parámetros];
Predeterminado	—
Context	upstream

Define la dirección y otros parámetros de un servidor. La dirección puede especificarse como un nombre de dominio o dirección IP, con un puerto opcional, o como una ruta de socket UNIX especificada después del prefijo unix:. Si no se especifica un puerto, se utiliza el puerto 80. Un nombre de dominio que se resuelve a varias direcciones IP define varios servidores a la vez.

Los siguientes parámetros pueden definirse:

weight=number	Establece el peso del servidor. El valor predeterminado es 1.
max_conns=number	Limita el número máximo de conexiones activas simultáneas al servidor proxy. El valor predeterminado es 0, lo que significa que no hay límite. Si el grupo de servidores no reside en la memoria compartida, la limitación funciona para cada proceso de trabajo.

Nota

Si las conexiones inactivas keepalive, múltiples procesos de trabajo y la memoria compartida están habilitados, el número total de conexiones activas e inactivas al servidor proxy puede exceder el valor max_conns.

max_fails=number — establece el número de intentos fallidos de comunicación con el servidor que deben ocurrir en la duración establecida por fail_timeout para considerar que el servidor no está disponible; luego se reintenta después de la misma duración.

Lo que se considera un intento fallido está definido por las directivas proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, memcached_next_upstream, y grpc_next_upstream.

Cuando se alcanza max_fails, el servidor también se considera no saludable por las sondas upstream_probe (PRO); no recibirá solicitudes de clientes hasta que las sondas lo consideren saludable nuevamente.

Nota

Si una directiva server en un grupo se resuelve en múltiples servidores, su configuración max_fails se aplica a cada servidor individualmente.

Si un upstream contiene solo un servidor después de que todas sus directivas server son resueltas, la configuración max_fails no tiene efecto y será ignorada.

max_fails=1	el número predeterminado de intentos
max_fails=0	desactiva el conteo de intentos

fail_timeout=time — establece el período de tiempo durante el cual debe ocurrir un número específico de intentos fallidos de comunicación con el servidor (max_fails) para considerar que el servidor no está disponible. El servidor permanece no disponible durante la misma cantidad de tiempo antes de que se vuelva a intentar.

Por defecto, esto se establece en 10 segundos.

Nota

Si una directiva server en un grupo se resuelve en múltiples servidores, su configuración fail_timeout se aplica a cada servidor individualmente.

Si un upstream contiene solo un servidor después de que todas sus directivas server son resueltas, la configuración fail_timeout no tiene efecto y será ignorada.

backup	marca el servidor como un servidor de respaldo. Recibirá solicitudes cuando los servidores primarios no estén disponibles. Si la directiva backup_switch (PRO) está configurada, también se aplica su lógica de respaldo activo.
down	marca el servidor como permanentemente no disponible.
drain (PRO)	marca el servidor como drenado; esto significa que solo recibe solicitudes de las sesiones que fueron vinculadas anteriormente con sticky. De lo contrario, se comporta de manera similar a down.

Advertencia

El parámetro backup no puede usarse junto con los métodos de balanceo de carga hash, ip_hash y random.

Los parámetros down y drain son mutuamente excluyentes.

Added in version 1.1.0.

resolve

habilita el monitoreo de cambios en la lista de direcciones IP que corresponden a un nombre de dominio, actualizándola sin recargar la configuración. El grupo debe almacenarse en una zona de memoria compartida; además, necesitas definir un resolver.

service=name

habilita la resolución de registros DNS SRV y establece el nombre del servicio. Para que este parámetro funcione, especifica el parámetro resolve del servidor, proporcionando un nombre de host sin número de puerto. Si no hay puntos en el nombre del servicio, el nombre se forma según el estándar RFC: el nombre del servicio se prefija con _, luego se añade _tcp después de un punto. Por lo tanto, el nombre de servicio http resultará en _http._tcp. Angie resuelve los registros SRV combinando el nombre de servicio normalizado y el nombre de host y obteniendo la lista de servidores para la combinación a través de DNS, junto con sus prioridades y pesos. Los registros SRV de máxima prioridad (aquellos que comparten el valor mínimo de prioridad) se resuelven en servidores primarios, y otros registros se convierten en servidores de respaldo. Si backup se establece con server, los registros SRV de máxima prioridad se resuelven en servidores de respaldo, y otros registros son ignorados. El peso es similar al parámetro weight de la directiva server. Si el peso se establece tanto por la directiva como por el registro SRV, se utiliza el peso establecido por la directiva.

Este ejemplo buscará el registro _http._tcp.backend.example.com:

server backend.example.com service=http resolve;

Added in version 1.2.0: Angie

Added in version 1.1.0-P1: Angie PRO

sid=id

establece el ID del servidor dentro del grupo. Si el parámetro no está establecido, el ID se establece como el hash MD5 hexadecimal de la dirección IP y el puerto o la ruta del socket UNIX.

Added in version 1.4.0.

slow_start=time

Establece el tiempo para que un servidor que vuelve al servicio recupere su peso cuando el balanceo de carga utiliza el método round-robin o least_conn. Si el parámetro está configurado y el servidor se considera nuevamente saludable después de un fallo según lo definido por max_fails y upstream_probe (PRO), el servidor recuperará gradualmente su peso designado dentro del período de tiempo especificado. Si el parámetro no está configurado, en una situación similar el servidor comenzará inmediatamente a trabajar con su peso designado.

Nota

Si hay solo un server en un upstream, slow_start no tiene efecto y será ignorado.

state (PRO)

Added in version 1.2.0: PRO

Syntax	state file;
Predeterminado	—
Context	upstream

Especifica el archivo donde se almacena de forma persistente la lista de servidores del upstream. Al instalar desde nuestros paquetes, se crea un directorio designado /var/lib/angie/state/ (/var/db/angie/state/ en FreeBSD) con los permisos apropiados para almacenar estos archivos, por lo que solo necesita añadir el nombre del archivo en la configuración:

upstream backend {

    zone backend 1m;
    state /var/lib/angie/state/<NOMBRE DEL ARCHIVO>;
}

El formato de la lista de servidores aquí es similar a server. El contenido del archivo cambia cada vez que se modifican los servidores en la sección /config/http/upstreams/ a través de la API de configuración. El archivo se lee al iniciar Angie o al recargar la configuración.

Advertencia

Para usar la directiva state en un bloque upstream, no debe haber directivas server en él, pero se requiere una zona de memoria compartida (zone).

sticky

Added in version 1.2.0: Angie

Added in version 1.1.0-P1: Angie PRO

Syntax	sticky cookie name [attr=value]...; sticky route $variable...; sticky learn zone=zone create=$create_var1... lookup=$lookup_var1... [header] [norefresh] [timeout=time]; sticky learn [zone=zone] lookup=$lookup_var1... remote_action=uri remote_result=$remote_var [norefresh] [timeout=time];
Predeterminado	—
Context	upstream

Configura la vinculación de sesiones de cliente a servidores proxy en el modo especificado por el primer parámetro; para drenar servidores que tienen configurada la directiva sticky, puede usar la opción drain (PRO) en el bloque server.

Advertencia

La directiva sticky debe usarse después de todas las directivas que establecen un método de balanceo de carga; de lo contrario, no funcionará. Si se usa junto con la directiva bind_conn (PRO), bind_conn debe aparecer después de sticky.

Modo cookieModo routeModo learn (PRO 1.4.0+)Modo learn con remote_action (PRO 1.8.0+)

Este modo utiliza cookies para mantener la persistencia de sesión. Es más adecuado para situaciones donde las cookies ya se utilizan para la gestión de sesiones.

Aquí, una solicitud de cliente, que aún no está vinculada a ningún servidor, se envía a un servidor elegido según el método de balanceo configurado. Además, Angie establece una cookie con un valor único que identifica al servidor.

El nombre de la cookie (name) se establece mediante la directiva sticky, y el valor (value) corresponde al parámetro sid de la directiva server. Tenga en cuenta que el parámetro se cifra adicionalmente si la directiva sticky_secret está configurada.

Las solicitudes posteriores del cliente que contengan esta cookie se reenvían al servidor identificado por el valor de la cookie, que es el servidor con el sid especificado. Si la selección de un servidor falla o el servidor elegido no puede manejar la solicitud, se selecciona otro servidor según el método de balanceo configurado.

La directiva permite asignar atributos a la cookie; el único atributo establecido por defecto es path=/. Los valores de los atributos se especifican como cadenas con variables. Para eliminar un atributo, establezca un valor vacío para él: attr=. Así, sticky cookie path= crea una cookie sin path.

Aquí, Angie crea una cookie llamada srv_id con una duración de una hora y un dominio especificado por variable:

upstream backend {
    server backend1.example.com:8080;
    server backend2.example.com:8080;

    sticky cookie srv_id domain=$my_domain max-age=3600;
}

sticky_secret

Added in version 1.2.0: Angie

Added in version 1.1.0-P1: Angie PRO

Syntax	sticky_secret string;
Predeterminado	—
Context	upstream

Añade el string como valor de sal a la función de hash MD5 para la directiva sticky en los modos cookie y route. El string puede contener variables, por ejemplo, $remote_addr:

upstream backend {
    server backend1.example.com:8080;
    server backend2.example.com:8080;

    sticky cookie cookie_name;
    sticky_secret my_secret.$remote_addr;
}

La sal se añade al valor que se está hasheando; para verificar el mecanismo de hash de forma independiente:

$ echo -n "<VALUE><SALT>" | md5sum

sticky_strict

Added in version 1.2.0: Angie

Added in version 1.1.0-P1: Angie PRO

Syntax	sticky_strict on | off;
Predeterminado	sticky_strict off;
Context	upstream

Cuando está habilitado, hace que Angie devuelva un error HTTP 502 al cliente si el servidor deseado no está disponible, en lugar de usar cualquier otro servidor disponible como lo haría cuando no hay servidores disponibles en el upstream.

upstream

Syntax	upstream name { ... }
Predeterminado	—
Context	http

Define un grupo de servidores. Los servidores pueden escuchar en diferentes puertos. Además, se pueden mezclar servidores que escuchan en sockets TCP y de dominio UNIX.

Ejemplo:

upstream backend {
    server backend1.example.com weight=5;
    server 127.0.0.1:8080       max_fails=3 fail_timeout=30s;
    server unix:/tmp/backend3;

    server backup1.example.com  backup;
}

Por defecto, las solicitudes se distribuyen entre los servidores utilizando un método de balanceo de carga ponderado round-robin. En el ejemplo anterior, cada 7 solicitudes se distribuirán de la siguiente manera: 5 solicitudes van a backend1.example.com y una solicitud a cada uno de los servidores segundo y tercero.

Si ocurre un error durante la comunicación con un servidor, la solicitud se pasará al siguiente servidor, y así sucesivamente hasta que se hayan probado todos los servidores en funcionamiento. Si no se pudo obtener una respuesta exitosa de ninguno de los servidores, el cliente recibirá el resultado de la comunicación con el último servidor.

zone

Syntax	zone name [size];
Predeterminado	—
Context	upstream

Define el nombre y tamaño de la zona de memoria compartida que mantiene la configuración del grupo y el estado de ejecución que se comparte entre los procesos de trabajo. Varios grupos pueden compartir la misma zona. En este caso, es suficiente especificar el tamaño solo una vez.

Variables Integradas

El módulo http_upstream admite las siguientes variables integradas:

$sticky_sessid

Se utiliza con remote_action en sticky; almacena el ID de sesión inicial tomado de lookup.

$sticky_sid

Se utiliza con remote_action en sticky; almacena el ID del servidor previamente asociado con la sesión.

$upstream_addr

almacena la dirección IP y el puerto, o la ruta al socket de dominio UNIX del servidor upstream. Si se contactaron varios servidores durante el procesamiento de la solicitud, sus direcciones se separan por comas, por ejemplo:

192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock

Si ocurre una redirección interna de un grupo de servidores a otro, iniciada por X-Accel-Redirect o error_page, entonces las direcciones de los servidores de diferentes grupos se separan por dos puntos, por ejemplo:

192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80

Si no se puede seleccionar un servidor, la variable mantiene el nombre del grupo de servidores.

$upstream_bytes_received

número de bytes recibidos de un servidor upstream. Los valores de varias conexiones se separan por comas y dos puntos como las direcciones en la variable $upstream_addr.

$upstream_bytes_sent

número de bytes enviados a un servidor upstream. Los valores de varias conexiones se separan por comas y dos puntos como las direcciones en la variable $upstream_addr.

$upstream_cache_status

mantiene el estado de acceso a una caché de respuestas. El estado puede ser MISS, BYPASS, EXPIRED, STALE, UPDATING, REVALIDATED, o HIT:

• MISS: La respuesta no se encuentra en la caché, y la solicitud se reenvía al servidor upstream.

• BYPASS: La caché se omite, y la solicitud se reenvía directamente al servidor upstream.

• EXPIRED: La respuesta en caché está obsoleta, y se envía una nueva solicitud para el contenido actualizado al servidor upstream.

• STALE: La respuesta en caché está obsoleta, pero se servirá a los clientes hasta que eventualmente se obtenga una actualización del servidor upstream.

• UPDATING: La respuesta en caché está obsoleta, pero se servirá a los clientes hasta que se complete la actualización actualmente en curso desde el servidor upstream.

• REVALIDATED: La respuesta en caché está obsoleta, pero se revalida con éxito y no necesita una actualización del servidor upstream.

• HIT: La respuesta se sirvió desde la caché.

Si la caché se omitió por completo sin acceder a ella, la variable no se establece.

$upstream_connect_time

mantiene el tiempo empleado en establecer una conexión con el servidor upstream; el tiempo se mantiene en segundos con resolución de milisegundos. En caso de SSL, incluye el tiempo empleado en el handshake. Los tiempos de varias conexiones se separan por comas y dos puntos como las direcciones en la variable $upstream_addr.

$upstream_cookie_<name>

cookie con el nombre especificado enviada por el servidor upstream en el campo de cabecera de respuesta Set-Cookie. Solo se guardan las cookies de la respuesta del último servidor.

$upstream_header_time

mantiene el tiempo empleado en recibir la cabecera de respuesta del servidor upstream; el tiempo se mantiene en segundos con resolución de milisegundos. Los tiempos de varias respuestas se separan por comas y dos puntos como las direcciones en la variable $upstream_addr.

$upstream_http_<name>

mantiene los campos de cabecera de respuesta del servidor. Por ejemplo, el campo de cabecera de respuesta Server está disponible a través de la variable $upstream_http_server. Las reglas para convertir los nombres de los campos de cabecera a nombres de variables son las mismas que para las variables que comienzan con el prefijo $http_. Solo se guardan los campos de cabecera de la respuesta del último servidor.

$upstream_queue_time

mantiene el tiempo que la solicitud pasó en la cola antes de que se seleccionara un servidor; el tiempo se mantiene en segundos con resolución de milisegundos. Los tiempos de varios intentos de selección se separan por comas y dos puntos, como las direcciones en la variable $upstream_addr.

$upstream_response_length

mantiene la longitud de la respuesta obtenida del servidor upstream; la longitud se mantiene en bytes. Las longitudes de varias respuestas están separadas por comas y dos puntos como las direcciones en la variable $upstream_addr.

$upstream_response_time

mantiene el tiempo empleado en recibir la respuesta del servidor upstream; el tiempo se mantiene en segundos con resolución de milisegundos. Los tiempos de varias respuestas están separados por comas y dos puntos como las direcciones en la variable $upstream_addr.

$upstream_status

mantiene el código de estado de la respuesta obtenida del servidor upstream. Los códigos de estado de varias respuestas están separados por comas y dos puntos como las direcciones en la variable $upstream_addr. Si no se puede seleccionar un servidor, la variable mantiene el código de estado 502 (Bad Gateway).

$upstream_sticky_status

Estado de las peticiones sticky.

""	Petición enviada al upstream sin sticky habilitado.
NEW	Petición sin información sticky.
HIT	Petición con información sticky enrutada al servidor deseado.
MISS	Petición con información sticky enrutada al servidor seleccionado por el algoritmo de balanceo de carga.

Los valores de múltiples conexiones están separados por comas y dos puntos, similar a las direcciones en la variable $upstream_addr.

$upstream_trailer_<name>

mantiene los campos del final de la respuesta obtenida del servidor upstream.