Cachés compartidos con clústeres de caché NGINX Plus (parte 1)

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

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

Esta publicación se ha actualizado para hacer referencia a la API NGINX Plus, que reemplaza y deja obsoleto el módulo de estado extendido separado que se analizó originalmente aquí.

¿Cómo se puede crear un clúster de caché de gran capacidad y alta disponibilidad utilizando NGINX o NGINX Plus? Esta es la primera de una serie de dos partes que presentan un enfoque alternativo para alcanzar este objetivo. Puedes acceder a la segunda parte a través del enlace de arriba. (Salvo que se indique lo contrario, los enfoques se aplican igualmente a NGINX Open Source y NGINX Plus, pero para abreviar nos referiremos solo a NGINX Plus).

Una descripción general del almacenamiento en caché de NGINX Plus

NGINX Plus puede funcionar como un servidor de caché proxy, ubicado entre el servidor de origen y los clientes remotos. NGINX Plus administra el tráfico al servidor de origen y almacena en caché recursos comunes e inmutables. Esto permite que NGINX Plus responda directamente a los clientes cuando se solicitan estos recursos y, por lo tanto, reduce la carga en el servidor de origen. La caché proxy de NGINX Plus se implementa más comúnmente en un centro de datos junto al servidor de origen, y también puede implementarse de manera similar a una CDN en PoP distribuidos globalmente.

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

• La mecánica del almacenamiento en caché de NGINX Plus : configuración del núcleo y la función de los procesos de cargador y administrador de caché
• Ajuste preciso de los tiempos de caché : implementación de prácticas como el microcaching 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 actúa como un servidor de caché web independiente. No existen medios técnicos para compartir un caché basado en disco entre múltiples servidores NGINX Plus; esta es una decisión de diseño deliberada.

Almacenar un caché en un sistema de archivos compartido de alta latencia y potencialmente poco confiable no es una buena opción de diseño. NGINX Plus es sensible a la latencia del disco, y aunque la capacidad de los grupos de subprocesos descarga las operaciones de lectura() y escritura() del subproceso principal, cuando el sistema de archivos es lento y la E/S de caché es alta, NGINX Plus puede verse abrumado por grandes volúmenes de subprocesos. Mantener un caché compartido y consistente en todas las instancias de NGINX Plus también requeriría bloqueos en todo el clúster para sincronizar operaciones de caché superpuestas, como rellenos, lecturas y eliminaciones. Por último, los sistemas de archivos compartidos introducen una fuente de falta de confiabilidad y rendimiento impredecible para el almacenamiento en caché, donde la confiabilidad y el 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é, aún existen buenas razones para almacenar en caché contenido en varios servidores NGINX Plus, cada uno con una técnica correspondiente:

• Si su objetivo principal es crear un caché de muy alta capacidad, divida su caché en varios servidores. Cubriremos esta técnica en este post.
• Si su objetivo principal es lograr una alta disponibilidad y minimizar la carga en los servidores de origen, utilice un caché compartido de alta disponibilidad. Para esta técnica, consulte la publicación complementaria (próximamente).

Fragmentación de su caché

La fragmentación de una caché es el proceso de distribuir entradas de caché entre múltiples servidores de caché web. La fragmentación de caché de NGINX Plus utiliza un algoritmo hash consistente para seleccionar un servidor de caché para cada entrada de caché. Las figuras muestran lo que sucede con un caché dividido en tres servidores (figura de la izquierda) cuando un servidor deja de funcionar (figura del medio) o se agrega otro servidor (figura de la derecha).

La capacidad total de caché es la suma de la capacidad de caché de cada servidor. Minimiza los viajes al servidor de origen porque solo un servidor intenta almacenar en caché cada recurso (no tienes 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, perderá solo 1/ N de su caché. Esta "porción perdida" se distribuye de manera uniforme mediante el hash consistente entre los N –1 servidores restantes. En cambio, los métodos de hash más simples redistribuyen todo el caché entre los servidores restantes y se pierde casi todo el caché durante la redistribución.

Cuando realice un equilibrio de carga de hash consistente , utilice la clave de caché (o un subconjunto de los campos utilizados para construir la clave) como clave para el hash consistente:

servidores_caché_de_subida { hash $esquema$host_proxy$uri_de_solicitud consistente;

servidor_rojo.caché.ejemplo.com;
servidor_verde.caché.ejemplo.com;
servidor_azul.caché.ejemplo.com;
}

Puede distribuir el tráfico entrante a través del nivel de Load Balancer (LB) utilizando la solución de alta disponibilidad activa-pasiva en NGINX Plus , DNS round-robin o una solución de alta disponibilidad como keepalived .

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

Puede elegir cualquiera de dos optimizaciones para su configuración de fragmentación de caché.

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

Puede combinar los niveles LB y Caché. En esta configuración, dos servidores virtuales se ejecutan en cada instancia de NGINX Plus. El servidor virtual de equilibrio de carga (“LB VS” en la figura) acepta solicitudes de clientes externos y utiliza un hash consistente para distribuirlas entre todas las instancias NGINX Plus del clúster, que están conectadas por una red interna. El servidor virtual de almacenamiento en caché (“Cache VS”) en cada instancia de NGINX Plus escucha en su dirección IP interna su parte de solicitudes, 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 almacenamiento en caché, maximizando su capacidad de caché.

Configuración de una caché activa de primer nivel

Como alternativa, puede configurar un caché de primer nivel en el nivel LB del frontend para contenido muy activo, utilizando el caché compartido grande como un caché de segundo nivel. Esto puede mejorar el rendimiento y reducir el impacto en el servidor de origen si falla un nivel de caché de segundo nivel, porque el contenido solo necesita actualizarse a medida que el contenido de caché de primer nivel expira gradualmente.

Si su clúster de caché maneja un volumen muy grande de contenido activo, es posible que descubra que la tasa de rotación en el caché de primer nivel más pequeño es muy alta. En otras palabras, la demanda de espacio limitado en la memoria caché es tan alta que el contenido se expulsa de la memoria caché (para dejar lugar para el contenido solicitado más recientemente) antes de que pueda usarse para satisfacer incluso una solicitud posterior.

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

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

En este caso, puedes ajustar tu caché para almacenar solo el contenido solicitado con más frecuencia. La directiva proxy_cache_min_uses puede ayudar a identificar este contenido.

resumen

Fragmentar un caché entre varios servidores de caché web NGINX o NGINX Plus es una forma eficaz de crear un caché escalable y de muy alta capacidad. El hash consistente proporciona un buen grado de alta disponibilidad, lo que garantiza que si falla un caché, solo se invalida su parte del contenido almacenado en caché.

La segunda parte de esta publicación describe un patrón de caché compartido alternativo que replica el 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 fallas y no se pierde ningún contenido almacenado en caché si un servidor de caché no está disponible.

Pruebe la fragmentación de caché en sus propios servidores: comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .