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

Owen GarrettDirecteur senior de la gestion des produits

Note de la rédaction – Voici le premier volet d’une série consacrée à la mise en cache haute capacité et haute disponibilité :

• Caches partagés avec des clusters de cache NGINX Plus, partie 1 (cet article)
• Caches partagés avec les clusters de cache NGINX Plus, 2e partie

Cet article a été mis à jour pour faire référence à l’API NGINX Plus, qui remplace et rend obsolète le module distinct de statut étendu initialement présenté ici.

Comment créer un cluster de cache à haute capacité et haute disponibilité à l’aide de NGINX ou NGINX Plus ? Cet article est le premier d’une série en deux parties présentant différentes approches pour atteindre cet objectif. Vous pouvez accéder à la seconde partie via le lien ci-dessus. (Sauf indication contraire, ces approches s’appliquent aussi bien à NGINX Open Source qu’à NGINX Plus, mais, par souci de concision, nous ferons uniquement référence à NGINX Plus.)

Présentation de la mise en cache avec NGINX Plus

NGINX Plus peut fonctionner comme un serveur de cache proxy, placé entre le serveur d’origine et les clients distants. NGINX Plus gère le trafic vers le serveur d’origine et met en cache (stocke) les ressources courantes qui ne changent pas. NGINX Plus peut ainsi répondre directement aux clients lorsque ces ressources sont demandées, ce qui réduit la charge sur le serveur d’origine. Le cache proxy de NGINX Plus est le plus souvent déployé dans un centre de données à proximité du serveur d’origine, mais il peut également être déployé à la manière d’un CDN dans des points de présence (PoP) répartis dans le monde entier.

La mise en cache du contenu est un sujet étonnamment complexe. Il est utile de vous familiariser avec quelques techniques de base de mise en cache avant de poursuivre la lecture de cet article :

• Fonctionnement de la mise en cache de NGINX Plus – Configuration de base et rôle des processus de chargement et de gestion du cache
• Ajustement précis des durées de mise en cache – Mise en œuvre de pratiques telles que la mise en cache de très courte durée afin de contrôler la façon dont le contenu est mis en cache et actualisé lorsqu’il expire

Pourquoi NGINX Plus n’utilise-t-il pas un disque partagé pour la mise en cache ?

Chaque serveur NGINX Plus fonctionne comme un serveur de cache web indépendant. Il n’existe aucun moyen technique de partager un cache sur disque entre plusieurs serveurs NGINX Plus ; il s’agit d’un choix de conception délibéré.

Le stockage d’un cache sur un système de fichiers partagé à latence élevée et potentiellement peu fiable n’est pas un choix judicieux en matière de conception. NGINX Plus est sensible à la latence des disques et, même si la fonctionnalité de pools de threads décharge le thread principal des opérations read() et write(), lorsque le système de fichiers est lent et que les E/S du cache sont importantes, NGINX Plus peut se retrouver submergé par un grand nombre de threads. Le maintien d’un cache partagé cohérent entre les instances NGINX Plus nécessiterait également des verrous à l’échelle du cluster afin de synchroniser les opérations de cache qui se chevauchent, telles que les remplissages, les lectures et les suppressions. Enfin, les systèmes de fichiers partagés rendent la mise en cache moins fiable et ses performances imprévisibles, alors que la fiabilité et la constance des performances sont primordiales.

Pourquoi partager un cache entre plusieurs serveurs NGINX Plus ?

Bien que le partage d’un système de fichiers ne soit pas une bonne approche pour la mise en cache, il existe néanmoins de bonnes raisons de mettre en cache du contenu sur plusieurs serveurs NGINX Plus, chacune faisant appel à une technique adaptée :

• Si votre objectif principal est de créer un cache de très grande capacité, répartissez-le (partitionnez-le) entre plusieurs serveurs. Nous aborderons cette technique dans cet article.
• Si votre objectif principal est d’assurer une haute disponibilité tout en réduisant au minimum la charge sur les serveurs d’origine, utilisez un cache partagé à haute disponibilité. Pour en savoir plus sur cette technique, consultez l’article complémentaire (à paraître prochainement).

Partitionnement de votre cache

Le partitionnement d’un cache consiste à répartir les entrées du cache entre plusieurs serveurs de cache web. Le partitionnement du cache de NGINX Plus utilise un algorithme de hachage cohérent pour sélectionner un serveur de cache unique pour chaque entrée du cache. Les figures montrent ce qui se passe pour un cache partitionné entre trois serveurs (figure de gauche) lorsqu’un serveur tombe en panne (figure du milieu) ou qu’un autre serveur est ajouté (figure de droite).

