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

Éditeur – Ceci est la première 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 (ce post)
• Caches partagés avec les clusters de cache NGINX Plus, partie 2

Cet article a été mis à jour pour faire référence à l'API NGINX Plus, qui remplace et supprime le module d'état étendu distinct initialement décrit ici.

Comment pouvez-vous créer un cluster de cache de grande capacité et hautement disponible à l’aide de NGINX ou NGINX Plus ? Il s’agit de la première d’une série en deux parties qui présente une approche alternative pour atteindre cet objectif. Vous pouvez accéder à la deuxième partie via le lien ci-dessus. (Sauf indication contraire, les approches s’appliquent également à NGINX Open Source et à NGINX Plus, mais par souci de concision, nous ferons référence à NGINX Plus uniquement.)

Présentation de la mise en cache NGINX Plus

NGINX Plus peut fonctionner comme un serveur de cache proxy, situé 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 communes et immuables. Cela permet à NGINX Plus de répondre directement aux clients lorsque ces ressources sont demandées et réduit ainsi 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 à côté du serveur d’origine et peut également être déployé de manière similaire à un CDN dans des PoP distribués à l’échelle mondiale.

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

• Mécanique de mise en cache NGINX Plus – Configuration de base et rôle des processus de chargement et de gestion du cache
• Ajustement précis des temps de mise en cache – Mise en œuvre de pratiques telles que la micromise en cache pour contrôler la manière dont le contenu est mis en cache et dont il est actualisé lorsqu'il expire

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

Chaque serveur NGINX Plus agit 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’une décision de conception délibérée.

Stocker un cache sur un système de fichiers partagé à latence élevée et potentiellement peu fiable n’est pas un bon choix de conception. NGINX Plus est sensible à la latence du disque, et même si la capacité des pools de threads décharge les opérations read() et write() du thread principal, lorsque le système de fichiers est lent et que les E/S de cache sont élevées, NGINX Plus peut être submergé par de grands volumes de threads. Le maintien d’un cache partagé cohérent entre les instances NGINX Plus nécessiterait également des verrous à l’échelle du cluster pour 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 introduisent une source de manque de fiabilité et de performances imprévisibles dans la mise en cache, où la fiabilité et des performances cohérentes sont primordiales.

Pourquoi partager un cache sur 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 toujours de bonnes raisons de mettre en cache du contenu sur plusieurs serveurs NGINX Plus, chacun avec une technique correspondante :

• Si votre objectif principal est de créer un cache de très haute capacité, partitionnez votre cache sur plusieurs serveurs. Nous aborderons cette technique dans cet article.
• Si votre objectif principal est d’atteindre une haute disponibilité tout en minimisant la charge sur les serveurs d’origine, utilisez un cache partagé hautement disponible. Pour cette technique, voir l’article complémentaire (à venir).

Diviser votre cache

Le partitionnement d'un cache est le processus de distribution des entrées de cache sur plusieurs serveurs de cache Web. Le partitionnement du cache NGINX Plus utilise un algorithme de hachage cohérent pour sélectionner le serveur de cache pour chaque entrée de cache. Les figures montrent ce qui arrive à un cache réparti sur 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 est la somme de la capacité du cache de chaque serveur. Vous minimisez les déplacements vers le serveur d’origine car un seul serveur tente de mettre en cache chaque ressource (vous n’avez pas plusieurs copies indépendantes de la même ressource).

Ce modèle est tolérant aux pannes dans le sens où si vous avez 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 par le hachage cohérent sur les N -1 serveurs restants. Les méthodes de hachage plus simples redistribuent plutôt l'intégralité du cache sur les serveurs restants et vous perdez presque tout votre cache lors de la redistribution.

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

cache_servers en amont { hachage $scheme$proxy_host$request_uri cohérent ;

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

Vous pouvez distribuer le trafic entrant sur le niveau Load Balancer (LB) à l'aide de la solution de haute disponibilité active-passive de NGINX Plus , du DNS round-robin ou d'une solution de haute disponibilité telle que keepalived .

Optimisation de la configuration de votre cache fragmenté

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

Combinaison des niveaux d'équilibrage de charge et de cache

Vous pouvez combiner les niveaux LB et 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 demandes des clients externes et utilise un hachage cohérent pour les distribuer sur toutes les instances NGINX Plus du cluster, qui sont connectées par un réseau interne. Le serveur virtuel de mise en cache (« Cache VS ») sur chaque instance NGINX Plus écoute sur son adresse IP interne sa part de requêtes, les transmet au serveur d'origine et met en cache les réponses. Cela permet à toutes les instances NGINX Plus d'agir comme serveurs de mise en cache, maximisant ainsi votre capacité de cache.

Configuration d'un cache « chaud » de premier niveau

Vous pouvez également configurer un cache de premier niveau sur le niveau LB frontal pour le contenu très chaud, en utilisant le grand cache partagé comme cache de deuxième niveau. Cela peut améliorer les performances et réduire l’impact sur le serveur d’origine en cas d’échec d’un niveau de cache de deuxième niveau, car le contenu ne doit être actualisé qu’à mesure que le contenu du cache de premier niveau expire progressivement.

Si votre cluster de cache gère un très grand volume de contenu chaud, vous constaterez peut-être que le taux de rotation du cache de premier niveau plus petit est très élevé. En d’autres termes, la demande d’espace limité dans le cache est si élevée que le contenu est expulsé du cache (pour faire de la place au contenu demandé plus récemment) avant de pouvoir être utilisé pour satisfaire même une seule demande ultérieure.

Un indicateur de cette situation est un faible ratio entre le contenu servi et le contenu écrit, deux mesures incluses dans les statistiques étendues rapportées par le module API NGINX Plus . Ils apparaissent dans les champs Servi et Écrit dans l’onglet Caches du tableau de bord de surveillance des activités en direct intégré. (Notez que le module API NGINX Plus et le tableau de bord de surveillance des activités en direct ne sont pas disponibles dans NGINX Open Source.)

Cette capture d'écran indique la situation dans laquelle NGINX Plus écrit plus de contenu dans le cache qu'il n'en diffuse :

Dans ce cas, vous pouvez affiner votre cache pour stocker uniquement le contenu le plus fréquemment demandé. La directive proxy_cache_min_uses peut aider à identifier ce contenu.

Résumé

La répartition d’un cache sur plusieurs serveurs de cache Web NGINX ou NGINX Plus est un moyen efficace de créer un cache évolutif de très haute capacité. Le hachage cohérent offre un bon degré de haute disponibilité, garantissant que si un cache échoue, seule sa part du contenu mis en cache est invalidée.

La deuxième partie de cet article décrit un modèle de cache partagé alternatif qui réplique le cache sur une paire de serveurs de cache NGINX ou NGINX Plus. La capacité totale est limitée à la capacité d’un serveur individuel, mais la configuration est entièrement tolérante aux pannes et aucun contenu mis en cache n’est perdu si un serveur de cache devient indisponible.

Essayez le sharding de cache 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 .