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

Editor : Esta es la segunda 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
• Cachés compartidos con clústeres de caché NGINX Plus, parte 2 (esta publicación)

¿Cómo se puede crear un clúster de caché de gran capacidad y alta disponibilidad utilizando NGINX o NGINX Plus? Esta publicación describe cómo usar dos o más servidores de caché NGINX o NGINX Plus para crear un clúster de caché de alta disponibilidad. (Salvo que se indique lo contrario, el método descrito aquí se aplica igualmente a NGINX Open Source y NGINX Plus, pero para abreviar nos referiremos solo a NGINX Plus).

Revisión – La solución de caché fragmentada

La primera parte de esta serie describió un patrón para crear clústeres de caché fragmentados muy grandes.

Este patrón es efectivo cuando necesitas crear un caché de gran capacidad que pueda ampliarse a voluntad. Debido a que cada recurso se almacena en caché solo en un servidor, no es totalmente tolerante a fallas, pero el equilibrio de carga de hash consistente garantiza que si un servidor falla, solo su parte del contenido almacenado en caché se invalida.

Creación de un clúster de caché de alta disponibilidad

Si su objetivo principal es minimizar a toda costa la cantidad de solicitudes a sus servidores de origen, entonces la solución de fragmentación de caché no es la mejor opción. En cambio, una solución con una configuración cuidadosa de las instancias NGINX Plus primarias y secundarias puede satisfacer sus requisitos:

La instancia principal de NGINX Plus recibe todo el tráfico y reenvía solicitudes a la instancia secundaria. La instancia secundaria recupera el contenido del servidor de origen y lo almacena en caché; la instancia principal también almacena en caché la respuesta de la instancia secundaria y la devuelve al cliente.

Ambos dispositivos tienen cachés completamente poblados y el caché se actualiza de acuerdo con los tiempos de espera configurados.

Configuración del servidor de caché principal

Configure el servidor de caché principal para reenviar todas las solicitudes al servidor secundario y almacenar en caché las respuestas. Como lo indica el parámetro de respaldo de la directiva del servidor en el grupo ascendente, el servidor principal reenvía las solicitudes directamente al servidor de origen en caso de que falle el servidor secundario:

proxy_cache_path /tmp/mycache keys_zone=mycache:10m; servidor { zona_estado mycache; # para estado extendido de NGINX Plus escuchar 80; proxy_cache mycache; proxy_cache_valid 200 15s; ubicación / { contraseña_proxy http://secundario; } } ascendente secundario { zona secundaria 128k; # para estado extendido de NGINX Plus servidor 192.168.56.11; # servidor secundario 192.168.56.12 copia de seguridad ; # origen }

Configuración del servidor de caché secundario

Configure el servidor de caché secundario para reenviar solicitudes al servidor de origen y almacenar en caché las respuestas.

ruta_caché_proxy /tmp/mycache zona_claves=mycache:10m;
servidor {
zona_estado mycache; # para estado extendido de NGINX Plus

escuchar 80;

caché_proxy mycache;
caché_proxy_válido 200 15s;

ubicación / {
contraseña_proxy http://origen;
}
}

origen_upstream {
zona origen 128k; # para estado extendido de NGINX Plus

servidor 192.168.56.12; # origen
}

Configuración de alta disponibilidad

Por último, es necesario configurar la alta disponibilidad (HA) para que el servidor secundario tome el tráfico entrante si el servidor principal falla, y el servidor principal retome el tráfico cuando posteriormente se recupere.

En este ejemplo, utilizamos la solución HA activa-pasiva para NGINX Plus . La dirección IP virtual anunciada externamente es 192.168.56.20, y el servidor de caché principal actúa como el nodo principal para HA en el clúster. Si está utilizando NGINX Open Source, puede instalar y configurar manualmente keepalived o una solución HA diferente.

Escenarios de conmutación por error

Recordemos que queremos crear un clúster de caché de alta disponibilidad que continúe funcionando incluso si falla un servidor de caché. No queremos que la carga en el servidor de origen aumente, ya sea cuando falla un servidor de caché o cuando se recupera y necesita actualizar contenido obsoleto.

Supongamos que el primario falla y la solución NGINX Plus HA transfiere la dirección IP externa al secundario.

El secundario tiene un caché lleno y continúa funcionando con normalidad. No hay ninguna carga adicional en el servidor de origen.

Cuando el servidor de caché principal se recupera y comienza a recibir tráfico de clientes, su caché estará desactualizado y muchas entradas habrán expirado. El servidor principal actualizará su caché local desde el servidor de caché secundario; debido a que el caché en el servidor secundario ya está actualizado, no hay aumento en el tráfico hacia el servidor de origen.

Ahora supongamos que el secundario falla . El servidor principal detecta esto (utilizando un control de estado configurado como parte de la solución HA) y reenvía el tráfico directamente al servidor de respaldo (que es el servidor de origen).

El servidor principal tiene un caché lleno y continúa funcionando normalmente. Una vez más, no hay ninguna carga adicional en el servidor de origen.

Cuando el secundario se recupere, su caché quedará desactualizado. Sin embargo, solo recibirá solicitudes del servidor principal cuando expire el caché del principal, momento en el cual la copia del servidor secundario también habrá expirado. Aunque el secundario necesita realizar una solicitud de contenido al servidor de origen, esto no aumenta la frecuencia de solicitudes al origen. No hay ningún efecto adverso en el servidor de origen.

Prueba del comportamiento de conmutación por error

Para probar nuestra solución HA, configuramos el servidor de origen para registrar las solicitudes y devolver la hora actual de cada solicitud. Esto significa que la respuesta del servidor de origen cambia cada segundo:

registro_de_acceso /var/log/nginx/access.log;
ubicación / {
devuelve 200 "Ahora es $time_localn";
}

Los servidores de caché primario y secundario ya están configurados para almacenar en caché las respuestas con código de estado200 durante 15 segundos. Esto normalmente da como resultado actualizaciones de caché cada 15 o 16 segundos.

proxy_cache_valid 200 15s;

Verificación del comportamiento de la caché

Una vez por segundo, enviamos una solicitud HTTP a la dirección IP virtual de alta disponibilidad para el clúster de caché. La respuesta no cambia hasta que los cachés de los servidores primario y secundario expiran y la respuesta se actualiza desde el servidor de origen. Esto sucede cada 15 o 16 segundos.

$ while sleep 1 ; hacer curl http://192.168.56.20/ ; hecho Ahora es 9/Feb/2017:06:35:03 -0800 Ahora es 9/Feb/2017:06:35:03 -0800 Ahora es 9/Feb/2017:06:35:03 -0800 Ahora es 9/Feb/2017:06:35:19 -0800 Ahora es 9/Feb/2017:06:35:19 -0800 ^C

También podemos inspeccionar los registros en el servidor de origen para confirmar que está recibiendo una solicitud solo cada 15 o 16 segundos.

Verificación de conmutación por error

Podemos verificar que el failover esté funcionando correctamente deteniendo el servidor primario o el secundario, por ejemplo, deteniendo los procesos nginx . La prueba de carga constante continúa ejecutándose y la respuesta se almacena en caché de forma constante.

Al inspeccionar el registro de acceso en el servidor de origen, se confirma que solo recibe una solicitud cada 15 o 16 segundos, sin importar cuál de los servidores de caché falla o se recupera.

Momento de las actualizaciones de caché

En una situación estable, el contenido almacenado en caché normalmente se actualiza cada 15 a 16 segundos. El contenido caduca después de 15 segundos y hay una demora de hasta 1 segundo antes de que se reciba la siguiente solicitud, lo que provoca una actualización de caché.

Ocasionalmente, la memoria caché parecerá actualizarse más lentamente (hasta 30 segundos entre cambios en el contenido). Esto ocurre si el contenido del servidor de caché principal caduca y el servidor principal recupera contenido en caché que está casi caducado del servidor secundario. Si esto presenta un problema, puede configurar un tiempo de espera de caché más corto en el servidor secundario.

resumen

La organización de cachés en niveles entre dos o más servidores de caché NGINX de la manera que hemos descrito aquí es una forma eficaz de crear un clúster de caché de alta disponibilidad que minimiza la carga en los servidores de origen, protegiéndolos de picos de tráfico cuando uno de los servidores de caché falla o se recupera.

La capacidad total de la caché está limitada a la capacidad de un solo servidor de caché. La primera parte de esta serie describe un patrón de caché fragmentado alternativo que particiona un caché en un clúster de servidores de caché. En ese caso, la capacidad total es la suma de todos los servidores de caché, pero el contenido no se replica para protegerse contra picos de tráfico al servidor de origen si falla un servidor de caché.

Pruebe el almacenamiento en caché de alta disponibilidad en sus propios servidores: comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .