BLOG | NGINX

Cómo evitar los 10 errores de configuración principales de NGINX

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Miniatura de Timo Stark
Timo Stark
Publicado el 22 de febrero de 2022

Cuando ayudamos a los usuarios de NGINX que tienen problemas, a menudo vemos los mismos errores de configuración que hemos visto una y otra vez en las configuraciones de otros usuarios, ¡a veces incluso en configuraciones escritas por otros ingenieros de NGINX! En este blog analizamos 10 de los errores más comunes, explicando qué está mal y cómo solucionarlo.

  1. No hay suficientes descriptores de archivos por trabajador
  2. La directiva error_log off
  3. No habilitar conexiones keepalive a servidores ascendentes
  4. Olvidando cómo funciona la herencia directiva
  5. La directiva proxy_buffering off
  6. Uso incorrecto de la directiva if
  7. Controles de salud excesivos
  8. Acceso no seguro a las métricas
  9. Uso de ip_hash cuando todo el tráfico proviene del mismo bloque CIDR /24
  10. No aprovechar los grupos ascendentes

Error 1: No hay suficientes descriptores de archivos por trabajador

La directiva workers_connections establece el número máximo de conexiones simultáneas que un proceso de trabajo NGINX puede tener abiertas (el valor predeterminado es 512). Todos los tipos de conexiones (por ejemplo, conexiones con servidores proxy) cuentan para el máximo, no solo las conexiones de cliente. Pero es importante tener en cuenta que, en última instancia, existe otro límite en la cantidad de conexiones simultáneas por trabajador: el límite del sistema operativo en la cantidad máxima de descriptores de archivos (FD) asignados a cada proceso. En las distribuciones UNIX modernas, el límite predeterminado es 1024.

Para todas las implementaciones de NGINX, excepto las más pequeñas, un límite de 512 conexiones por trabajador probablemente sea demasiado pequeño. De hecho, el archivo nginx.conf predeterminado que distribuimos con los binarios de código abierto NGINX y NGINX Plus lo aumenta a 1024.

El error de configuración común es no aumentar el límite de FD al menos al doble del valor de workers_connections . La solución es establecer ese valor con la directiva workers_rlimit_nofile en el contexto de configuración principal.

Esta es la razón por la que se necesitan más archivos de destino (FD): cada conexión de un proceso de trabajo de NGINX a un cliente o servidor ascendente consume un FD. Cuando NGINX actúa como servidor web, utiliza un FD para la conexión del cliente y un FD por archivo servido, con un mínimo de dos FD por cliente (aunque la mayoría de las páginas web se crean a partir de muchos archivos). Cuando actúa como servidor proxy, NGINX utiliza un FD para la conexión con el cliente y el servidor ascendente, y potencialmente un tercer FD para el archivo utilizado para almacenar temporalmente la respuesta del servidor. Como servidor de almacenamiento en caché, NGINX se comporta como un servidor web para respuestas almacenadas en caché y como un servidor proxy si el caché está vacío o ha expirado.

NGINX también utiliza un FD por archivo de registro y un par de FD para comunicarse con el proceso maestro, pero generalmente estos números son pequeños en comparación con la cantidad de FD utilizados para conexiones y archivos.

UNIX ofrece varias formas de establecer la cantidad de FD por proceso:

  • El comando ulimit si inicia NGINX desde un shell
  • Las variables del manifiesto del servicio systemd o del script de inicio si inicia NGINX como un servicio
  • El archivo /etc/security/limits.conf

Sin embargo, el método a utilizar depende de cómo inicie NGINX, mientras queworker_rlimit_nofile funciona sin importar cómo inicie NGINX.

También hay un límite en todo el sistema en la cantidad de FD, que se puede configurar con el comando sysctl fs.file-max del sistema operativo. Generalmente es lo suficientemente grande, pero vale la pena verificar que la cantidad máxima de descriptores de archivos que todos los procesos de trabajo de NGINX pueden usar ( worker_rlimit_nofile * worker_processes ) sea significativamente menor que fs.file‑max . Si NGINX de alguna manera utiliza todos los FD disponibles (por ejemplo, durante un ataque DoS), resulta imposible incluso iniciar sesión en la máquina para solucionar el problema.

Error 2: La directiva error_log off

El error común es pensar que la directiva error_log off deshabilita el registro. De hecho, a diferencia de la directiva access_log , error_log no toma un parámetro off . Si incluye la directiva error_log off en la configuración, NGINX crea un archivo de registro de errores llamado off en el directorio predeterminado para los archivos de configuración de NGINX (normalmente /etc/nginx ).

No recomendamos deshabilitar el registro de errores, ya que es una fuente vital de información al depurar cualquier problema con NGINX. Sin embargo, si el almacenamiento es tan limitado que podría ser posible registrar suficientes datos como para agotar el espacio disponible en disco, podría ser conveniente deshabilitar el registro de errores. Incluya esta directiva en el contexto de configuración principal:

registro de errores /dev/null emerg;

Tenga en cuenta que esta directiva no se aplica hasta que NGINX lea y valide la configuración. Por lo tanto, cada vez que se inicia NGINX o se recarga la configuración, es posible que se registre en la ubicación de registro de errores predeterminada (generalmente /var/log/nginx/error.log ) hasta que se valide la configuración. Para cambiar el directorio de registro, incluya el parámetro -e < error_log_location > en el comando nginx .

Error 3: No habilitar conexiones Keepalive a servidores ascendentes

De forma predeterminada, NGINX abre una nueva conexión a un servidor ascendente (backend) para cada nueva solicitud entrante. Esto es seguro pero ineficiente, porque NGINX y el servidor deben intercambiar tres paquetes para establecer una conexión y tres o cuatro para terminarla.

Cuando hay un gran volumen de tráfico, abrir una nueva conexión para cada solicitud puede agotar los recursos del sistema y hacer que sea imposible abrir conexiones. Esta es la razón: para cada conexión, la tupla de 4 de dirección de origen, puerto de origen, dirección de destino y puerto de destino debe ser única. Para las conexiones desde NGINX a un servidor ascendente, tres de los elementos (el primero, el tercero y el cuarto) son fijos, dejando solo el puerto de origen como variable. Cuando se cierra una conexión, el socket de Linux permanece en el estado TIME-WAIT durante dos minutos, lo que en casos de alto volumen de tráfico aumenta la posibilidad de agotar el grupo de puertos de origen disponibles. Si eso sucede, NGINX no puede abrir nuevas conexiones a los servidores ascendentes.

La solución es habilitar conexiones keepalive entre NGINX y los servidores ascendentes: en lugar de cerrarse cuando se completa una solicitud, la conexión permanece abierta para usarse para solicitudes adicionales. Esto reduce la posibilidad de quedarse sin puertos de origen y mejora el rendimiento .

Para habilitar conexiones keepalive:

  • Incluya la directiva keepalive en cada bloque upstream{} para establecer la cantidad de conexiones keepalive inactivas a servidores upstream conservadas en el caché de cada proceso de trabajo.

    Tenga en cuenta que la directiva keepalive no limita la cantidad total de conexiones a servidores ascendentes que un proceso de trabajo NGINX puede abrir; este es un concepto erróneo común. Por lo tanto, el parámetro para mantener activo no necesita ser tan grande como podría pensarse.

    Recomendamos configurar el parámetro al doble del número de servidores enumerados en el bloque upstream{} . Esto es lo suficientemente grande para que NGINX mantenga conexiones activas con todos los servidores, pero lo suficientemente pequeño para que los servidores ascendentes también puedan procesar nuevas conexiones entrantes.

    Tenga en cuenta también que cuando especifica un algoritmo de equilibrio de carga en el bloque upstream{} (con la directiva hash , ip_hash , less_conn , less_time o random ), la directiva debe aparecer encima de la directiva keepalive . Esta es una de las raras excepciones a la regla general de que el orden de las directivas en la configuración de NGINX no importa.

  • En el bloque location{} que reenvía solicitudes a un grupo ascendente, incluya las siguientes directivas junto con la directiva proxy_pass :

    proxy_http_version 1.1;
proxy_set_header "Conexión" "";

    De forma predeterminada, NGINX utiliza HTTP/1.0 para las conexiones a servidores ascendentes y, en consecuencia, agrega el encabezado Connection: close a las solicitudes que reenvía a los servidores. El resultado es que cada conexión se cierra cuando se completa la solicitud, a pesar de la presencia de la directiva keepalive en el bloque upstream{} .

    La directiva proxy_http_version le indica a NGINX que utilice HTTP/1.1 en su lugar, y la directiva proxy_set_header elimina el valor de cierre del encabezado de conexión .

Error 4: Olvidando cómo funciona la herencia directiva

Las directivas NGINX se heredan hacia abajo, o “de afuera hacia adentro”: un contexto secundario (uno anidado dentro de otro contexto (su padre )) hereda las configuraciones de las directivas incluidas en el nivel padre. Por ejemplo, todos los bloques server{} y location{} en el contexto http{} heredan el valor de las directivas incluidas en el nivel http , y una directiva en un bloque server{} es heredada por todos los bloques location{} secundarios en él. Sin embargo, cuando se incluye la misma directiva tanto en un contexto principal como en su contexto secundario, los valores no se suman, sino que el valor en el contexto secundario anula el valor principal.

El error es olvidar esta “regla de anulación” para las directivas de matriz , que pueden incluirse no solo en múltiples contextos sino también varias veces dentro de un contexto determinado. Los ejemplos incluyen proxy_set_header y add_header : tener “add” en el nombre del segundo hace que sea particularmente fácil olvidarse de la regla de anulación.

Podemos ilustrar cómo funciona la herencia con este ejemplo para add_header :

http { 
add_header X-HTTP-NIVEL-ENCABEZADO 1;
add_header X-OTRO-HTTP-NIVEL-ENCABEZADO 1;

servidor {
list 8080;
ubicación / {
devuelve 200 "OK";
} 
}

servidor {
list 8081;
add_header X-SERVIDOR-NIVEL-ENCABEZADO 1;
ubicación / {
devuelve 200 "OK";
}

ubicación /prueba {
add_header X-UBICACIÓN-NIVEL-ENCABEZADO 1;
devuelve 200 "OK";
}

ubicación /correcto {
add_header X-HTTP-NIVEL-ENCABEZADO 1;
add_header X-OTRO-HTTP-NIVEL-ENCABEZADO 1;

add_header X-SERVIDOR-NIVEL-ENCABEZADO 1;
add_header ENCABEZADO DE NIVEL DE UBICACIÓN X 1;
devuelve 200 "OK";
} 
}
}

Para el servidor que escucha en el puerto 8080, no hay directivas add_header en los bloques server{} o location{} . Entonces la herencia es sencilla y vemos los dos encabezados definidos en el contexto http{} :

% curl -i localhost:8080 HTTP/1.1 200 OK Servidor: nginx/1.21.5 Fecha: Lun, 21 Feb 2022 10:12:15 GMT Tipo de contenido: texto sin formato Longitud del contenido: 2 Conexión: mantener activa X-HTTP-LEVEL-HEADER: 1 X OTRO ENCABEZADO DE NIVEL HTTP: 1 OK

Para el servidor que escucha en el puerto 8081, hay una directiva add_header en el bloque server{} pero no en su ubicación / bloque secundario. El encabezado definido en el bloque server{} anula los dos encabezados definidos en el contexto http{} :

% curl -i localhost:8081 HTTP/1.1 200 OK Servidor: nginx/1.21.5 Fecha: Lun, 21 Feb 2022 10:12:20 GMT Tipo de contenido: texto sin formato Longitud del contenido: 2 Conexión: mantener activa X-SERVER-LEVEL-HEADER: 1 OK

En el bloque de ubicación secundaria /prueba , hay una directiva add_header y anula tanto el encabezado de su bloque principal server{} como los dos encabezados del contexto http{} :

% curl -i localhost:8081/test HTTP/1.1 200 OK Servidor: nginx/1.21.5 Fecha: Lun, 21 Feb 2022 10:12:25 GMT Tipo de contenido: texto sin formato Longitud del contenido: 2 Conexión: mantener activa X-UBICACIÓN-NIVEL-ENCABEZADO: 1 OK

Si queremos que un bloque location{} preserve los encabezados definidos en sus contextos principales junto con cualquier encabezado definido localmente, debemos redefinir los encabezados principales dentro del bloque location{} . Esto es lo que hemos hecho en el bloque de ubicación /corrección :

% curl -i localhost:8081/correct HTTP/1.1 200 OK Servidor: nginx/1.21.5 Fecha: Lun, 21 Feb 2022 10:12:30 GMT Tipo de contenido: texto sin formato Longitud del contenido: 2 Conexión: mantener activa X-HTTP-LEVEL-HEADER: 1 X OTRO ENCABEZADO DE NIVEL HTTP: 1 ENCABEZADO DE NIVEL DE SERVIDOR X: 1 X-UBICACIÓN-NIVEL-ENCABEZADO: 1 OK

Error 5: La directiva proxy_buffering off

El almacenamiento en búfer de proxy está habilitado de manera predeterminada en NGINX (la directiva proxy_buffering está establecida en on ). El almacenamiento en búfer de proxy significa que NGINX almacena la respuesta de un servidor en búferes internos a medida que llega y no comienza a enviar datos al cliente hasta que se almacena en búfer toda la respuesta. El almacenamiento en búfer ayuda a optimizar el rendimiento con clientes lentos: debido a que NGINX almacena en búfer la respuesta durante el tiempo que le toma al cliente recuperarla por completo, el servidor proxy puede devolver su respuesta lo más rápido posible y volver a estar disponible para atender otras solicitudes.

Cuando el almacenamiento en búfer del proxy está deshabilitado, NGINX almacena en búfer solo la primera parte de la respuesta de un servidor antes de comenzar a enviarla al cliente, en un búfer que, de manera predeterminada, tiene el tamaño de una página de memoria (4 KB u 8 KB, según el sistema operativo). Generalmente, este espacio es suficiente para el encabezado de respuesta. Luego, NGINX envía la respuesta al cliente de manera sincrónica a medida que la recibe, lo que obliga al servidor a permanecer inactivo mientras espera hasta que NGINX pueda aceptar el siguiente segmento de respuesta.

Por eso nos sorprende la frecuencia con la que vemos que proxy_buffering está desactivado en las configuraciones. Quizás se pretende reducir la latencia que experimentan los clientes, pero el efecto es insignificante mientras que los efectos secundarios son numerosos: con el buffering de proxy deshabilitado, la limitación de velocidad y el almacenamiento en caché no funcionan incluso si están configurados, el rendimiento se resiente, etc.

Solo hay una pequeña cantidad de casos de uso en los que deshabilitar el almacenamiento en búfer de proxy podría tener sentido (como el sondeo largo), por lo que desaconsejamos enfáticamente cambiar el valor predeterminado. Para obtener más información, consulte la Guía de administración de NGINX Plus .

Error 6: Uso indebido de la directiva if

La directiva if es complicada de utilizar, especialmente en bloques location{} . A menudo no hace lo que se espera e incluso puede provocar errores de segmentación. De hecho, es tan complicado que hay un artículo titulado If is Evil en el Wiki de NGINX, y lo dirigimos allí para obtener una discusión detallada de los problemas y cómo evitarlos.

En general, las únicas directivas que siempre puedes usar de forma segura dentro de un bloque if{} son return y rewrite . El siguiente ejemplo utiliza if para detectar solicitudes que incluyen el encabezado X-Test (pero puede ser cualquier condición que desee probar). NGINX devuelve el430 ( Error de campos de encabezado de solicitud demasiado grandes) , lo intercepta en la ubicación indicada @error_430 y envía la solicitud al grupo ascendente llamado b .

ubicación / { 
error_page 430 = @error_430;
if ($http_x_test) {
devolver 430; 
}

contraseña_proxy http://a;
}

ubicación @error_430 {
contraseña_proxy b;
}

Para este y muchos otros usos de if , a menudo es posible evitar la directiva por completo. En el siguiente ejemplo, cuando la solicitud incluye el encabezado X‑Test, el bloque map{} establece la variable $upstream_name en b y la solicitud se envía al grupo ascendente con ese nombre.

mapa $http_x_test $nombre_de_flujo_arriba { 
predeterminado "b";
"" "a";
}

# ...

ubicación / {
contraseña_de_proxy http://$nombre_de_flujo_arriba;
}

Error 7: Controles de salud excesivos

Es bastante común configurar múltiples servidores virtuales para enviar solicitudes al mismo grupo ascendente (en otras palabras, incluir la misma directiva proxy_pass en múltiples bloques server{} ). El error en esta situación es incluir una directiva health_check en cada bloque server{} . Esto simplemente crea más carga en los servidores ascendentes sin proporcionar ninguna información adicional.

Corriendo el riesgo de ser obvio, la solución es definir solo una comprobación de estado por cada bloque upstream{} . Aquí definimos la comprobación del estado del grupo ascendente denominado b en una ubicación con nombre especial, completa con tiempos de espera y configuraciones de encabezado adecuados.

ubicación / { 
encabezado_proxy_set Host $host;
encabezado_proxy_set "Conexión" "";
versión_http_proxy 1.1;
contraseña_proxy http://b;
}

ubicación @health_check {
health_check;
tiempo_de_espera_conexión_proxy 2s;
tiempo_de_espera_lectura_proxy 3s;
encabezado_proxy_set Host ejemplo.com;
contraseña_proxy http://b;
}

En configuraciones complejas, puede simplificar aún más la administración agrupar todas las ubicaciones de verificación de estado en un solo servidor virtual junto con la API y el panel de control de NGINX Plus , como en este ejemplo.

servidor { 
escuchar 8080;

ubicación / {
# …
}

ubicación @health_check_b {
health_check;
tiempo de espera de conexión de proxy 2 s;
tiempo de espera de lectura de proxy 3 s;
encabezado_de_proxy_configurado Host ejemplo.com;
contraseña_de_proxy http://b;
}

ubicación @health_check_c {
health_check;
tiempo de espera de conexión de proxy 2 s;
tiempo de espera de lectura de proxy 3 s;
encabezado_de_proxy_configurado Host api.ejemplo.com;
contraseña_de_proxy http://c;
}

ubicación /api {
api write=on;
# directivas que limitan el acceso a la API (ver "Error 8" a continuación)
}

ubicación = /dashboard.html {
root /usr/share/nginx/html;
}
}

Para obtener más información sobre las comprobaciones del estado de los servidores HTTP, TCP, UDP y gRPC, consulte la Guía de administración de NGINX Plus .

Error 8: Acceso no seguro a las métricas

