Presentamos NGINX Plus R12

Owen GarrettDirector sénior de Gestión de Producto

[Editor: Esta entrada se ha actualizado para hacer referencia a la API de NGINX Plus, que sustituye y deja obsoletos los módulos independientes de configuración dinámica y de estado tratados en la versión original de la entrada.]

Hoy nos complace anunciar que NGINX Plus R12 está disponible como actualización gratuita para todos los suscriptores de NGINX Plus. NGINX Plus es una plataforma de software de alto rendimiento para la entrega de aplicaciones que incluye un balanceador de carga, una caché de contenido y un servidor web. NGINX Plus R12 es una versión importante que incorpora nuevas funciones centradas en la agrupación en clústeres, la personalización y la supervisión.

Para obtener más información sobre NGINX Plus R12, vea nuestro seminario web bajo demanda.

Los usuarios empresariales se beneficiarán de la nueva función de agrupación en clústeres, que simplifica la gestión de clústeres de servidores NGINX Plus de alta disponibilidad. Todos los usuarios se beneficiarán de la compatibilidad oficial con nginScript, un lenguaje de scripting ligero y de alto rendimiento integrado directamente en la configuración de NGINX. Las mejoras en la supervisión y la instrumentación, el almacenamiento en caché y las comprobaciones de estado aumentan la fiabilidad y el rendimiento de las aplicaciones.

• Uso compartido de la configuración – Un script compatible para compartir la configuración permite enviar de forma fiable la configuración desde una instancia principal de NGINX Plus a un conjunto de instancias homólogas. El proceso realiza copias de seguridad y verifica que la configuración sea válida en cada instancia homóloga remota antes de aplicarla y recargar el proceso nginx.
• Disponibilidad general del módulo JavaScript de NGINX – El módulo JavaScript de NGINX<.htmla> permite crear sofisticadas soluciones de gestión del tráfico con NGINX Plus utilizando la conocida sintaxis de JavaScript. [Anteriormente, el módulo se llamaba nginScript y en esta publicación ambos nombres se utilizan indistintamente.] El código JavaScript se puede integrar en la configuración de NGINX Plus para realizar acciones personalizadas sobre el tráfico HTTP, TCP y UDP.
• Nuevas estadísticas – La visibilidad es fundamental para mantener aplicaciones en buen estado y con un alto rendimiento. NGINX Plus R12 ofrece una mayor visibilidad del rendimiento de las aplicaciones mediante métricas adicionales, como los tiempos de respuesta de los servidores, el uso de las zonas de memoria compartida y los códigos de error de los servicios TCP/UDP. Consulte las nuevas estadísticas en el panel de control integrado de supervisión de la actividad en tiempo real o expórtelas en formato JSON a su herramienta de supervisión preferida.
• Almacenamiento en caché mejorado – Obtenga un rendimiento aún mayor de su caché. NGINX Plus R12 admite las extensiones de caché stale-while-revalidate y stale-if-error definidas en RFC 5861. La revalidación de la caché puede realizarse en segundo plano para que los usuarios no tengan que esperar a que se complete la comunicación de ida y vuelta con el servidor de origen.
• Mejoras en las comprobaciones de estado – Cuando se añaden nuevos servidores a un grupo de balanceo de carga mediante la API de NGINX Plus o DNS, NGINX Plus puede retrasar el envío de tráfico hasta que superen la comprobación de estado periódica configurada y, a continuación, aplicar la función de inicio lento para aumentar gradualmente el tráfico que reciben. Además, una nueva comprobación de estado más sencilla para UDP facilita el despliegue de servicios UDP fiables para los usuarios.

Otras mejoras incluyen la autenticación mediante certificados de cliente para servicios TCP, la posibilidad de inspeccionar campos personalizados en los JWT de OAuth, la compatibilidad con el formato WebP en el módulo Image-Filter, así como diversas mejoras de rendimiento y estabilidad.

Recomendamos a todos los suscriptores que actualicen de inmediato a NGINX Plus R12 para aprovechar las mejoras de rendimiento, funcionalidad y fiabilidad de esta versión. Antes de realizar la actualización, asegúrese de revisar los cambios de comportamiento indicados en la siguiente sección.

Cambios de comportamiento

NGINX Plus R12 introduce algunos cambios en el comportamiento predeterminado y en el funcionamiento interno de NGINX Plus que debe tener en cuenta al actualizar:

• Formato de los metadatos de la caché – El formato de la cabecera interna de metadatos de la caché ha cambiado. Al actualizar a NGINX Plus R12, la caché almacenada en disco deja de ser válida y NGINX Plus la actualiza automáticamente según sea necesario. Las entradas antiguas de la caché se eliminan automáticamente.
• Variables «DN» de SSL – El formato de las variables $ssl_client_s_dn y $ssl_client_i_dn ha cambiado. La coma ( , ) se utiliza ahora como separador de campos en lugar de la barra diagonal ( / ) y se escapa conforme a las RFC 2253 y 4514. Para seguir utilizando el formato X509_NAME_oneline con la barra diagonal como separador de campos, utilice las variables $ssl_client_s_dn_legacy y $ssl_client_i_dn_legacy.
• Cola de conexiones máximas – La directiva queue indica a NGINX Plus que ponga en cola las conexiones a los servidores ascendentes si están sobrecargados. Como consecuencia de las optimizaciones de memoria y rendimiento de R12, la directiva queue ahora debe aparecer en el bloque upstream debajo de la directiva que especifica el algoritmo de balanceo de carga (hash, ip_hash, least_conn, o least_time).
• Módulos dinámicos de terceros – Los módulos dinámicos desarrollados o certificados por NGINX, Inc. están disponibles en nuestro repositorio. Para que los módulos de terceros sigan funcionando con NGINX Plus R12, deben volver a compilarse con NGINX Open Source versión 1.11.10. Consulte la Guía de administración de NGINX Plus para obtener más información.
• Última versión para sistemas operativos que han llegado al final de su vida útil – Ubuntu ha anunciado el fin de la vida útil de Ubuntu 12.04 LTS, y Red Hat ha anunciado el fin del soporte en fase de producción para Red Hat Enterprise Linux 5.10+, ambos con efecto a partir del 31 de marzo de 2017. NGINX Plus R12 es la última versión que incluirá paquetes y soporte para estas versiones de sistemas operativos, así como para CentOS 5.10+ y Oracle Linux 5.10+. Para seguir recibiendo actualizaciones y soporte después de NGINX Plus R12, actualice a una versión compatible del sistema operativo.

Características de NGINX Plus R12 en detalle

Uso compartido de la configuración

Los servidores NGINX Plus suelen implementarse en un clúster de dos o más instancias para garantizar una alta disponibilidad y escalabilidad. Esto permite mejorar la fiabilidad de los servicios al protegerlos del impacto de los fallos de los servidores, así como ampliar horizontalmente la infraestructura para gestionar grandes volúmenes de tráfico.

NGINX Plus ya ofrece un método compatible para distribuir el tráfico entre los servidores de un clúster en modo activo-pasivo o activo-activo. NGINX Plus R12 añade otro método compatible para sincronizar la configuración en todo un clúster. Esta función de sincronización de la configuración permite a un administrador configurar un «clúster» de servidores NGINX Plus desde una única ubicación. Estos servidores comparten un subconjunto común de su configuración.

La configuración de NGINX Plus se envía desde el servidor principal a los demás servidores

Así se sincroniza la configuración:

1. Designe uno o varios nodos «principales» en el clúster.
2. Instale el nuevo paquete nginx-sync en los nodos primarios.
3. Aplique los cambios de configuración a un nodo primario.
4. Invoque el proceso de sincronización de la configuración, nginx-sync.sh, incluido en el paquete nginx-sync, para actualizar cada uno de los demás servidores del clúster (los pares). El proceso de sincronización lleva a cabo los siguientes pasos en cada par:
   1. Envía la configuración actualizada al nodo homólogo mediante ssh o rsync.
   2. Verifica que la configuración sea válida para el par y, de no ser así, la revierte.
   3. Aplica la configuración si es válida y vuelve a cargar los servidores NGINX Plus en el nodo par.

Esta funcionalidad resulta especialmente útil cuando NGINX Plus se implementa en un par de servidores tolerante a fallos (o en un número mayor de servidores). Puede utilizar este método para simplificar la implementación fiable de la configuración en un clúster o para enviar la configuración desde un servidor de preproducción a un clúster de servidores de producción.

Para obtener instrucciones detalladas, consulte la Guía de administración de NGINX Plus.

Disponibilidad general del módulo JavaScript de NGINX

Con NGINX Plus R12, nos complace anunciar que el módulo NGINX JavaScript ya está disponible de forma general como módulo estable tanto para NGINX Open Source como para NGINX Plus. [El módulo se llamaba anteriormente nginScript y en esta publicación ambos nombres se utilizan indistintamente.] nginScript cuenta con soporte completo para los suscriptores de NGINX Plus.

nginScript es una implementación única de JavaScript<.htmla> para NGINX y NGINX Plus, diseñada específicamente para casos de uso del lado del servidor y el procesamiento de cada solicitud. Permite ampliar la sintaxis de configuración de NGINX Plus con código JavaScript para implementar soluciones de configuración avanzadas.

Con nginScript puede registrar variables personalizadas mediante lógica compleja, controlar la selección de servidores upstream, implementar algoritmos de balanceo de carga, personalizar la persistencia de sesiones e incluso implementar servicios web sencillos. Durante las próximas semanas publicaremos en nuestro blog instrucciones completas para algunas de estas soluciones y añadiremos aquí los enlaces correspondientes a medida que estén disponibles.

En concreto, NGINX Plus R12 incluye las siguientes mejoras:

• Fase de lectura previa en el módulo Stream
• Métodos y constantes de Math en ECMAScript 6
• Métodos adicionales de String, como endsWith, includes, repeat, startsWith y trim
• Ámbitos

Aunque nginScript es estable, se sigue trabajando para admitir aún más casos de uso y ampliar la compatibilidad con el lenguaje JavaScript. Obtenga más información en Cómo aprovechar la potencia y la comodidad de JavaScript en cada solicitud con el módulo JavaScript de NGINX<.htmla> en nuestro blog.

Nuevas estadísticas

La monitorización y la instrumentación de NGINX Plus aportan un importante valor añadido, ya que ofrecen información detallada sobre el rendimiento y el comportamiento tanto de NGINX Plus como de las aplicaciones de origen. Las estadísticas están disponibles tanto a través de nuestro panel gráfico integrado como en formato JSON, que puede exportarse a su herramienta de monitorización preferida.

El panel de monitorización de la actividad en tiempo real se ha actualizado para NGINX Plus R12

NGINX Plus R12 incorpora varias mejoras: más información sobre el rendimiento (tiempo de respuesta) de los servidores con equilibrio de carga, datos sobre el funcionamiento de los servicios TCP y UDP, y una serie de datos internos que ayudan a identificar problemas durante su resolución y a ajustar NGINX Plus para optimizar el rendimiento.

Las nuevas estadísticas de NGINX Plus R12 incluyen:

