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

Sintaxis	backup_switch permanent[=time];
Predeterminado	—
Contexto	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)

Sintaxis	bind_conn value;
Predeterminado	—
Contexto	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)

Sintaxis	feedback variable [inverse] [factor=number] [account=condition_variable] [last_byte];
Predeterminado	—
Contexto	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

Sintaxis	hash key [consistent];
Predeterminado	—
Contexto	upstream

Especifica un método de balanceo de carga para un grupo de servidores donde la asignación cliente-servidor se determina utilizando 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.

hash $remote_addr;

Al usar nombres de dominio que se resuelven en múltiples direcciones IP (por ejemplo, con el parámetro resolve), el servidor no ordena las direcciones recibidas, por lo que su orden puede diferir entre diferentes servidores, lo que afecta la distribución de clientes. Para garantizar una distribución consistente, use el parámetro consistent.

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

Sintaxis	ip_hash;
Predeterminado	—
Contexto	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

Sintaxis	keepalive connections;
Predeterminado	—
Contexto	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 establecen 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 servidores 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 tienen un concepto de conexiones keepalive.

keepalive_requests

Sintaxis	keepalive_requests number;
Predeterminado	keepalive_requests 1000;
Contexto	upstream

Establece el número máximo de solicitudes que pueden ser servidas a través de una conexión keepalive. Después de alcanzar el número máximo de solicitudes, 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 solicitudes demasiado alto podría resultar en un uso excesivo de memoria y no es recomendable.

keepalive_time

Sintaxis	keepalive_time time;
Predeterminado	keepalive_time 1h;
Contexto	upstream

Limita el tiempo máximo durante el cual las solicitudes 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 solicitud subsiguiente.

keepalive_timeout

Sintaxis	keepalive_timeout timeout;
Predeterminado	keepalive_timeout 60s;
Contexto	upstream

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

least_conn

Sintaxis	least_conn;
Predeterminado	—
Contexto	upstream

Especifica que un grupo debe usar un método de balanceo de carga donde una solicitud 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)

Sintaxis	least_time header | last_byte [factor=number] [account=condition_variable];
Predeterminado	—
Contexto	upstream

Especifica que el grupo debe usar un método de balanceo de carga donde la probabilidad de que un servidor activo reciba la solicitud es inversamente proporcional a su tiempo medio de respuesta; cuanto menor sea, más solicitudes 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.

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 cabeceras) y response_time (respuestas completas) en el objeto health del servidor entre las métricas de upstream en la API.

queue (PRO)

Sintaxis	queue number [timeout=time];
Predeterminado	—
Contexto	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 number 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

Sintaxis	random [two];
Predeterminado	—
Contexto	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)

Sintaxis	response_time_factor number;
Predeterminado	response_time_factor 90;
Contexto	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 number 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 cabeceras) 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 todas las cabeceras son recibidas y procesadas, y response_time se recalcula solo si se recibe la respuesta completa.

server

Sintaxis	server address [parameters];
Predeterminado	—
Contexto	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.

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;

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.

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 se define 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 solo hay un server en un upstream, slow_start no tiene efecto y será ignorado.

state (PRO)

Sintaxis	state file;
Por defecto	—
Contexto	upstream

Especifica el file 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 agregar el nombre del archivo en la configuración:

upstream backend {

    zone backend 1m;
    state /var/lib/angie/state/<FILE NAME>;
}

El formato de la lista de servidores aquí es similar a server. El contenido del archivo cambia cada vez que se modifican servidores en la sección /config/http/upstreams/ a través de la API de configuración. El archivo se lee al inicio de 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

Sintaxis	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];
Por defecto	—
Contexto	upstream

Configura la persistencia de sesión del cliente a servidores backend, utilizando el modo especificado en el primer parámetro. Para retirar gradualmente servidores con la directiva sticky, puede usar la opción drain (PRO) en el bloque server.

Advertencia

La directiva sticky debe aparecer después de todas las directivas de método de balanceo de carga. De lo contrario, no funcionará. Si se usa junto con bind_conn (PRO), entonces bind_conn debe venir después de sticky.

Modo cookieModo routeModo learn (PRO 1.4.0+)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;
}

The sticky directive respects upstream server states:

• Servers marked down or failing are excluded.

• Servers over max_conns limit are skipped.

• drain servers (PRO) may still be selected for new sessions in sticky mode when identifiers match.

• Recovered servers are reused automatically.

You can further adjust behavior using sticky_secret and sticky_strict. If stickiness fails and sticky_strict is off, fallback balancing is used; if on, the request is rejected.

Each zone used in sticky must be exclusive to a single upstream. Zones cannot be shared across multiple upstream blocks.

sticky_secret

Sintaxis	sticky_secret string;
Predeterminado	—
Contexto	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

Sintaxis	sticky_strict on | off;
Predeterminado	sticky_strict off;
Contexto	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

Sintaxis	upstream name { ... }
Predeterminado	—
Contexto	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 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

Sintaxis	zone name [size];
Predeterminado	—
Contexto	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.

Nota

El contenido de la zona solo se conserva en una recarga cuando el size configurado no cambia. Cualquier cambio de tamaño —aumento o reducción— provoca que la zona se vuelva a crear vacía.

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 pasa al servidor upstream.

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

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

• STALE: La respuesta en caché está obsoleta, pero aún se sirve a los clientes hasta que el contenido se actualice eventualmente desde el servidor upstream.

• UPDATING: La respuesta en caché está obsoleta, pero aún se sirve a los clientes mientras la actualización actualmente en curso desde el servidor upstream está en progreso.

• REVALIDATED: La respuesta en caché está obsoleta, pero se revalidó con éxito y no necesita actualizarse desde el servidor upstream.

• HIT: La respuesta se tomó de la caché.

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

$upstream_cache_key

contiene la clave de caché utilizada para la solicitud.

$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_request_method

método de solicitud utilizado para la solicitud upstream. Puede diferir del método de solicitud del cliente cuando la caché convierte HEAD a GET o cuando proxy_method está configurado.

$upstream_queue_time

mantiene el tiempo que la solicitud pasó en la cola antes de la siguiente selección de servidor; el tiempo se mantiene en segundos con resolución de milisegundos. Los tiempos de varios intentos 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 se separan 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 se separan 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 se separan 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 solicitudes sticky.

""	Solicitud enviada a un upstream donde sticky no está habilitado.
NEW	La solicitud no contiene información sticky.
HIT	Solicitud con información sticky enviada al servidor deseado.
MISS	Solicitud con información sticky enviada a un servidor seleccionado por el algoritmo de balanceo de carga.

Los estados de varias conexiones se separan por comas y dos puntos como las direcciones en la variable $upstream_addr.

$upstream_trailer_<name>

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