Caches partagés avec les clusters de cache NGINX Plus, partie 2

Éditeur – Ceci est la deuxième partie d’une série sur la mise en cache à haute capacité et à haute disponibilité :

• Caches partagés avec les clusters de cache NGINX Plus, partie 1
• Caches partagés avec les clusters de cache NGINX Plus, partie 2 (ce post)

Comment pouvez-vous créer un cluster de cache de grande capacité et hautement disponible à l’aide de NGINX ou NGINX Plus ? Cet article décrit comment utiliser deux ou plusieurs serveurs de cache NGINX ou NGINX Plus pour créer un cluster de cache hautement disponible. (Sauf indication contraire, la méthode décrite ici s’applique également à NGINX Open Source et à NGINX Plus, mais par souci de concision, nous ferons référence à NGINX Plus uniquement.)

Test – La solution Sharded Cache

La première partie de cette série décrit un modèle de création de clusters de cache fragmentés très volumineux.

Ce modèle est efficace lorsque vous devez créer un cache de très grande capacité qui peut être étendu à volonté. Étant donné que chaque ressource n’est mise en cache que sur un seul serveur, elle n’est pas totalement tolérante aux pannes, mais l’équilibrage de charge de hachage cohérent garantit qu’en cas de défaillance d’un serveur, seule sa part du contenu mis en cache est invalidée.

Création d'un cluster de cache hautement disponible

Si minimiser à tout prix le nombre de requêtes adressées à vos serveurs d’origine est votre objectif principal, la solution de partitionnement du cache n’est pas la meilleure option. Au lieu de cela, une solution avec une configuration minutieuse des instances NGINX Plus primaires et secondaires peut répondre à vos besoins :

L'instance principale NGINX Plus reçoit tout le trafic et transmet les demandes à l'instance secondaire. L'instance secondaire récupère le contenu du serveur d'origine et le met en cache ; l'instance principale met également en cache la réponse du serveur secondaire et la renvoie au client.

Les deux appareils ont des caches entièrement remplis et le cache est actualisé en fonction des délais d'expiration configurés.

Configuration du serveur de cache principal

Configurez le serveur de cache principal pour transférer toutes les demandes au serveur secondaire et mettre en cache les réponses. Comme indiqué par le paramètre de sauvegarde de la directive serveur dans le groupe en amont, le serveur principal transmet les demandes directement au serveur d'origine en cas de défaillance du serveur secondaire :

proxy_cache_path /tmp/mycache keys_zone=mycache:10m; server { status_zone mycache; # pour l'écoute de l'état étendu NGINX Plus 80; proxy_cache mycache; proxy_cache_valid 200 15s; location / { proxy_pass http://secondary; } } upstream secondary { zone secondary 128k; # pour l'état étendu NGINX Plus server 192.168.56.11; # serveur secondaire 192.168.56.12 backup ; # origin }

Configuration du serveur de cache secondaire

Configurez le serveur de cache secondaire pour transférer les demandes au serveur d'origine et mettre en cache les réponses.

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
status_zone mycache; # pour le statut étendu de NGINX Plus

listen 80;

proxy_cache mycache;
proxy_cache_valid 200 15s;

location / {
proxy_pass http://origin;
}
}

upstream origin {
zone origin 128k; # pour le statut étendu de NGINX Plus

server 192.168.56.12; # origin
}

Configuration de la haute disponibilité

Enfin, vous devez configurer la haute disponibilité (HA) de sorte que le serveur secondaire prenne le trafic entrant en cas de défaillance du serveur principal ; le serveur principal reprend le trafic lorsqu'il récupère ultérieurement.

Dans cet exemple, nous utilisons la solution HA active-passive pour NGINX Plus . L'adresse IP virtuelle annoncée en externe est 192.168.56.20 et le serveur de cache principal agit comme nœud principal pour HA dans le cluster. Si vous utilisez NGINX Open Source, vous pouvez installer et configurer manuellement keepalived ou une autre solution HA.

Scénarios de basculement

Rappelons que nous souhaitons créer un cluster de cache hautement disponible qui continue de fonctionner même si un serveur de cache tombe en panne. Nous ne voulons pas que la charge sur le serveur d’origine augmente, que ce soit lorsqu’un serveur de cache tombe en panne ou lorsqu’il récupère et doit actualiser un contenu obsolète.

Supposons que le serveur primaire échoue et que la solution NGINX Plus HA transfère l’adresse IP externe au serveur secondaire.

Le secondaire a un cache plein et continue de fonctionner normalement. Il n'y a pas de charge supplémentaire sur le serveur d'origine.

Lorsque le serveur de cache principal récupère et commence à recevoir le trafic client, son cache sera obsolète et de nombreuses entrées auront expiré. Le serveur principal actualisera son cache local à partir du serveur de cache secondaire ; comme le cache du serveur secondaire est déjà à jour, il n’y a pas d’augmentation du trafic vers le serveur d’origine.

Supposons maintenant que le secondaire tombe en panne . Le serveur principal détecte cela (à l'aide d'un contrôle d'intégrité configuré dans le cadre de la solution HA) et transmet le trafic directement au serveur de sauvegarde (qui est le serveur d'origine).

Le serveur principal dispose d'un cache plein et continue de fonctionner normalement. Encore une fois, il n’y a pas de charge supplémentaire sur le serveur d’origine.

Lorsque le secondaire récupère, son cache sera obsolète. Cependant, il ne recevra les requêtes du primaire que lorsque le cache du primaire expirera, auquel cas la copie du secondaire aura également expiré. Même si le serveur secondaire doit effectuer une demande de contenu auprès du serveur d'origine, cela n'augmente pas la fréquence des demandes adressées au serveur d'origine. Il n’y a aucun effet négatif sur le serveur d’origine.

Test du comportement de basculement

Pour tester notre solution HA, nous configurons le serveur d'origine pour enregistrer les requêtes et renvoyer l'heure actuelle pour chaque requête. Cela signifie que la réponse du serveur d'origine change toutes les secondes :

access_log /var/log/nginx/access.log;
location / {
return 200 "Il est maintenant $time_localn";
}

Les serveurs de cache primaire et secondaire sont déjà configurés pour mettre en cache les réponses avec le code d'état200 pendant 15 secondes. Cela entraîne généralement des mises à jour du cache toutes les 15 ou 16 secondes.

proxy_cache_valide 200 15s;

Vérification du comportement du cache

Une fois par seconde, nous envoyons une requête HTTP à l’adresse IP virtuelle hautement disponible du cluster de cache. La réponse ne change pas jusqu’à ce que les caches sur les serveurs principal et secondaire expirent et que la réponse soit actualisée à partir du serveur d’origine. Cela se produit toutes les 15 ou 16 secondes.

$ while sleep 1 ; do curl http://192.168.56.20/ ; done Il est maintenant 9/Fév/2017:06:35:03 -0800 Il est maintenant 9/Fév/2017:06:35:03 -0800 Il est maintenant 9/Fév/2017:06:35:03 -0800 Il est maintenant 9/Fév/2017:06:35:19 -0800 Il est maintenant 9/Fév/2017:06:35:19 -0800 ^C

Nous pouvons également inspecter les journaux sur le serveur d’origine pour confirmer qu’il reçoit une demande uniquement toutes les 15 ou 16 secondes.

Vérification du basculement

Nous pouvons vérifier que le basculement fonctionne correctement en arrêtant soit le serveur principal, soit le serveur secondaire, par exemple en arrêtant les processus nginx . Le test de charge constante continue de s’exécuter et la réponse est systématiquement mise en cache.

L'inspection du journal d'accès sur le serveur d'origine confirme qu'il ne reçoit une demande que toutes les 15 à 16 secondes, quel que soit le serveur de cache qui tombe en panne ou récupère.

Moment des mises à jour du cache

Dans une situation stable, le contenu mis en cache est normalement mis à jour toutes les 15 à 16 secondes. Le contenu expire après 15 secondes et il y a un délai pouvant aller jusqu'à 1 seconde avant la réception de la prochaine requête, ce qui provoque une mise à jour du cache.

Parfois, le cache semble se mettre à jour plus lentement (jusqu'à 30 secondes entre les modifications de contenu). Cela se produit si le contenu du serveur de cache principal expire et que le serveur principal récupère le contenu mis en cache qui est presque expiré à partir du serveur secondaire. Si cela pose un problème, vous pouvez configurer un délai d’expiration du cache plus court sur le serveur secondaire.

Résumé

La hiérarchisation des caches entre deux ou plusieurs serveurs de cache NGINX de la manière que nous avons décrite ici est un moyen efficace de créer un cluster de cache hautement disponible qui minimise la charge sur les serveurs d’origine, les protégeant des pics de trafic lorsque l’un des serveurs de cache tombe en panne ou récupère.

La capacité totale du cache est limitée à la capacité d'un seul serveur de cache. La première partie de cette série décrit un modèle de cache fragmenté alternatif qui partitionne un cache sur un cluster de serveurs de cache. Dans ce cas, la capacité totale est la somme de tous les serveurs de cache, mais le contenu n'est pas répliqué pour se protéger contre les pics de trafic vers le serveur d'origine en cas de défaillance d'un serveur de cache.

Essayez la mise en cache haute disponibilité sur vos propres serveurs : démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .