Presentamos NGINX Plus R27

Prabhat Dixit

Nos complace anunciar la disponibilidad de NGINX Plus versión 27 (R27). Basado en NGINX Open Source, NGINX Plus es el único software todo en uno que funciona como servidor web, equilibrador de carga, proxy inverso, caché de contenido y puerta de enlace de API.

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

• Conexiones persistentes para las 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 permite utilizar conexiones persistentes para las comprobaciones de estado y establecer su duración. Establecer nuevas conexiones requiere muchos recursos computacionales, por lo que reutilizarlas puede reducir considerablemente el uso de la CPU cuando hay un gran número de servidores ascendentes.
• Compatibilidad con TLS en el kernel – NGINX Plus ahora es compatible con TLS en el kernel (kTLS) en tres sistemas operativos que cumplen los requisitos necesarios: FreeBSD 13, RHEL 9.0+ y Ubuntu 22.04 LTS.
• Métricas de TLS para servidores upstream y virtuales – NGINX Plus ahora genera estadísticas de TLS para cada servidor upstream y virtual cuando el proxy mediante HTTPS está habilitado, además de las estadísticas globales que generaba en versiones anteriores. Disponer de métricas tanto del lado del cliente como del servidor resulta útil para solucionar problemas con los protocolos de enlace TLS.
• Personalización del código de error de los fallos de validación de JWT – En NGINX Plus R25 y R26, puede definir comprobaciones personalizadas de validación de JWT, pero el código de error devuelto cuando falla una validación siempre es 401 (No autorizado). NGINX Plus R27 incorpora el parámetro error a la directiva auth_jwt_require, lo que permite establecer el código en 401 o 403 (Prohibido) para cada comprobación y distinguir mejor entre errores de autenticación y de 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 con precisión el comportamiento de la función ngx.fetch y un nuevo objeto que muestra la versión de njs como un número hexadecimal. El módulo Prometheus-njs ahora puede convertir métricas adicionales de NGINX Plus a un formato compatible con Prometheus: el campo codes (que muestra el recuento de cada código de estado HTTP de los servidores ascendentes y virtuales) y las métricas generadas por los módulos Limit Connections y Limit Requests.

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

Cambios importantes en el comportamiento

Nota: Si va a actualizar desde una versión distinta de NGINX Plus R26, asegúrese de consultar la sección Cambios importantes de comportamiento de los blogs de anuncios de todas las versiones comprendidas entre la que utiliza actualmente y esta.

Nuevos sistemas operativos compatibles:

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

Sistemas operativos y arquitecturas antiguos eliminados:

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

Sistemas operativos y arquitecturas antiguos obsoletos y cuya eliminación está prevista en NGINX Plus R28:

• Debian 10, que llegará al final de su vida útil en agosto de 2022

Nuevas funcionalidades en detalle

Conexiones persistentes para las comprobaciones de estado

Conexiones persistentes entre NGINX Plus y los servidores ascendentes mejoran considerablemente el rendimiento en casos de uso de proxy inverso y equilibrio de carga. En particular, al usar un proxy a través de HTTPS, el coste computacional del protocolo de enlace TLS completo necesario para cada nueva conexión puede sobrecargar los 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 persistentes para las comprobaciones de estado, sino que establecía una nueva conexión para cada sondeo de estado. NGINX Plus R27 incorpora conexiones persistentes para las comprobaciones de estado HTTP. El nuevo parámetro keepalive_time de la directiva health_check establece la duración de cada conexión persistente, tras la cual se establece una nueva conexión. Nuestras pruebas indican que, al usar un proxy sobre HTTPS, las conexiones persistentes reducen entre 10 y 20 veces el uso de CPU de las comprobaciones de estado en los servidores NGINX Plus. También ahorran recursos de CPU en los servidores ascendentes.

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

Cargando ejemplo de código…

Compatibilidad con TLS en el kernel

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

La combinación de kTLS y la llamada al sistema sendfile() permite cifrar los datos directamente en el espacio del kernel antes de pasarlos a la pila de red para su transmisión, en lugar de copiarlos al espacio de usuario para cifrarlos mediante bibliotecas TLS y volver a copiarlos después al espacio del kernel antes de transmitirlos. kTLS también permite descargar el procesamiento de TLS en el hardware, incluido el procesamiento criptográfico simétrico de TLS en dispositivos de red.

Hay tres requisitos para admitir kTLS:

1. El núcleo del sistema operativo es compatible con kTLS
2. La distribución del sistema operativo incluye la biblioteca criptográfica OpenSSL 3.0 o posterior, compilada con compatibilidad con kTLS
3. NGINX Plus (o NGINX Open Source) está compilado con la biblioteca criptográfica OpenSSL 3.0+

En octubre de 2021 añadimos compatibilidad con kTLS en NGINX Open Source 1.21.4 en las plataformas que cumplen los requisitos 1 y 2. Ahora añadimos compatibilidad con kTLS en NGINX Plus en estas plataformas:

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

Métricas de TLS para servidores upstream y virtuales

Cuando NGINX Plus se implementa como proxy inverso o equilibrador 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 de cada servidor ascendente y virtual, lo que permite a los clientes observar y supervisar el rendimiento y la disponibilidad de los servidores.

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 los servidores ascendentes, tanto en los contextos http como stream (establecidas mediante las directivas proxy_pass https://path-to-upstream y proxy_ssl on, respectivamente). Las estadísticas abarcan los protocolos de enlace, los fallos y las reutilizaciones de sesiones (según la configuración de la directiva proxy_ssl_session_reuse).

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

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

Cargando ejemplo de código…

Esta salida indica que el primer servidor upstream participó en cuatro negociaciones TLS y reutilizó dos sesiones (para mayor brevedad, mostramos una salida parcial del primer servidor y omitimos la de los demás servidores upstream):

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq{
  "peers": [
    {
      "id": 0,
      "server": "127.0.0.1:8081",
      "name": "127.0.0.1:8081",
      "backup": false,
      "weight": 1,
      "state": "up",
      "active": 0,
      "ssl": { "handshakes": 4, "handshakes_failed": 0, "session_reuses": 2 },
      "requests": 4,
      "header_time": 4,
      "response_time": 4,
      ...
    }
    ...
  ]
}

Este resultado 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{
  "processing": 0,
  "requests": 7,
  "responses": {
    "1xx": 0,
    "2xx": 7,
    "3xx": 0,
    "4xx": 0,
    "5xx": 0,
    "codes": {
      "200": 7
    },
    "total": 7
  },
  "discarded": 0,
  "received": 546,
  "sent": 1134,
  "ssl": { "handshakes": 7, "handshakes_failed": 0, "session_reuses": 0 }
  ...
}

Tenga en cuenta que la API de NGINX Plus sigue recopilando las métricas globales de TLS disponibles en versiones anteriores de NGINX Plus:

$ curl http://127.0.0.1:8000/api/8/ssl | jq{
  "handshakes": 21,
  "handshakes_failed": 0,
  "session_reuses": 6
}

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

NGINX Plus R25 incorporó<.htmla> la directiva auth_jwt_require para definir comprobaciones personalizadas durante el proceso de validación de JWT. En NGINX Plus R25 y R26, el código de error devuelto cuando falla la validación es siempre 401 (No autorizado).

NGINX Plus R27 incorpora el parámetro «error» a la directiva «auth_jwt_require», que permite establecer el código en 401 o 403 (Prohibido) de forma independiente para cada directiva. Cuando se deniega la solicitud de acceso de un usuario, la elección de los códigos permite indicar la diferencia entre un error de autenticación (el JWT no es válido) y un error de autorización (falta la declaración requerida). 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 redirigir la solicitud a una ubicación interna con nombre para su posterior procesamiento.

El código de estado predeterminado sigue siendo 401 cuando fallan los siguientes tipos de comprobaciones de JWT:

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

Si hay varias directivas auth_jwt_require en un bloque location, 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 devuelve 403 si $req1 o $req2 se evalúan como un valor vacío o como 0 (cero).

Cargando ejemplo de código…

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

NGINX Plus R27 incorpora las versiones 0.7.3 y 0.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 en NGINX Plus R24, introdujo la función ngx.fetch (también denominada API Fetch) para crear una instancia de un cliente HTTP sencillo desde el contexto de una conexión TCP/UDP. (Para obtener información sobre los casos de uso de esta función, consulte Uso de servicios HTTP para TCP.htmlUDP con un cliente HTTP sencillo en nuestro blog).

NGINX Plus R27 incorpora las siguientes directivas para ajustar con precisión el comportamiento de la API Fetch:

• js_fetch_buffer_size[HTTP][Flujo] – Establece el tamaño del búfer utilizado para la lectura y la escritura.
• 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 la lectura y la escritura entre dos operaciones sucesivas de lectura o escritura (no para la respuesta completa). Si no se transmite ningún dato durante el periodo de espera, se cierra la conexión.
• js_fetch_verify[HTTP][Stream] – Activa o desactiva la verificación del certificado del servidor HTTPS.

Número de versión indicado como número hexadecimal

El nuevo objeto njs.version_number indica la versión del módulo njs como un número hexadecimal. (El objeto existente njs.version 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 endpoints adicionales:

• /http/limit_conns
• /http/limit_reqs
• El campo codes (que informa del número de códigos de estado HTTP individuales<.htmla>) en /http/server_zones y /http/upstreams
• /stream/limit_conns

Otras mejoras de NGINX Plus R27

Cambio de versión de la API de NGINX Plus

El número de versión de la API de NGINX Plus se actualiza de 7 a 8 para reflejar la incorporación del campo «ssl» a las métricas notificadas para los servidores ascendentes y virtuales, tal como se describe en Métricas de TLS para servidores ascendentes y virtuales. Los números de versión anteriores siguen funcionando, pero la salida no incluye las métricas añadidas en versiones posteriores de la API.

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

NGINX Plus R27 distribuye las conexiones de forma 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 solo notifica al proceso que fue el primero en añadir el socket de escucha a la instancia de EPOLL. Como resultado, el primer proceso de trabajo gestiona la mayoría de las conexiones. Ahora, NGINX vuelve a añadir periódicamente el socket para que otros procesos de trabajo tengan la oportunidad de aceptar conexiones.

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R27 lo antes posible. También obtendrá varias correcciones y mejoras adicionales, y facilitará que NGINX pueda ayudarle cuando necesite abrir una incidencia de soporte.

Si aún no ha probado NGINX Plus, le animamos a hacerlo, ya sea para la seguridad, el equilibrio de carga y la puerta de enlace de API, o como servidor web con soporte completo y API avanzadas de supervisión y gestión. Puede empezar hoy mismo con una prueba gratuita de 30 días.

Sobre el autor

Prabhat Dixit

Más artículos de Prabhat Dixit