Las métricas básicas sobre el funcionamiento de NGINX están disponibles en el módulo Estado del stub . Para NGINX Plus, también puede recopilar un conjunto mucho más amplio de métricas con la API de NGINX Plus . Habilite la recopilación de métricas incluyendo la directiva stub_status o api , respectivamente, en un bloque server{} o location{} , que se convierte en la URL a la que accede para ver las métricas. (Para la API de NGINX Plus , también debe configurar zonas de memoria compartida para las entidades NGINX (servidores virtuales, grupos ascendentes, cachés, etc.) para las que desea recopilar métricas; consulte las instrucciones en la Guía de administración de NGINX Plus ).

Algunas de las métricas son información confidencial que puede usarse para atacar su sitio web o las aplicaciones proxy de NGINX, y el error que a veces vemos en las configuraciones de usuario es no restringir el acceso a la URL correspondiente. Aquí analizamos algunas de las formas en las que puedes proteger las métricas. Usaremos stub_status en los primeros ejemplos.

Con la siguiente configuración, cualquier persona en Internet puede acceder a las métricas en http://example.com/basic_status .

servidor { 
escuchar 80;
nombre_del_servidor ejemplo.com;

ubicación = /estado_básico {
estado_de_stub;
}
}

Proteja las métricas con la autenticación básica HTTP

Para proteger con contraseña las métricas con autenticación básica HTTP , incluya las directivas auth_basic y auth_basic_user_file . El archivo (aquí, .htpasswd ) enumera los nombres de usuario y las contraseñas de los clientes que pueden iniciar sesión para ver las métricas:

servidor { 
escuchar 80;
nombre_del_servidor ejemplo.com;

ubicación = /estado_básico {
auth_basic “sitio cerrado”;
auth_basic_usuario_archivo conf.d/.htpasswd;
estado_de_stub;
}
}

Proteja las métricas con las directivas permitir y denegar

Si no desea que los usuarios autorizados tengan que iniciar sesión y conoce las direcciones IP desde las que accederán a las métricas, otra opción es la directiva allow . Puede especificar direcciones IPv4 e IPv6 individuales y rangos CIDR. La directiva denegar todo impide el acceso desde cualquier otra dirección.

servidor { 
escuchar 80;
nombre_servidor ejemplo.com;

ubicación = /estado_básico {
permitir 192.168.1.0/24;
permitir 10.1.1.0/16;
permitir 2001:0db8::/32;
permitir 96.1.2.23/32;
denegar todo;
estado_stub;
}
}

Combine los dos métodos

¿Qué pasa si queremos combinar ambos métodos? Podemos permitir que los clientes accedan a las métricas desde direcciones específicas sin una contraseña y aún así requerir el inicio de sesión para clientes que provienen de diferentes direcciones. Para esto utilizamos la directiva satisfy any . Le indica a NGINX que permita el acceso a los clientes que inician sesión con credenciales de autenticación básica HTTP o usan una dirección IP previamente aprobada. Para mayor seguridad, puedes configurar "Satisfacer a todos " para que requiera que incluso las personas que provienen de direcciones específicas inicien sesión.

servidor { 
escuchar 80;
nombre_servidor monitor.example.com;

ubicación = /estado_básico {
satisfacer cualquier;

auth_basic “sitio cerrado”;
auth_basic_user_file conf.d/.htpasswd;
permitir 192.168.1.0/24;
permitir 10.1.1.0/16;
permitir 2001:0db8::/32;
permitir 96.1.2.23/32;
denegar todo;
estado_stub;
}
}

Con NGINX Plus, utiliza las mismas técnicas para limitar el acceso al punto final de la API de NGINX Plus ( http://monitor.example.com:8080/api/ en el siguiente ejemplo), así como al panel de monitoreo de actividad en vivo en http://monitor.example.com/dashboard.html .

Esta configuración permite el acceso sin contraseña sólo a clientes que provienen de la red 96.1.2.23/32 o localhost. Dado que las directivas se definen en el nivel del servidor{} , las mismas restricciones se aplican tanto a la API como al panel de control. Como nota al margen, el parámetro write=on de la API significa que estos clientes también pueden usar la API para realizar cambios de configuración.

Para obtener más información sobre cómo configurar la API y el panel de control, consulte la Guía de administración de NGINX Plus .

servidor { 
escuchar 8080;
nombre_servidor monitor.ejemplo.com;

satisfacer cualquier;
auth_basic “sitio cerrado”;
auth_basic_user_file conf.d/.htpasswd;
permitir 127.0.0.1/32;
permitir 96.1.2.23/32;
denegar todo;

ubicación = /api/ { 
api write=on;
}

ubicación = /dashboard.html {
root /usr/share/nginx/html;
}
}

Error 9: Uso de ip_hash cuando todo el tráfico proviene del mismo bloque CIDR /24

El algoritmo ip_hash equilibra la carga del tráfico entre los servidores en un bloque upstream{} , basándose en un hash de la dirección IP del cliente. La clave hash son los primeros tres octetos de una dirección IPv4 o de toda la dirección IPv6. El método establece la persistencia de la sesión, lo que significa que las solicitudes de un cliente siempre se pasan al mismo servidor, excepto cuando el servidor no está disponible.

Supongamos que hemos implementado NGINX como proxy inverso en una red privada virtual configurada para alta disponibilidad. Colocamos varios firewalls, enrutadores, balanceadores de carga de capa 4 y puertas de enlace frente a NGINX para aceptar tráfico de diferentes fuentes (la red interna, las redes de socios, Internet, etc.) y pasarlo a NGINX para realizar un proxy inverso a los servidores ascendentes. Aquí está la configuración inicial de NGINX:

http {
upstream {
ip_hash;
servidor 10.10.20.105:8080;
servidor 10.10.20.106:8080;
servidor 10.10.20.108:8080;
}

servidor {# …}
}

Pero resulta que hay un problema: todos los dispositivos “interceptores” están en la misma red 10.10.0.0/24, por lo que para NGINX parece que todo el tráfico proviene de direcciones en ese rango CIDR. Recuerde que el algoritmo ip_hash codifica los primeros tres octetos de una dirección IPv4. En nuestra implementación, los primeros tres octetos son los mismos (10.10.0) para cada cliente, por lo que el hash es el mismo para todos ellos y no hay base para distribuir el tráfico a diferentes servidores.

La solución es utilizar el algoritmo hash con la variable $binary_remote_addr como clave hash. Esa variable captura la dirección completa del cliente, convirtiéndola en una representación binaria de 4 bytes para una dirección IPv4 y 16 bytes para una dirección IPv6. Ahora el hash es diferente para cada dispositivo interceptor y el equilibrio de carga funciona como se esperaba.

También incluimos el parámetro consistente para utilizar el método hash ketama en lugar del predeterminado. Esto reduce en gran medida la cantidad de claves que se reasignan a un servidor ascendente diferente cuando cambia el conjunto de servidores, lo que produce una mayor tasa de aciertos de caché para los servidores de almacenamiento en caché.

http { 
upstream {
hash $binary_remote_addr consistente;
servidor 10.10.20.105:8080;
servidor 10.10.20.106:8080;
servidor 10.10.20.108:8080;
}

servidor {# …}
}

Error 10: No aprovechar los grupos ascendentes

Supongamos que está utilizando NGINX para uno de los casos de uso más simples, como proxy inverso para una única aplicação de backend basada en NodeJS que escucha en el puerto 3000. Una configuración común podría verse así:

http {
servidor {
escuchar 80;
nombre_del_servidor ejemplo.com;

ubicación / {
encabezado_del_conjunto_proxy Host $host;
contraseña_del_proxy http://localhost:3000/;
}
}
}

Sencillo, ¿verdad? La directiva proxy_pass le dice a NGINX dónde enviar las solicitudes de los clientes. Todo lo que NGINX necesita hacer es resolver el nombre de host a una dirección IPv4 o IPv6. Una vez establecida la conexión, NGINX reenvía las solicitudes a ese servidor.

El error aquí es asumir que debido a que solo hay un servidor (y, por lo tanto, no hay motivo para configurar el equilibrio de carga), no tiene sentido crear un bloque upstream{} . De hecho, un bloque upstream{} desbloquea varias funciones que mejoran el rendimiento, como lo ilustra esta configuración:

http {
upstream node_backend {
zona upstreams 64K;
servidor 127.0.0.1:3000 máx. fallos=1 tiempo de espera de fallo=2s;
mantener activo 2;
}

servidor {
escuchar 80;
nombre_servidor ejemplo.com;

ubicación / {
encabezado_de_proxy Host $host;
contraseña_proxy http://node_backend/;
proxy_next_upstream tiempo de espera de error http_500;

}
}
}

La directiva de zona establece una zona de memoria compartida donde todos los procesos de trabajo de NGINX en el host pueden acceder a la información de configuración y estado de los servidores ascendentes. Varios grupos aguas arriba pueden compartir la zona. Con NGINX Plus, la zona también permite usar la API de NGINX Plus para cambiar los servidores de un grupo ascendente y la configuración de servidores individuales sin reiniciar NGINX. Para más información, consulte la Guía de administración de NGINX Plus .

La directiva del servidor tiene varios parámetros que puedes usar para ajustar el comportamiento del servidor. En este ejemplo, hemos cambiado las condiciones que utiliza NGINX para determinar que un servidor no está en buen estado y, por lo tanto, no es elegible para aceptar solicitudes. Aquí se considera que un servidor no está en buen estado si un intento de comunicación falla incluso una vez dentro de cada período de 2 segundos (en lugar del valor predeterminado de una vez en un período de 10 segundos ).

Combinamos esta configuración con la directiva proxy_next_upstream para configurar lo que NGINX considera un intento de comunicación fallido, en cuyo caso pasa las solicitudes al siguiente servidor en el grupo ascendente. A las condiciones de error y tiempo de espera predeterminadas agregamos http_500 para que NGINX considere un HTTP 500(Error interno del servidor ) código de un servidor ascendente para representar un intento fallido.

La directiva keepalive establece la cantidad de conexiones keepalive inactivas a servidores ascendentes conservadas en el caché de cada proceso de trabajo. Ya comentamos los beneficios del Error 3: No habilitar conexiones Keepalive a servidores ascendentes .

Con NGINX Plus puedes configurar funciones adicionales con grupos ascendentes:

  • Mencionamos anteriormente que NGINX Open Source resuelve los nombres de host del servidor en direcciones IP solo una vez, durante el inicio. El parámetro de resolución de la directiva del servidor permite a NGINX Plus monitorear los cambios en las direcciones IP que corresponden al nombre de dominio de un servidor ascendente y modificar automáticamente la configuración ascendente sin la necesidad de reiniciar.

    El parámetro de servicio también permite que NGINX Plus utilice registros DNS SRV , que incluyen información sobre números de puerto, pesos y prioridades. Esto es fundamental en entornos de microservicios donde los números de puerto de los servicios a menudo se asignan de forma dinámica.

    Para obtener más información sobre cómo resolver direcciones de servidor, consulte Uso de DNS para el descubrimiento de servicios con NGINX y NGINX Plus en nuestro blog.

  • El parámetro slow_start de la directiva del servidor permite que NGINX Plus aumente gradualmente el volumen de solicitudes que envía a un servidor que recientemente se considera saludable y disponible para aceptar solicitudes. Esto evita una inundación repentina de solicitudes que podría saturar el servidor y provocar que falle nuevamente.

  • La directiva de cola permite a NGINX Plus colocar solicitudes en una cola cuando no es posible seleccionar un servidor ascendente para atender la solicitud, en lugar de devolver un error al cliente inmediatamente.

Recursos

Para probar NGINX Plus, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .

Leer más publicaciones de blog sobre F5 NGINX ›

"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.