• Tiempo de respuesta del servidor ascendente – En NGINX Plus R11 y versiones anteriores, el tiempo de respuesta de los servidores ascendentes solo se calculaba cuando se utilizaba el algoritmo de balanceo de carga Least Time. A partir de NGINX Plus R12, el tiempo de respuesta se mide para todos los algoritmos y se muestra tanto en los datos JSON como en el panel integrado.
• Códigos de respuesta de los servidores ascendentes TCP/UDP en el panel gráfico – El módulo Stream para el balanceo de carga TCP/UDP genera pseudocódigos de estado para indicar cómo se cerró una conexión (200 significa «correcto», 502 significa «servidor ascendente no disponible», etc.) y los notifica en la variable $status. NGINX Plus R12 añade una serie de columnas al panel para mostrar el número de códigos de respuesta de los servidores virtuales TCP y UDP, como las que ya existen para los servidores virtuales HTTP. Los pseudocódigos de estado también se pueden registrar para integrarlos con las herramientas de análisis de registros existentes.
• Información de la versión de NGINX Plus – Para facilitar la resolución de problemas, los datos JSON ahora indican el número de versión de NGINX Plus como nginx_build (por ejemplo, nginx-plus-r12) y el número de versión de NGINX Open Source como nginx_version (por ejemplo, 1.11.10). El panel muestra ambos valores en el recuadro superior izquierdo de la pestaña principal.
• Nombre de host del servidor ascendente – En los datos JSON, el campo server identifica un servidor de un grupo ascendente mediante su dirección IP y puerto. El nuevo campo name muestra el primer parámetro de la directiva server en el bloque de configuración upstream, que puede ser un nombre de dominio o una ruta de socket de dominio UNIX, además de una dirección IP y un puerto. En el panel, la columna Nombre situada más a la izquierda en las pestañas Servidores ascendentes y Servidores ascendentes TCP/UDP ahora muestra el valor del campo name en lugar del campo server (que se mostraba en NGINX Plus R11 y versiones anteriores). La nueva métrica facilita la correlación de los datos JSON y del panel con sus servidores ascendentes si los define mediante nombres DNS, especialmente si estos se resuelven en varias direcciones IP.
• Uso de las zonas de memoria compartida en los datos de estado ampliados – Las zonas de memoria compartida se configuran con un tamaño fijo, y puede resultar difícil elegir un tamaño que no sea ni demasiado grande (se asigna memoria, pero nunca se utiliza) ni demasiado pequeño (la memoria se agota y los elementos almacenados en caché se descartan). La nueva instrumentación de las métricas proporciona un informe interno detallado sobre el uso de memoria de cada zona compartida, lo que permite supervisar dicho uso y ayuda al soporte técnico de NGINX a ofrecer recomendaciones más fundamentadas para optimizar la configuración de NGINX.
• Escape compatible con JSON en el registro de acceso de NGINX Plus – Algunas herramientas modernas de análisis de registros pueden procesar de forma eficiente archivos de registro con formato JSON y extraer información de ellos más fácilmente que de archivos de registro sin formato. Puede definir una plantilla JSON en la directiva estándar log_format de NGINX Plus, y el nuevo parámetro opcional escape de la directiva aplica un escape compatible con JSON para que las líneas del registro tengan el formato correcto.

Para obtener más información, consulte Supervisión de la actividad en tiempo real.

Almacenamiento en caché mejorado

NGINX Plus R12 mejora significativamente el motor de almacenamiento en caché de NGINX Plus.

Servir contenido obsoleto durante la actualización

NGINX Plus R12 incorpora compatibilidad con las extensiones Cache-Control definidas en RFC 5861: stale-while-revalidate y stale-if-error. Ahora puede configurar NGINX Plus para que respete estas extensiones de Cache-Control y siga sirviendo recursos caducados desde la caché mientras los actualiza en segundo plano, sin añadir latencia a la solicitud del cliente. Del mismo modo, NGINX Plus puede servir recursos caducados desde la caché si el servidor de origen no está disponible, una técnica para implementar patrones de disyuntor en aplicaciones de microservicios.

A menos que esté configurado para ignorar la cabecera Cache-Control, NGINX Plus respeta los temporizadores de contenido stale de los servidores de origen que devuelven cabeceras Cache-Control conformes con RFC 5861, como en este ejemplo:

Cache-Control: max-age=3600 stale-while-revalidate=120 stale-if-error=900

Para habilitar la compatibilidad con las extensiones de Cache-Control con actualización en segundo plano, incluye las directivas resaltadas:

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;

        # Serve stale content when updating
        proxy_cache_use_stale updating;
        
        # In addition, don’t block the first request that triggers the update
        # and do the update in the background
        proxy_cache_background_update on;

        proxy_pass http://my_upstream;
    }
}

La directiva proxy_cache_use_stale updating indica a NGINX Plus que sirva la versión obsoleta del contenido mientras se actualiza. Si solo incluye esa directiva, el primer usuario que solicite contenido obsoleto sufrirá la penalización por «fallo de caché»; es decir, no recibirá el contenido hasta que NGINX Plus lo haya obtenido del servidor de origen y almacenado en caché. Los usuarios que soliciten posteriormente el contenido obsoleto mientras se actualiza lo recibirán inmediatamente desde la caché, mientras que el primer usuario no recibirá nada hasta que el contenido actualizado se haya obtenido y almacenado en caché.

Con la nueva directiva proxy_cache_background_update, todos los usuarios, incluido el primero, reciben el contenido obsoleto mientras NGINX Plus lo actualiza en segundo plano.

La nueva funcionalidad también está disponible en los módulos FastCGI, SCGI y uwsgi.

Solicitudes de intervalos de bytes

Otra mejora del motor de almacenamiento en caché permite que NGINX Plus omita la caché en las solicitudes de intervalos de bytes que comiencen a una distancia del inicio de un archivo no almacenado en caché superior al número de bytes configurado. Esto significa que, en el caso de archivos grandes, como el contenido de vídeo, las solicitudes de un intervalo de bytes situado en una parte avanzada del archivo no añaden latencia a la solicitud del cliente. En versiones anteriores de NGINX Plus, el cliente no recibía el intervalo de bytes solicitado hasta que NGINX Plus obtenía todo el contenido desde el inicio del archivo hasta el intervalo de bytes solicitado y lo escribía en la caché.

La nueva directiva «proxy_cache_max_range_offset» especifica el desplazamiento desde el principio del archivo a partir del cual NGINX Plus envía una solicitud de intervalo de bytes directamente al servidor de origen y no almacena en caché la respuesta. (La nueva funcionalidad también está disponible en los módulos FastCGI, SCGI y uwsgi).

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
    location / {
        proxy_cache my_cache;

        # Bypass cache for byte range requests beyond 10 megabytes
        proxy_cache_max_range_offset 10m;

        proxy_pass http://my_upstream;
    }
}

Estas mejoras consolidan aún más NGINX Plus como un motor de almacenamiento en caché de alto rendimiento y conforme con los estándares, apto para cualquier entorno, desde la aceleración de la entrega de aplicaciones hasta la creación de redes de distribución de contenidos (CDN) completas.

Comprobaciones de estado mejoradas

NGINX Plus R12 mejora aún más las capacidades de comprobación activa del estado de NGINX Plus.

Comprobación de estado de los servidores recién añadidos

Con la creciente adopción de entornos en contenedores y grupos de aplicaciones con escalado automático, es fundamental que el balanceador de carga realice comprobaciones de estado proactivas a nivel de aplicación y dé tiempo a los nuevos servidores para inicializar sus recursos internos antes de alcanzar su pleno rendimiento.

Antes de NGINX Plus R12, cuando se añadía un nuevo servidor al grupo de balanceo de carga (mediante la NGINX Plus API o DNS), NGINX Plus lo consideraba en buen estado desde el primer momento y le enviaba tráfico inmediatamente. Al incluir el nuevo parámetro mandatory en la directiva health_check (HTTP o TCP/UDP), el nuevo servidor debe superar la comprobación de estado configurada antes de que NGINX Plus le envíe tráfico. En combinación con la función slow‑start, el nuevo parámetro proporciona a los nuevos servidores aún más tiempo para conectarse a las bases de datos y «calentarse» antes de tener que gestionar la totalidad del tráfico que les corresponde.

upstream my_upstream {     zone my_upstream 64k;
     server backend1.example.com slow_start=30s;
}

server {
    location / {
        proxy_pass http://my_upstream;
  
        # Require new server to pass health check before receiving traffic
        health_check mandatory;
    }
}

Aquí se incluyen tanto el parámetro mandatory de la directiva health_check como el parámetro slow_start de la directiva server (HTTP o TCP/UDP). Los servidores que se añaden al grupo de servidores ascendentes mediante las interfaces de API o DNS se marcan como no disponibles y no reciben tráfico hasta que superan la comprobación de estado; a partir de ese momento, empiezan a recibir una cantidad de tráfico que aumenta gradualmente durante un periodo de 30 segundos.

Comprobación de estado UDP sin configuración

Es igual de importante implementar comprobaciones de estado a nivel de aplicación para los servidores UDP que para los servidores HTTP y TCP, a fin de evitar que el tráfico de producción se envíe a servidores que no sean plenamente funcionales. NGINX Plus admite comprobaciones de estado activas para UDP, pero antes de NGINX Plus R12 era necesario crear un bloque match que definiera los datos que se debían enviar y la respuesta que se debía esperar. Determinar los valores adecuados puede resultar complicado cuando se utilizan protocolos binarios o protocolos con procesos de negociación complejos. Para estas aplicaciones, NGINX Plus R12 admite ahora una comprobación de estado «sin configuración» para UDP que verifica la disponibilidad de la aplicación sin necesidad de definir cadenas de envío y respuesta esperada. Añada el parámetro udp a la directiva health_check para realizar una comprobación de estado básica de UDP.

upstream udp_app {    server backend1.example.com:1234;
    server backend2.example.com:1234;
}

server {
    listen 1234 udp;
    proxy_pass udp_app;

    # Basic UDP health check
    health_check udp;
}

Actualizaciones de SSL – Certificados de cliente para servicios TCP y variables actualizadas

Los certificados de cliente SSL se utilizan habitualmente para autenticar a los usuarios en sitios web protegidos. NGINX Plus R12 añade compatibilidad con la autenticación para servicios TCP protegidos mediante SSL a la compatibilidad existente con HTTP. Normalmente, se utiliza para la autenticación entre máquinas, en lugar del inicio de sesión de usuarios finales, y permite utilizar NGINX Plus tanto para la terminación SSL como para la autenticación de clientes al equilibrar la carga de protocolos de capa 4. Entre los ejemplos se incluye la autenticación de dispositivos IoT para la comunicación mediante el protocolo MQTT.

La variable $ssl_client_verify ahora incluye información adicional sobre los eventos de autenticación de clientes fallidos. Esto incluye motivos como certificados «revocados» y «caducados».

El formato de las variables $ssl_client_i_dn y $ssl_client_s_dn se ha modificado para cumplir con las RFC 2253 y 4514. Para obtener más información, consulte Cambios de comportamiento.

Validación de JWT mejorada

NGINX Plus R10 incorporó compatibilidad nativa con tokens web JSON (JWT) para casos de uso de OAuth 2.0 y OpenID Connect. Uno de los principales casos de uso consiste en que NGINX Plus valide un JWT, examine sus campos y los transfiera a la aplicación de backend como cabeceras HTTP. Esto permite que las aplicaciones participen fácilmente en un entorno de inicio de sesión único (SSO) de OAuth 2.0, delegando la validación del token en NGINX Plus y obteniendo la identidad del usuario mediante la lectura de las cabeceras HTTP.

NGINX Plus R10 y versiones posteriores pueden inspeccionar los campos definidos en la especificación JWT. NGINX Plus R12 amplía la compatibilidad con JWT para que se pueda acceder a cualquier campo de un JWT (incluidos los campos personalizados) como una variable de NGINX y, por tanto, se pueda reenviar mediante proxy, registrar o utilizar para tomar decisiones de autorización.

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a la versión 12 lo antes posible. Así obtendrá diversas correcciones y mejoras, y nos facilitará la tarea de ayudarle si necesita abrir una incidencia de soporte. Encontrará las instrucciones de instalación y actualización en el portal del cliente.

Consulte los cambios de comportamiento descritos anteriormente antes de proceder con la actualización.

Si aún no ha probado NGINX Plus, le animamos a utilizarlo para acelerar sitios web, equilibrar cargas y distribuir aplicaciones, o como servidor web con soporte completo y una API para mejorar la supervisión y la gestión de la configuración. Puede empezar hoy mismo de forma gratuita con una evaluación de 30 días y comprobar por sí mismo cómo NGINX Plus puede ayudarle a distribuir y escalar sus aplicaciones.

Sobre el autor

Owen GarrettDirector sénior de Gestión de Producto

Más artículos de Owen Garrett