# Upstream Proporciona un contexto para describir grupos de servidores que pueden usarse en la directiva [proxy_pass](https://es.angie.software//angie/docs/configuration/modules/stream/stream_proxy.md#s-proxy-pass). ## Ejemplo de configuración ```nginx upstream backend { hash $remote_addr consistent; zone backend 1m; server backend1.example.com:1935 weight=5; server unix:/tmp/backend3; server backend3.example.com service=_example._tcp resolve; server backup1.example.com:1935 backup; server backup2.example.com:1935 backup; } resolver 127.0.0.53 status_zone=resolver; server { listen 1936; proxy_pass backend; } ``` ## Directivas ### upstream | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `upstream` name { ... } | |--------------------------------------------------------------------------------------------|---------------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | stream | Describe un grupo de servidores. Los servidores pueden escuchar en diferentes puertos. Además, se pueden mezclar servidores que escuchen en sockets TCP y de dominio UNIX. Ejemplo: ```nginx upstream backend { server backend1.example.com:1935 weight=5; server 127.0.0.1:1935 max_fails=3 fail_timeout=30s; server unix:/tmp/backend2; server backend3.example.com:1935 resolve; server backup1.example.com:1935 backup; } ``` De forma predeterminada, las conexiones se distribuyen entre los servidores utilizando un método de balanceo round-robin ponderado. En el ejemplo anterior, cada 7 conexiones se distribuyen de la siguiente forma: 5 conexiones van a backend1.example.com:1935 y una conexión a cada uno de los servidores segundo y tercero. Si ocurre un error durante la comunicación con un servidor, la conexión se pasará al siguiente servidor, y así sucesivamente hasta que se prueben todos los servidores en funcionamiento. Si la comunicación con todos los servidores falla, la conexión se cerrará. ### server | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `server` address [parameters]; | |--------------------------------------------------------------------------------------------|----------------------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Define la dirección y otros parámetros de un servidor. La dirección puede especificarse como un nombre de dominio o una dirección IP con un puerto obligatorio, o como una ruta de socket de dominio UNIX especificada tras el prefijo `unix:`. Un nombre de dominio que resuelva en varias direcciones IP define múltiples servidores a la vez. Se pueden definir los siguientes parámetros: | `weight=`number | Establece el peso del servidor; por defecto, 1. | |--------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `max_conns=`number | Limita el número máximo de conexiones activas simultáneas al servidor proxy. El valor por defecto es `0`, lo que significa que no hay límite. Si el grupo de servidores no reside en la [memoria compartida](#s-u-zone), la limitación funciona por cada proceso worker. | `max_fails=`number — establece el número de intentos fallidos de comunicación con el servidor que deben ocurrir en el período definido por [fail_timeout](#s-fail-timeout) para considerar al servidor como no disponible; luego se reintenta tras el mismo período. Aquí, un intento fallido es un error o timeout al establecer una conexión con el servidor. #### NOTE Si una directiva `server` en un grupo resuelve en varios 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` se resuelvan, la configuración `max_fails` no tiene efecto y será ignorada. | `max_fails=1` | Número de intentos por defecto. | |-----------------|-----------------------------------| | `max_fails=0` | Desactiva el cómputo de intentos. | `fail_timeout=`time — establece el período de tiempo durante el cual debe ocurrir un número especificado de intentos fallidos de comunicación con el servidor ([max_fails](#s-max-fails)) para considerarlo no disponible. El servidor permanece no disponible durante la misma cantidad de tiempo antes de que se vuelva a intentar. Por defecto, está configurado en 10 segundos. #### NOTE Si una directiva `server` en un grupo resuelve en varios 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` se resuelvan, la configuración `fail_timeout` no tiene efecto y será ignorada. | `backup` | Marca el servidor como servidor de respaldo. Se le pasarán peticiones cuando los servidores principales no estén disponibles. | |---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `down` | Marca el servidor como no disponible de forma permanente. | | `drain` (PRO) | Marca el servidor como en drenaje; esto significa
que solo recibe peticiones de las sesiones
que fueron vinculadas anteriormente con [sticky](#s-u-sticky).
De lo contrario, se comporta de forma similar a `down`. | #### WARNING El parámetro `backup` no puede usarse junto con los métodos de balanceo de carga [hash](#s-u-hash) y [random](#s-u-random). Los parámetros `down` y `drain` son mutuamente excluyentes. | `resolve` | Habilita la monitorización de cambios en la lista de direcciones IP que corresponde a un nombre de dominio, actualizándola sin necesidad de recargar la configuración.
El grupo debe residir en una [zona de memoria compartida](#s-u-zone); además, debe definirse un [resolver](https://es.angie.software//angie/docs/configuration/modules/stream/index.md#s-resolver). | |----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `service=`name | Habilita la resolución de registros DNS SRV y establece el nombre del servicio.
Para que este parámetro funcione, también debe especificarse el parámetro resolve, sin especificar el puerto del servidor en el nombre de host.

Si no hay puntos en el nombre del servicio,
el nombre se forma de acuerdo con el estándar RFC:
el nombre del servicio se antepone con `_`,
luego se añade `_tcp` tras un punto.
Así, 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 vía DNS,
junto con sus prioridades y pesos.

- Los registros SRV de máxima prioridad
(los que comparten el valor de prioridad mínima)
se resuelven en servidores principales,
y los demás registros se convierten en servidores de respaldo.
Si se configura `backup` con `server`,
los registros SRV de máxima prioridad se resuelven como servidores de respaldo,
y los demás registros se ignoran.
- El peso es similar al parámetro `weight` de la directiva `server`.
Si el peso está configurado tanto en la directiva como en el registro SRV,
se usa el peso definido en la directiva. | Este ejemplo buscará el registro `_http._tcp.backend.example.com`: ```nginx server backend.example.com service=http resolve; ``` | `sid=`id | Establece el ID del servidor en el grupo. Si el parámetro no se especifica,
el ID se establece como un hash MD5 hexadecimal
de la dirección IP y el puerto o de la ruta del socket de dominio UNIX. | |------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `slow_start=`tiempo | Establece el [tiempo](https://es.angie.software//angie/docs/configuration/configfile.md#syntax) que tarda un servidor en recuperar su peso
al volver a estar en servicio
con los métodos de balanceo de carga [round-robin](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream.md#round-robin) o [least_conn](#s-u-least-conn).

Si el parámetro está configurado
y un servidor vuelve a considerarse saludable
tras un fallo según [max_fails](#s-max-fails) y [upstream_probe (PRO)](https://es.angie.software//angie/docs/configuration/modules/stream/stream_upstream_probe.md#s-u-upstream-probe),
el servidor recupera gradualmente su peso designado
durante el período de tiempo especificado.

Si el parámetro no está configurado,
en una situación similar
el servidor comienza a trabajar inmediatamente con su peso designado. | |-----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| #### NOTE Si solo se especifica un `server` en el upstream, `slow_start` no tiene efecto y será ignorado. ### state (PRO) | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `state` archivo; | |--------------------------------------------------------------------------------------------|--------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Especifica el archivo donde se almacena de forma persistente la lista de servidores del upstream. Al instalar desde [nuestros paquetes](https://es.angie.software//angie/docs/installation/index.md#install-packages), se crea un directorio dedicado `/var/lib/angie/state/` (`/var/db/angie/state/` en FreeBSD) con los permisos adecuados para almacenar dichos archivos, por lo que solo es necesario añadir el nombre de archivo en la configuración: ```nginx upstream backend { zone backend 1m; state /var/lib/angie/state/; } ``` El formato de la lista de servidores aquí es similar a `s_server`. El contenido del archivo cambia siempre que los servidores se modifiquen en la sección [/config/stream/upstreams/](https://es.angie.software//angie/docs/configuration/modules/http/http_api.md#api-config-stream-upstreams-servers) mediante la API de configuración. El archivo se lee al iniciar Angie o al recargar la configuración. #### WARNING 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](#s-u-zone)). ### zone | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `zone` nombre [tamaño]; | |--------------------------------------------------------------------------------------------|---------------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Define el nombre y tamaño de la zona de memoria compartida que almacena la configuración y el estado en tiempo de ejecución del grupo, compartido entre los procesos worker. Varios grupos pueden usar la misma zona. En este caso, basta con especificar el tamaño una sola vez. #### NOTE 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. ### backup_switch (PRO) | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `backup_switch` `permanent`[=tiempo]; | |--------------------------------------------------------------------------------------------|-----------------------------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | 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 en el que previamente se encontró un servidor con éxito. Si no se puede encontrar un servidor en el grupo activo para la siguiente petición, y la búsqueda se traslada al grupo de respaldo, este grupo de respaldo se convierte en activo, y las siguientes peticiones se dirigen primero a los servidores de este grupo. Si se define el parámetro `permanent` sin un valor de [tiempo](https://es.angie.software//angie/docs/configuration/configfile.md#syntax), el grupo permanece activo tras la selección, y no se produce la re-comprobación automática de grupos con niveles de prioridad más bajos. Si se especifica tiempo, el estado activo del grupo expira tras el intervalo especificado, y el balanceador de carga vuelve a comprobar los grupos con niveles de prioridad más bajos, retornando a ellos si los servidores funcionan normalmente. Ejemplo: ```nginx upstream media_backend { server primary1.example.com:1935; server primary2.example.com:1935; server reserve1.example.com:1935 backup; server reserve2.example.com:1935 backup; backup_switch permanent=2m; } ``` Si el balanceador de carga cambia de los servidores principales al grupo de respaldo, todas las peticiones posteriores son gestionadas por este grupo de respaldo durante 2 minutos. Tras expirar los 2 minutos, el balanceador vuelve a comprobar los servidores principales y los hace activos de nuevo si funcionan con normalidad. ### feedback (PRO) | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `feedback` variable [`inverse`] [`factor=`número] [`account=`variable_condición]; | |--------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Habilita un mecanismo de balanceo de carga basado en retroalimentación para el `upstream`. Ajusta dinámicamente las decisiones de balanceo de carga multiplicando el peso de cada servidor proxy por el valor promedio de retroalimentación, que cambia con el tiempo según el valor de 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 la proporciona el servidor.

El valor se evalúa con cada respuesta del servidor
y se incorpora al promedio móvil
según la configuración de `inverse` y `factor`. | |--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `inverse` | Si se establece el parámetro, el valor de retroalimentación se interpreta de forma inversa:
valores más bajos indican mejor rendimiento. | | `factor` | El factor por el cual se pondera 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 usando la fórmula de [suavizado exponencial](https://es.wikipedia.org/wiki/Suavizado_exponencial).

Cuanto mayor sea el factor, menos afectarán los valores nuevos al promedio;
si se especifica `90`, se tomará el 90% del valor anterior
y solo el 10% del valor nuevo. | | `account` | Especifica una variable de condición
que controla cómo se contabilizan las conexiones en el cálculo.
El valor promedio se actualiza con el valor de retroalimentación
solo si la variable de condición
no es igual a `""` ni a `"0"`.

#### NOTE
Por defecto, el tráfico de las [sondas](https://es.angie.software//angie/docs/configuration/modules/stream/stream_upstream_probe.md#s-u-upstream-probe)
no se incluye en el cálculo;
combinar la variable [$upstream_probe](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream_probe.md#v-upstream-probe)
con `account` permite incluirlas
o incluso excluir todo lo demás. | Ejemplo: ```nginx upstream backend { zone backend 1m; feedback $feedback_value factor=80 account=$condition_value; server backend1.example.com:1935 weight=1; server backend2.example.com:1935 weight=2; } map $protocol $feedback_value { "TCP" 100; "UDP" 75; default 10; } map $upstream_probe $condition_value { "high_priority" "1"; "low_priority" "0"; default "1"; } ``` Esta configuración clasifica los servidores por niveles de retroalimentación basados en los protocolos usados en sesiones individuales, y además añade una condición sobre [$upstream_probe](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream_probe.md#v-upstream-probe) para contabilizar solo las sondas de `high_priority` o las sesiones de clientes normales. ### hash | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `hash` clave [`consistent`]; | |--------------------------------------------------------------------------------------------|--------------------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Especifica un método de balanceo de carga para el grupo donde la asignación cliente-servidor se determina usando un valor hash de la clave. La clave puede contener texto, variables y sus combinaciones. Tenga en cuenta que cualquier adición o eliminación de servidores 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 librería Perl [Cache::Memcached](https://metacpan.org/pod/Cache::Memcached). Ejemplo de uso: ```nginx 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 a la distribución de clientes. Para garantizar una distribución consistente, use el parámetro `consistent`. Si se especifica el parámetro `consistent`, se usará el método de hash consistente ketama en lugar del método anterior. Este método garantiza que, al añadir o eliminar un servidor del grupo, solo un número mínimo de claves se reasignará a otros servidores. Usar el método para servidores de caché proporciona una mayor tasa de aciertos de caché. El método es compatible con la librería Perl [Cache::Memcached::Fast](https://metacpan.org/pod/Cache::Memcached::Fast) con el parámetro `ketama_points` configurado en 160. ### least_conn | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `least_conn`; | |--------------------------------------------------------------------------------------------|-----------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Especifica un método de balanceo de carga para el grupo donde una conexión se pasa al servidor con el menor número de conexiones activas, teniendo en cuenta los pesos de los servidores. Si varios servidores son adecuados, se seleccionan cíclicamente (round-robin) con sus pesos tenidos en cuenta. ### least_time (PRO) | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `least_time` `connect` | `first_byte` | `last_byte` [`factor=`número] [`account=`variable_condición]; | |--------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Especifica un método de balanceo de carga para el grupo donde la probabilidad de pasar una conexión a un servidor activo es inversamente proporcional a su tiempo promedio de respuesta; cuanto menor sea, más conexiones recibirá el servidor. | `connect` | La directiva tiene en cuenta el tiempo promedio para establecer una conexión. | |--------------|----------------------------------------------------------------------------------| | `first_byte` | La directiva usa el tiempo promedio para recibir el primer byte de la respuesta. | | `last_byte` | La directiva usa el tiempo promedio para recibir la respuesta completa. | | `factor` | Realiza la misma función que [response_time_factor (PRO)](#s-u-response-time-factor),
y lo anula si se especifica el parámetro. | |------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `account` | Especifica una variable de condición
que controla qué conexiones se contabilizan en el cálculo.
El valor promedio se actualiza
solo si la variable de condición de la conexión
no es igual a `""` ni a `"0"`.

#### NOTE
Por defecto, las [sondas](https://es.angie.software//angie/docs/configuration/modules/stream/stream_upstream_probe.md#s-u-upstream-probe)
no se incluyen en el cálculo;
combinar la variable [$upstream_probe](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream_probe.md#v-upstream-probe)
con `account` permite incluirlas
o incluso excluir todo lo demás. | Los valores actuales se presentan como `connect_time`, `first_byte_time` y `last_byte_time` en el objeto `health` del servidor entre las [métricas de upstream](https://es.angie.software//angie/docs/configuration/modules/http/http_api.md#api-status-stream-upstreams) en la API. ### random | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `random` [`two`]; | |--------------------------------------------------------------------------------------------|---------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Especifica un método de balanceo de carga para el grupo donde una conexión 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 y luego elige un servidor usando el método especificado. El método predeterminado es [least_conn](#s-u-least-conn), que pasa la conexión al servidor con el menor número de conexiones activas. ### response_time_factor (PRO) | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `response_time_factor` número; | |--------------------------------------------------------------------------------------------|----------------------------------| | Predeterminado | `response_time_factor 90;` | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Especifica para el método de balanceo de carga [least_time (PRO)](#s-u-least-time) el factor de suavizado para el valor **anterior** al calcular el tiempo promedio de respuesta usando la fórmula de [media móvil ponderada exponencialmente](https://es.wikipedia.org/wiki/Media_m%C3%B3vil#Media_m%C3%B3vil_exponencial). Cuanto mayor sea el número especificado, menos afectarán los valores nuevos al promedio; si se especifica `90`, se tomará el 90% del valor anterior y solo el 10% del valor nuevo. Los valores válidos son de 0 a 99 inclusive. Los resultados actuales del cálculo se presentan como `connect_time` (tiempo para establecer una conexión), `first_byte_time` (tiempo para recibir el primer byte de la respuesta) y `last_byte_time` (tiempo para recibir la respuesta completa) en el objeto `health` del servidor entre las [métricas de upstream](https://es.angie.software//angie/docs/configuration/modules/http/http_api.md#api-status-stream-upstreams) en la API. #### NOTE Solo se consideran las respuestas exitosas en el cálculo; lo que constituye una respuesta no exitosa se determina por las directivas [proxy_next_upstream](https://es.angie.software//angie/docs/configuration/modules/stream/stream_proxy.md#s-proxy-next-upstream). ### sticky | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `sticky route` value...;

`sticky learn` `zone=`zone `create=`$create_var1... `lookup=`$lookup_var1... [`connect`] [`norefresh`] [`timeout=`time];

`sticky learn` `lookup=`$lookup_var1... `remote_action=`uri `remote_result=`$remote_var [`remote_uri=`uri]; | |--------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Configura sesiones persistentes entre clientes y servidores upstream, dependiendo del modo especificado en el primer parámetro. Para retirar gradualmente servidores con `sticky` de la rotación, puede usarse la opción `drain` (PRO) en el bloque [server](#s-u-server). #### WARNING La directiva `sticky` debe aparecer después de todas las directivas de método de balanceo de carga, de lo contrario no funcionará. Modo `route` Este modo utiliza identificadores de ruta predefinidos que pueden estar integrados en propiedades de conexión accesibles para Angie. Es menos flexible ya que depende de valores predefinidos, pero es más adecuado si dichos identificadores ya están en uso. Aquí, al establecer una conexión, el servidor upstream puede asignar una ruta al cliente y devolver su identificador de una manera conocida por ambas partes. El identificador de ruta debe usar el valor del parámetro [sid](#s-reresolve) de la directiva [server](#s-u-server). Tenga en cuenta que el parámetro se hashea adicionalmente si se especifica la directiva [sticky_secret](#s-u-sticky-secret). Las conexiones posteriores de clientes que deseen usar esta ruta deben contener el identificador emitido por el servidor, de tal manera que termine en variables de Angie. Los parámetros de la directiva especifican cadenas que pueden incluir variables para el enrutamiento. Para seleccionar el servidor al que se dirige la conexión entrante, se usa el primer valor no vacío; luego se compara con el parámetro [sid](#s-reresolve) de la directiva [server](#s-u-server). Si la selección del servidor falla o el servidor seleccionado no puede aceptar la conexión, se seleccionará otro servidor según el método de balanceo de carga configurado. Aquí Angie busca el identificador de ruta en la variable `$route`, que recibe su valor basándose en [$ssl_preread_server_name](https://es.angie.software//angie/docs/configuration/modules/stream/stream_ssl_preread.md#v-ssl-preread-server-name) (tenga en cuenta que [ssl_preread](https://es.angie.software//angie/docs/configuration/modules/stream/stream_ssl_preread.md#s-ssl-preread) debe estar habilitado): ```nginx stream { map $ssl_preread_server_name $route { a.example.com a; b.example.com b; default ""; } upstream backend { server 127.0.0.1:8081 sid=a; server 127.0.0.1:8082 sid=b; sticky route $route; } server { listen 127.0.0.1:8080; ssl_preread on; proxy_pass backend; } } ``` Modo `learn` (PRO) En este modo, se usa una clave generada dinámicamente para vincular un cliente a un servidor upstream específico; este modo es más flexible ya que asigna servidores sobre la marcha, almacena sesiones en una zona de memoria compartida, y admite varias formas de pasar identificadores de sesión. Aquí, se crea una sesión basándose en propiedades de conexión provenientes del servidor upstream. Los parámetros `create` y `lookup` listan variables que especifican cómo se crean nuevas sesiones y se encuentran las existentes. Ambos parámetros pueden usarse múltiples veces. El identificador de sesión es el valor de la primera variable no vacía especificada con `create`; por ejemplo, esto podría ser el [nombre del servidor upstream](https://es.angie.software//angie/docs/configuration/modules/http/index.md#v-server-name). Las sesiones se almacenan en una zona de memoria compartida; su nombre y tamaño se especifican mediante el parámetro `zone`. Si no se ha accedido a una sesión dentro del [tiempo](https://es.angie.software//angie/docs/configuration/configfile.md#syntax) especificado por `timeout`, se elimina. El valor predeterminado es 1 hora. Por defecto, Angie extiende el tiempo de vida de la sesión actualizando la marca de tiempo del último acceso cada vez que se usa. El parámetro `norefresh` cambia este comportamiento: la sesión expira estrictamente por tiempo de espera, incluso si se está usando. Las conexiones posteriores de clientes que deseen usar una sesión deben contener su identificador. El parámetro `lookup` busca el identificador de sesión en la conexión usando la lista especificada de variables, deteniéndose en la primera no vacía. Si no se encuentra nada, la solicitud se considera nueva. El valor del identificador encontrado se compara con las sesiones en memoria compartida. Si la selección del servidor falla o el servidor seleccionado no puede manejar la conexión, se seleccionará otro servidor según el método de balanceo de carga configurado. El parámetro `connect` permite crear una sesión inmediatamente después de establecer una conexión con el servidor upstream. Sin él, la sesión se crea solo después de que se completa el procesamiento de la conexión. (En el caso de conexiones UDP, las sesiones se crean inmediatamente después de la selección del servidor.) En el ejemplo, Angie crea y busca sesiones usando la variable [$rdp_cookie](https://es.angie.software//angie/docs/configuration/modules/stream/stream_rdp_preread.md#v-rdp-cookie): ```nginx stream { upstream backend { server 127.0.0.1:3390; server 127.0.0.1:3391; sticky learn lookup=$rdp_cookie create=$rdp_cookie zone=sessions:1m; } server { listen 127.0.0.1:3389; rdp_preread on; proxy_pass backend; } } ``` Modo `learn` con `remote_action` (PRO 1.10.0+) Los parámetros `remote_action` y `remote_result` permiten asignar y gestionar identificadores de sesión dinámicamente usando un almacén de sesiones remoto (PRO). A diferencia del modo `learn` con `zone`, este modo no almacena sesiones en caché localmente y consulta el almacén remoto para cada conexión. El parámetro `remote_action` debe apuntar a un `location` en el contexto [client](https://es.angie.software//angie/docs/configuration/modules/http/index.md#client). El parámetro `remote_uri` especifica el URI de la solicitud HTTP del cliente al `location` especificado. Por defecto, es `/`. El valor de `remote_uri` puede contener variables. El principio general de funcionamiento de este modo es el siguiente: si no se encuentra un identificador de sesión localmente, Angie envía una subpetición síncrona a un almacén remoto especificado por el parámetro `remote_action`. Cuando llega una nueva conexión, Angie realiza las siguientes acciones: - Primero, el identificador de sesión se extrae de la primera variable no vacía en la lista `lookup`. Si todas las variables están vacías, se usa el algoritmo de balanceo de carga normal sin sesiones persistentes. - Luego Angie envía una subpetición HTTP síncrona al almacén remoto especificado por el parámetro `remote_action`, que debe contener en un formato entendido por el almacén: - el identificador de *sesión* del parámetro `lookup` (en la configuración, esta es la variable [$sticky_sessid](#v-s-sticky-sessid)); - el identificador del *servidor* preseleccionado: el valor del parámetro `sid=` de la directiva `server`, si se especifica, o el hash MD5 del nombre del servidor (en la configuración, esta es la variable [$sticky_sid](#v-s-sticky-sid)). Las variables `$sticky_sessid` y `$sticky_sid` se exportan automáticamente al contexto HTTP con el prefijo `stream_`: `$stream_sticky_sessid`, `$stream_sticky_sid`. Esto permite usarlas directamente en directivas HTTP, por ejemplo mediante cabeceras HTTP usando [proxy_set_header](https://es.angie.software//angie/docs/configuration/modules/http/http_proxy.md#proxy-set-header). - El almacén remoto procesa la solicitud y devuelve una respuesta HTTP: Una respuesta con código 200, 201 o 204 confirma el servidor seleccionado. El almacén remoto puede simultáneamente devolver un identificador de servidor alternativo en una cabecera HTTP o en el cuerpo de la respuesta (PRO); puede extraerse mediante `remote_result`. Al recibir cualquier otro código HTTP del almacén (incluyendo errores de red y tiempos de espera) o un identificador de servidor inexistente, Angie usa el servidor originalmente seleccionado. El identificador del servidor se extrae de la respuesta del almacén remoto mediante el parámetro `remote_result`: puede especificar variables con el prefijo `upstream_http_`, que son creadas automáticamente por Angie para acceder a las cabeceras de respuesta HTTP del almacén remoto, o [$sent_body](https://es.angie.software//angie/docs/configuration/modules/http/index.md#v-sent-body) para usar el cuerpo de la respuesta. Por ejemplo, la cabecera `X-Sid: server1` en dicha respuesta se vuelve accesible en la variable `$upstream_http_x_sid` con el valor `server1`. A continuación se muestra un ejemplo de configuración simplificado. El almacén remoto devuelve el identificador del servidor en la cabecera `X-Sticky-Sid` y así confirma o anula la selección de Angie: ```nginx http { client { location @sticky_client1 { # usar variables del upstream de stream; # las añade al contexto HTTP con el prefijo stream_* proxy_set_header X-Sticky-Sessid $stream_sticky_sessid; proxy_set_header X-Sticky-Sid $stream_sticky_sid; proxy_set_header X-Sticky-Last $msec; proxy_pass http://127.0.0.1:8080; proxy_cache remote; proxy_cache_valid 200 1d; proxy_cache_key $scheme$proxy_host$request_uri$stream_sticky_sessid; } } } stream { upstream u { server 127.0.0.1:8081 sid=backend-01; server 127.0.0.1:8082 sid=backend-02; sticky learn lookup=$remote_addr # variable de stream remote_action=@sticky_client1 # location del bloque client remote_result=$upstream_http_x_sticky_sid # variable HTTP remote_uri=/foo; # por defecto es / } server { listen 127.0.0.1:8080; proxy_pass u; } } ``` Aquí, con la siguiente respuesta del almacén remoto: ```none HTTP/1.1 200 OK ... X-Sticky-Sid: backend-01 X-Session-Info: active ``` Dos variables quedan disponibles: - `$upstream_http_x_sticky_sid`, con el valor `backend-01`; - `$upstream_http_x_session_info`, con el valor `active`. Dado que la variable `$upstream_http_x_sticky_sid` se especifica en el parámetro `remote_result`, su valor se utilizará para seleccionar el servidor con `sid=backend-01`. La directiva `sticky` tiene en cuenta el estado de los servidores en [upstream](#s-u-upstream): - Los servidores marcados como `down` o temporalmente no disponibles debido a fallos se excluyen de la selección. - Los servidores que han alcanzado el número máximo de conexiones (al usar `max_conns`) se omiten temporalmente. - Los servidores con la opción `drain` (PRO) pueden ser seleccionados para crear nuevas sesiones en modo `sticky` cuando los identificadores coinciden. - Si un servidor previamente no disponible se recupera, `sticky` reanuda automáticamente su uso. El comportamiento de `sticky` puede configurarse adicionalmente con las directivas [sticky_secret](#s-u-sticky-secret) y [sticky_strict](#s-u-sticky-strict). Si `sticky` no logra seleccionar un servidor o este no está disponible, la solicitud se manejará según el método de balanceo de carga seleccionado, a menos que la directiva `sticky_strict` esté habilitada. En modo `sticky_strict on;`, la solicitud se rechaza con un error. Las zonas de memoria compartida especificadas en el parámetro `zone` de la directiva `sticky` no pueden compartirse entre diferentes grupos `upstream`; cada grupo debe usar su propia zona. ### sticky_secret | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `sticky_secret` cadena; | |--------------------------------------------------------------------------------------------|---------------------------| | Predeterminado | — | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Añade cadena como sal a la función hash MD5 para la directiva [sticky](#s-u-sticky) en modo `route`. Cadena puede contener variables, por ejemplo `$remote_addr`: ```nginx upstream backend { server 127.0.0.1:8081 sid=a; server 127.0.0.1:8082 sid=b; sticky route $route; sticky_secret my_secret.$remote_addr; } ``` La sal se añade después del valor hash; para verificar independientemente el mecanismo de hash: ```console $ echo -n "" | md5sum ``` ### sticky_strict | [Sintaxis](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | `sticky_strict` `on` | `off`; | |--------------------------------------------------------------------------------------------|---------------------------------| | Predeterminado | `sticky_strict off;` | | [Contexto](https://es.angie.software//angie/docs/configuration/configfile.md#configfile) | upstream | Cuando está habilitado, Angie devolverá un error de conexión al cliente si el servidor deseado no está disponible, en lugar de recurrir a otro servidor disponible, que es el comportamiento predeterminado cuando no se encuentra un servidor coincidente. ## Variables integradas El módulo `stream_upstream` admite las siguientes variables integradas: ### `$sticky_sessid` Se usa con `remote_action` en [sticky](#s-u-sticky); almacena el identificador de sesión inicial tomado de `lookup`. ### `$sticky_sid` Se usa con `remote_action` en [sticky](#s-u-sticky); almacena el identificador del servidor previamente asociado con la sesión. `sticky_sid` contiene el valor del parámetro `sid=` de la directiva `server` en el bloque [upstream](#s-u-upstream), si se especifica, o el hash MD5 del nombre del servidor. ### `$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 proxying, sus direcciones se separan por comas, por ejemplo: > 192.168.1.1:1935, 192.168.1.2:1935, unix:/tmp/sock Si no se puede seleccionar un servidor, la variable conserva el nombre del [grupo de servidores](#s-u-upstream). ### `$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](#v-s-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](#v-s-upstream-addr). ### `$upstream_connect_time` tiempo para conectarse al servidor upstream; el tiempo se mantiene en segundos con resolución de milisegundos. Los tiempos de varias conexiones se separan por comas y dos puntos como las direcciones en la variable [$upstream_addr](#v-s-upstream-addr). ### `$upstream_first_byte_time` tiempo para recibir el primer byte de datos; el tiempo se mantiene en segundos con resolución de milisegundos. Los tiempos de varias conexiones se separan por comas como las direcciones en la variable [$upstream_addr](#v-s-upstream-addr). ### `$upstream_session_time` duración de la sesión en segundos con resolución de milisegundos. Los tiempos de varias conexiones se separan por comas como las direcciones en la variable [$upstream_addr](#v-s-upstream-addr). ### `$upstream_sticky_status` Estado de las conexiones sticky. | `""` | Conexión dirigida a un grupo de servidores donde sticky no está habilitado. | |--------|----------------------------------------------------------------------------------------------------------------| | `NEW` | Conexión que no contiene información sticky. | | `HIT` | Conexión con información sticky dirigida al servidor deseado. | | `MISS` | Conexión con información sticky dirigida a un servidor
seleccionado por el algoritmo de balanceo de carga. | Los valores de múltiples conexiones se separan por comas y dos puntos, de manera similar a las direcciones en la variable [$upstream_addr](#v-s-upstream-addr).