La capacité totale du cache correspond à la somme des capacités de cache de chaque serveur. Vous réduisez au minimum les requêtes adressées au serveur d’origine, car un seul serveur tente de mettre en cache chaque ressource (vous ne disposez pas de plusieurs copies indépendantes d’une même ressource).

Ce modèle est tolérant aux pannes : si vous disposez de N serveurs de cache et que l’un d’eux tombe en panne, vous ne perdez que 1/N de votre cache. Cette « partie perdue » est répartie uniformément entre les N –1 serveurs restants grâce au hachage cohérent. À l’inverse, les méthodes de hachage plus simples redistribuent l’intégralité du cache entre les serveurs restants, ce qui entraîne la perte de la quasi-totalité du cache pendant la redistribution.

Lorsque vous effectuez un équilibrage de charge par hachage cohérent, utilisez la clé de cache (ou un sous-ensemble des champs utilisés pour construire la clé) comme clé du hachage cohérent :

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;
}

Vous pouvez répartir le trafic entrant entre les instances de la couche d’équilibrage de charge (LB) à l’aide de la solution de haute disponibilité active-passive de NGINX Plus, d’un DNS à tour de rôle ou d’une solution de haute disponibilité telle que keepalived.

Optimisation de la configuration de votre cache partitionné

Vous pouvez choisir l’une des deux optimisations proposées pour votre configuration de partitionnement du cache.

Combinaison des couches d’équilibrage de charge et de cache

Vous pouvez combiner les niveaux d’équilibrage de charge et de cache. Dans cette configuration, deux serveurs virtuels s’exécutent sur chaque instance NGINX Plus. Le serveur virtuel d’équilibrage de charge (« LB VS » dans la figure) accepte les requêtes des clients externes et utilise un hachage cohérent pour les répartir entre toutes les instances NGINX Plus du cluster, lesquelles sont reliées par un réseau interne. Le serveur virtuel de mise en cache (« Cache VS ») de chaque instance NGINX Plus écoute sur son adresse IP interne les requêtes qui lui sont attribuées, les transmet au serveur d’origine et met les réponses en cache. Ainsi, toutes les instances NGINX Plus peuvent faire office de serveurs de cache, ce qui permet d’optimiser votre capacité de cache.

Configuration d’un cache « chaud » de premier niveau

Vous pouvez également configurer un cache de premier niveau sur la couche d’équilibrage de charge frontale pour les contenus très sollicités, en utilisant le grand cache partagé comme cache de second niveau. Cela peut améliorer les performances et réduire l’impact sur le serveur d’origine en cas de défaillance d’une couche de cache de second niveau, car le contenu n’a besoin d’être actualisé qu’au fur et à mesure de l’expiration progressive du contenu du cache de premier niveau.

Si votre cluster de caches traite un très grand volume de contenu très sollicité, il se peut que le taux de renouvellement du cache de premier niveau, plus petit, soit très élevé. En d’autres termes, la demande pour l’espace limité du cache est telle que le contenu en est évincé (afin de libérer de la place pour du contenu demandé plus récemment) avant même de pouvoir répondre à une seule requête ultérieure.

L’un des indicateurs de cette situation est un faible rapport entre le contenu servi et le contenu écrit, deux métriques incluses dans les statistiques étendues fournies par le module d’API NGINX Plus. Elles apparaissent dans les champs Served et Written de l’onglet Caches du tableau de bord intégré de surveillance de l’activité en temps réel. (Notez que le module d’API NGINX Plus et le tableau de bord de surveillance de l’activité en temps réel ne sont pas disponibles dans NGINX Open Source.)

Cette capture d’écran illustre une situation dans laquelle NGINX Plus écrit davantage de contenu dans le cache qu’il n’en fournit à partir de celui-ci :

Dans ce cas, vous pouvez affiner la configuration de votre cache afin de ne stocker que le contenu le plus fréquemment demandé. La directive « proxy_cache_min_uses » peut vous aider à identifier ce contenu.

Résumé

Le partitionnement d’un cache entre plusieurs serveurs de cache web NGINX ou NGINX Plus constitue un moyen efficace de créer un cache évolutif de très grande capacité. Le hachage cohérent offre un bon niveau de haute disponibilité, garantissant qu’en cas de défaillance d’un cache, seule la part du contenu mis en cache qui lui est attribuée est invalidée.

La deuxième partie de cet article décrit une autre architecture de cache partagé, qui réplique le cache sur deux serveurs de cache NGINX ou NGINX Plus. La capacité totale est limitée à celle d’un seul serveur, mais la configuration offre une tolérance totale aux pannes et aucun contenu mis en cache n’est perdu si un serveur de cache devient indisponible.

Testez le partitionnement du cache sur vos propres serveurs : commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Owen GarrettDirecteur senior de la gestion des produits

Autres articles de Owen Garrett