Cachés compartidas con clústeres de caché de NGINX Plus, parte 1

Owen GarrettDirector sénior de Gestión de Producto

Nota del editor: Esta es la primera parte de una serie sobre almacenamiento en caché de alta capacidad y alta disponibilidad:

• Cachés compartidas con clústeres de caché de NGINX Plus, parte 1 (esta publicación)
• Cachés compartidas con clústeres de caché de NGINX Plus, parte 2

Esta entrada se ha actualizado para hacer referencia a la API de NGINX Plus, que sustituye y deja obsoleto el módulo independiente de estado ampliado que se trataba originalmente aquí.

¿Cómo se puede crear un clúster de caché de gran capacidad y alta disponibilidad con NGINX o NGINX Plus? Esta es la primera entrega de una serie de dos partes en la que se presentan enfoques alternativos para alcanzar este objetivo. Puede acceder a la segunda parte mediante el enlace anterior. (Salvo que se indique lo contrario, los enfoques se aplican por igual a NGINX Open Source y NGINX Plus, pero, para abreviar, nos referiremos únicamente a NGINX Plus).

Descripción general del almacenamiento en caché de NGINX Plus

NGINX Plus puede funcionar como servidor de caché proxy, situado entre el servidor de origen y los clientes remotos. NGINX Plus gestiona el tráfico dirigido al servidor de origen y almacena en caché recursos comunes que no cambian. Esto permite que NGINX Plus responda directamente a los clientes cuando solicitan estos recursos, reduciendo así la carga del servidor de origen. La caché proxy de NGINX Plus suele implementarse en un centro de datos próximo al servidor de origen, aunque también puede desplegarse de forma similar a una CDN en puntos de presencia (PoP) distribuidos por todo el mundo.

El almacenamiento en caché de contenido es un tema sorprendentemente complejo. Conviene familiarizarse con algunas técnicas básicas de almacenamiento en caché antes de continuar con este artículo:

• El funcionamiento del almacenamiento en caché de NGINX Plus – Configuración básica y función de los procesos de carga y gestión de la caché
• Ajuste preciso de los tiempos de caché – Implementación de prácticas como el microalmacenamiento en caché para controlar cómo se almacena el contenido en caché y cómo se actualiza cuando caduca

¿Por qué NGINX Plus no utiliza un disco compartido para el almacenamiento en caché?

Cada servidor NGINX Plus funciona como un servidor de caché web independiente. No existe ningún medio técnico para compartir una caché basada en disco entre varios servidores NGINX Plus; se trata de una decisión de diseño deliberada.

Almacenar una caché en un sistema de archivos compartido de alta latencia y potencialmente poco fiable no es una buena decisión de diseño. NGINX Plus es sensible a la latencia del disco y, aunque la funcionalidad de grupos de subprocesos descarga del subproceso principal las operaciones read() y write(), si el sistema de archivos es lento y la E/S de la caché es elevada, NGINX Plus puede verse desbordado por un gran volumen de subprocesos. Mantener una caché compartida y coherente entre las instancias de NGINX Plus también requeriría bloqueos en todo el clúster para sincronizar operaciones de caché simultáneas, como el llenado, la lectura y la eliminación. Por último, los sistemas de archivos compartidos introducen una fuente de falta de fiabilidad y rendimiento impredecible en la caché, donde la fiabilidad y un rendimiento constante son primordiales.

¿Por qué compartir una caché entre varios servidores NGINX Plus?

Aunque compartir un sistema de archivos no es un buen enfoque para el almacenamiento en caché, sigue habiendo buenas razones para almacenar contenido en caché en varios servidores NGINX Plus, cada una con su técnica correspondiente:

• Si su objetivo principal es crear una caché de muy alta capacidad, fragmente (particione) la caché entre varios servidores. En este artículo explicaremos esta técnica.
• Si su objetivo principal es lograr una alta disponibilidad y, al mismo tiempo, minimizar la carga de los servidores de origen, utilice una caché compartida de alta disponibilidad. Para obtener más información sobre esta técnica, consulte el artículo complementario (próximamente).

Fragmentación de la caché

La fragmentación de una caché es el proceso de distribuir las entradas de caché entre varios servidores de caché web. La fragmentación de caché de NGINX Plus utiliza un algoritmo de hash coherente para seleccionar un único servidor de caché para cada entrada. Las figuras muestran qué sucede con una caché fragmentada entre tres servidores (figura de la izquierda) cuando uno de ellos deja de funcionar (figura central) o se añade otro servidor (figura de la derecha).

La capacidad total de la caché es la suma de la capacidad de caché de cada servidor. Se minimizan las solicitudes al servidor de origen porque solo un servidor intenta almacenar en caché cada recurso (no hay varias copias independientes del mismo recurso).

Este patrón es tolerante a fallos en el sentido de que, si tiene N servidores de caché y uno falla, solo pierde 1/N de la caché. Esta «parte perdida» se distribuye uniformemente mediante el hash consistente entre los N –1 servidores restantes. En cambio, los métodos de hash más sencillos redistribuyen toda la caché entre los servidores restantes, por lo que se pierde casi toda la caché durante la redistribución.

Cuando utilice el equilibrio de carga mediante hash coherente, use la clave de caché (o un subconjunto de los campos utilizados para crearla) como clave del hash coherente:

upstream cache_servers {    hash $scheme$proxy_host$request_uri consistent;

    server red.cache.example.com;
    server green.cache.example.com;
    server blue.cache.example.com;
}

Puede distribuir el tráfico entrante entre los servidores de la capa de balanceadores de carga (LB) mediante la solución de alta disponibilidad activo-pasivo de NGINX Plus, DNS de turno rotatorio o una solución de alta disponibilidad como keepalived.

Optimización de la configuración de la caché fragmentada

Puede elegir una de las dos optimizaciones disponibles para la configuración de particionamiento de la caché.

Combinación de los niveles de balanceo de carga y caché

Puede combinar los niveles de balanceo de carga y caché. En esta configuración, se ejecutan dos servidores virtuales en cada instancia de NGINX Plus. El servidor virtual de balanceo de carga («LB VS» en la figura) acepta solicitudes de clientes externos y utiliza un hash coherente para distribuirlas entre todas las instancias de NGINX Plus del clúster, que están conectadas mediante una red interna. El servidor virtual de caché («Cache VS») de cada instancia de NGINX Plus escucha en su dirección IP interna las solicitudes que le corresponden, las reenvía al servidor de origen y almacena en caché las respuestas. Esto permite que todas las instancias de NGINX Plus actúen como servidores de caché, lo que maximiza la capacidad de la caché.

Configuración de una caché «caliente» de primer nivel

Como alternativa, puede configurar una caché de primer nivel en la capa de balanceo de carga del frontend para el contenido con una demanda muy alta y utilizar la caché compartida de gran tamaño como caché de segundo nivel. Esto puede mejorar el rendimiento y reducir el impacto en el servidor de origen si falla una capa de caché de segundo nivel, ya que el contenido solo tendrá que actualizarse a medida que caduque gradualmente el contenido de la caché de primer nivel.

Si el clúster de caché gestiona un volumen muy elevado de contenido muy solicitado, es posible que la tasa de renovación de la caché de primer nivel, de menor tamaño, sea muy alta. En otras palabras, la demanda del espacio limitado de la caché es tan elevada que el contenido se expulsa de ella (para dejar espacio al contenido solicitado más recientemente) antes de que pueda utilizarse para atender siquiera una solicitud posterior.

Un indicador de esta situación es una proporción baja entre el contenido servido y el contenido escrito, dos métricas incluidas en las estadísticas ampliadas que proporciona el módulo de API de NGINX Plus. Aparecen en los campos Servido y Escrito de la pestaña Cachés del panel de supervisión de la actividad en tiempo real integrado. (Tenga en cuenta que el módulo de API de NGINX Plus y el panel de supervisión de la actividad en tiempo real no están disponibles en NGINX Open Source.)

Esta captura de pantalla muestra una situación en la que NGINX Plus escribe más contenido en la caché del que sirve desde ella:

En este caso, puede ajustar la caché para almacenar únicamente el contenido solicitado con mayor frecuencia. La directiva «proxy_cache_min_uses» puede ayudarle a identificar este contenido.

Resumen

Distribuir una caché entre varios servidores de caché web NGINX o NGINX Plus es una forma eficaz de crear una caché escalable y de muy alta capacidad. El hash coherente proporciona un buen nivel de alta disponibilidad, ya que garantiza que, si una caché falla, solo se invalide la parte del contenido almacenado en caché que le corresponde.

La segunda parte de esta publicación describe un patrón alternativo de caché compartida que replica la caché en un par de servidores de caché NGINX o NGINX Plus. La capacidad total está limitada a la capacidad de un servidor individual, pero la configuración es totalmente tolerante a fallos y no se pierde ningún contenido almacenado en caché si uno de los servidores de caché deja de estar disponible.

Pruebe la fragmentación de la caché en sus propios servidores: inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Owen GarrettDirector sénior de Gestión de Producto

Más artículos de Owen Garrett