Anunciamos NGINX Plus R27

Nos complace anunciar la disponibilidad de NGINX Plus Release 27 (R27) . Basado en NGINX de código abierto, NGINX Plus es el único servidor web de software todo en uno , balanceador de carga, proxy inverso, caché de contenido y puerta de enlace API.

Las características nuevas y mejoradas de NGINX Plus R27 incluyen:

• Conexiones Keepalive para comprobaciones de estado : en versiones anteriores, NGINX Plus establecía una nueva conexión para cada comprobación de estado. El nuevo parámetro keepalive_time de la directiva HTTP health_check habilita conexiones keepalive para controles de estado y establece su duración. Establecer nuevas conexiones es computacionalmente costoso, por lo que reutilizar conexiones puede reducir considerablemente el uso de CPU cuando hay un gran número de servidores ascendentes.
• Compatibilidad con Kernel TLS : NGINX Plus ahora admite Kernel TLS (kTLS) en tres sistemas operativos que cumplen los requisitos para admitirlo: FreeBSD 13, RHEL 9.0+ y Ubuntu 22.04 LTS .
• Métricas TLS para servidores ascendentes y virtuales : NGINX Plus ahora genera estadísticas TLS para servidores ascendentes y virtuales individuales cuando se habilita el proxy sobre HTTPS, además de las estadísticas globales que generaba en versiones anteriores. Disponer de métricas tanto del lado del cliente como del lado del servidor resulta útil a la hora de solucionar problemas con los protocolos de enlace TLS.
• Personalización del código de error de las fallas de validación de JWT : en NGINX Plus R25 y R26 , puede definir verificaciones de validación de JWT personalizadas, pero el código de error devuelto para una falla de validación siempre es 401(No autorizado) . NGINX Plus R27 introduce el parámetro de error en la directiva auth_jwt_require , lo que le permite configurar el código para401 o 403(Prohibido) para cada verificación para distinguir mejor entre errores de autenticación y autorización.
• Mejoras en los módulos NGINX JavaScript y Prometheus-njs : las mejoras en el módulo NGINX JavaScript incluyen nuevas directivas para ajustar el comportamiento de la función ngx.fetch y un nuevo objeto que informa la versión njs como un número hexadecimal. El módulo Prometheus-njs ahora puede convertir métricas NGINX Plus adicionales a un formato compatible con Prometheus: el campo de códigos (que informa los recuentos de códigos de estado HTTP individuales para servidores ascendentes y virtuales) y métricas generadas por los módulos Limitar conexiones y Limitar solicitudes.

Para completar el lanzamiento se incluye un nuevo número de versión (8) para la API NGINX Plus y una distribución más uniforme de las conexiones cuando se utiliza el modo EPOLLEXCLUSIVE en los kernels de Linux.

Cambios importantes en el comportamiento

Nota:  Si está actualizando desde una versión distinta a NGINX Plus R26 , asegúrese de consultar la sección Cambios importantes en el comportamiento en los blogs de anuncios de todas las versiones entre su versión actual y esta.

Nuevos sistemas operativos compatibles:

• Alpine Linux 3.16
• RHEL 9.0+ (agregado a NGINX Plus R26 después del lanzamiento inicial)
• Ubuntu 22.04 LTS (agregado a NGINX Plus R26 después del lanzamiento inicial)

Se eliminaron sistemas operativos y arquitecturas más antiguas:

• Alpine 3.12, que llegó al final de su vida útil (EOL) el 1 de mayo de 2022
• CentOS 8.1+, que alcanzó el fin de su vida útil el 31 de diciembre de 2021 (RHEL 8.1+ aún recibe soporte porque su fecha de fin de vida útil es diferente)
• Arquitectura Power 8 (ppc64le; afecta a CentOS y RHEL)

Sistemas operativos y arquitecturas más antiguos obsoletos y programados para su eliminación en NGINX Plus R28:

• Debian 10, que alcanzará el fin de su vida útil en agosto de 2022

Nuevas funciones en detalle

Conexiones Keepalive para comprobaciones de salud

Las conexiones Keepalive entre NGINX Plus y los servidores ascendentes mejoran significativamente el rendimiento para casos de uso de equilibrio de carga y proxy inverso. En el caso particular del proxy sobre HTTPS, el gasto computacional del protocolo de enlace TLS completo requerido para cada nueva conexión puede generar tensión en sus recursos informáticos, especialmente en entornos de producción con un gran número de servidores ascendentes.

En versiones anteriores, NGINX Plus no utilizaba conexiones keepalive para los controles de estado, sino que establecía una nueva conexión para cada sonda de estado. NGINX Plus R27 introduce conexiones keepalive para comprobaciones del estado de HTTP. El nuevo parámetro keepalive_time de la directiva health_check establece el tiempo de vida de cada conexión keepalive, después de lo cual se establece una nueva conexión. Nuestras pruebas indican que, para el proxy sobre HTTPS, las conexiones keepalive reducen el uso de CPU para controles de estado en un factor de 10 a 20 en los servidores NGINX Plus. También ahorran recursos de CPU en servidores ascendentes.

El siguiente ejemplo habilita conexiones keepalive con una duración de 60 segundos. Teniendo en cuenta la frecuencia de comprobación de estado de 1 segundo establecida por el parámetro de intervalo , NGINX Plus incurre en el gasto del protocolo de enlace TLS y el establecimiento de la conexión solo una vez cada 60 comprobaciones de estado.

Compatibilidad con Kernel TLS

Transport Layer Security (TLS) es el protocolo estándar de facto para el cifrado de datos en Internet. Desafortunadamente, proteger los datos también agrega latencia. La implementación de TLS en el kernel (kTLS) mejora el rendimiento al servir contenido estático al reducir significativamente la necesidad de operaciones de copia entre el espacio del usuario y el kernel.

La combinación de kTLS y la llamada al sistema sendfile() significa que los datos se cifran directamente en el espacio del kernel antes de pasarlos a la pila de red para su transmisión, en lugar de copiarse al espacio del usuario para su cifrado mediante bibliotecas TLS y luego copiarse nuevamente al espacio del kernel antes de la transmisión. kTLS también permite la descarga del procesamiento de TLS al hardware, incluida la descarga del procesamiento de cifrado simétrico de TLS a los dispositivos de red.

Hay tres requisitos para admitir kTLS:

1. El kernel del sistema operativo lo admite.
2. La distribución del sistema operativo incluye la biblioteca de cifrado OpenSSL 3.0+ compilada con soporte kTLS
3. NGINX Plus (o NGINX Open Source) está construido con la biblioteca de cifrado OpenSSL 3.0+

En octubre de 2021 agregamos soporte para kTLS a NGINX Open Source 1.21.4 en plataformas que cumplen con los requisitos 1 y 2. Ahora estamos agregando soporte para kTLS en NGINX Plus en estas plataformas:

• FreeBSD 13 (en NGINX Plus R26 y posteriores)
• RHEL 9.0+
• Ubuntu 22.04 LTS

Métricas TLS para servidores virtuales y ascendentes

Cuando NGINX Plus se implementa como un proxy inverso o un balanceador de carga, la API de NGINX Plus proporciona un amplio conjunto de métricas sobre el tráfico, los códigos de respuesta y la latencia para cada servidor virtual, lo que permite a los clientes observar y monitorear el rendimiento y la disponibilidad del servidor.

En versiones anteriores, NGINX Plus generaba métricas sobre la actividad y los errores de TLS a nivel de todo el sistema cuando se utilizaban conexiones HTTPS entre NGINX Plus y servidores ascendentes, tanto en contextos http como de flujo (establecidos con las directivas proxy_pass https: //path-to-upstream y proxy_ssl on respectivamente). Las estadísticas cubren protocolos de enlace, fallas y reutilizaciones de sesiones (según lo configurado con la directiva proxy_ssl_session_reuse ).

NGINX Plus R27 genera esas métricas TLS para servidores ascendentes individuales cuya configuración incluye la directiva zone y para servidores virtuales cuya configuración incluye la directiva status_zone . Disponer de métricas tanto del lado del cliente como del lado del servidor resulta útil a la hora de solucionar problemas con los protocolos de enlace TLS.

El siguiente ejemplo habilita la recopilación de estadísticas en el servidor ascendente upstream1 y el servidor virtual que redirige el tráfico hacia él.

Este resultado indica que el primer servidor ascendente participó en cuatro protocolos de enlace TLS y dos sesiones reutilizadas (para abreviar, mostramos un resultado parcial para el primer servidor y omitimos el resultado para los otros servidores ascendentes):

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq { "pares": [ { "id": 0, "servidor": "127.0.0.1:8081", "nombre": "127.0.0.1:8081", "copia de seguridad": falso, "peso": 1, "estado": "arriba", "activo": 0, "ssl": { "apretones de manos": 4, "el protocolo de enlace falló": 0, "reutilizaciones de sesión": 2 } , "solicitudes": 4, "tiempo_de_encabezado": 4, "tiempo_de_respuesta": 4, ... } ... ] }

Esta salida indica que NGINX Plus participó en siete protocolos de enlace TLS:

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq { "procesando": 0, "solicitudes": 7, "respuestas": { "1xx": 0, "2xx": 7, "3xx": 0, "4xx": 0, "5xx": 0, "códigos": { "200": 7 }, "total": 7 }, "descartado": 0, "recibido": 546, "enviado": 1134, "ssl": { "apretones de manos": 7, "el protocolo de enlace falló": 0, "reutilizaciones de sesión": 0 } ... }

Tenga en cuenta que la API de NGINX Plus aún recopila las métricas TLS globales disponibles en versiones anteriores de NGINX Plus:

$ curl http://127.0.0.1:8000/api/8/ssl | jq { "apretones de manos": 21, "el protocolo de enlace falló": 0, "reutilizaciones de sesión": 6 }

Personalización del código de error para fallas de validación de JWT

NGINX Plus R25 introdujo la directiva auth_jwt_require para definir verificaciones personalizadas durante el proceso de validación de JWT. En NGINX Plus R25 y R26 , el código de error devuelto por una falla de validación siempre es 401(No autorizado) .

NGINX Plus R27 introduce el parámetro de error en la directiva auth_jwt_require , que puede usar para configurar el código en401 o403 (Prohibido) para cada directiva de forma independiente. Cuando falla la solicitud de acceso de un usuario, la elección de códigos le permite transmitir la distinción entre una falla de autenticación (JWT no es válido) y una falla de autorización (falta el reclamo requerido). También puede crear controladores personalizados para los códigos de error, por ejemplo, para devolver una página especial que explique el error (con la directiva error_page ) o para redirigir la solicitud a una ubicación interna determinada para su posterior procesamiento.

El código de estado predeterminado permanece401 por fallas en los siguientes tipos de comprobaciones JWT:

• Las comprobaciones (no personalizadas) que siempre se realizan
• Comprobaciones personalizadas configuradas con auth_jwt_require pero no con el parámetro de error

Si hay varias directivas auth_jwt_require en un bloque de ubicación , se evalúan en el orden en que aparecen. El procesamiento se detiene en el primer fallo y se devuelve el código de error especificado.

En este ejemplo, la directiva auth_jwt_require devuelve403 si $req1 o $req2 se evalúan como un valor vacío o0 (cero).

Mejoras en los módulos NGINX JavaScript y Prometheus-njs

NGINX Plus R27 incorpora versiones0.7.3 y0.7.4 del módulo JavaScript de NGINX e incluye las siguientes mejoras.

Directivas adicionales para la API Fetch de njs

NGINX Javascript 0.5.3, incorporado a NGINX Plus R24 , introdujo la función ngx.fetch (también conocida como Fetch API) para crear una instancia de un cliente HTTP simple desde el contexto de una conexión TCP/UDP. (Para obtener una discusión sobre los casos de uso de la función, consulte Aprovechar los servicios HTTP para TCP.htmlUDP con un cliente HTTP simple en nuestro blog).

NGINX Plus R27 presenta las siguientes directivas para ajustar el comportamiento de la API Fetch:

• js_fetch_buffer_size [ HTTP ][ Stream ] – Establece el tamaño del búfer utilizado para leer y escribir.
• js_fetch_max_response_buffer_size [ HTTP ][ Stream ] – Establece el tamaño máximo de la respuesta recibida con la API Fetch.
• js_fetch_timeout [ HTTP ][ Stream ] – Define el tiempo de espera para lectura y escritura entre dos operaciones de lectura o escritura sucesivas (no para toda la respuesta). Si no se transmiten datos dentro del período de tiempo de espera, la conexión se cierra.
• js_fetch_verify [ HTTP ][ Stream ] – Habilita o deshabilita la verificación del certificado del servidor HTTPS.

Número de versión informado como un número hexadecimal

El nuevo objeto njs.version_number informa la versión del módulo njs como un número hexadecimal. (El objeto njs.version existente devuelve la versión como una cadena de caracteres).

El módulo Prometheus-njs convierte métricas adicionales

El módulo Prometheus-njs , que convierte las métricas de NGINX Plus a un formato compatible con Prometheus, ahora puede convertir las métricas expuestas en estos puntos finales adicionales:

• /http/limit_conns
• /http/limit_reqs
• El campo de códigos (que informa los recuentos de códigos de estado HTTP individuales<.htmla>) en /http/server_zones y /http/upstreams
• /stream/limit_conns

Otras mejoras en NGINX Plus R27

Cambio de versión de la API de NGINX Plus

El número de versión de la API NGINX Plus se actualiza de 7 a 8 para reflejar la adición del campo ssl a las métricas informadas para servidores ascendentes y virtuales como se describe en Métricas TLS para servidores ascendentes y virtuales . Los números de versiones anteriores aún funcionan, pero la salida no incluye las métricas agregadas en versiones de API posteriores.

Mejor distribución de conexiones en el modo EPOLLEXCLUSIVE de Linux

NGINX Plus R27 distribuye las conexiones de manera más uniforme entre los procesos de trabajo de NGINX cuando se utiliza el modo EPOLLEXCLUSIVE en los kernels de Linux. Normalmente, en este modo el kernel notifica solo al proceso que fue el primero en agregar el socket de escucha a la instancia EPOLL. Como resultado, la mayoría de las conexiones son manejadas por el primer proceso de trabajo. NGINX ahora vuelve a agregar el socket periódicamente para darles a otros procesos de trabajo la oportunidad de aceptar conexiones.

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R27 lo antes posible. También recibirás varias correcciones y mejoras adicionales, y ayudará a NGINX a ayudarte cuando necesites generar un ticket de soporte.

Si aún no ha probado NGINX Plus, le recomendamos que lo haga por cuestiones de seguridad, equilibrio de carga y puerta de enlace de API, o como servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy con una prueba gratuita de 30 días .