Redis Cluster gère les défaillances du nœud grâce à une combinaison de détection de défaillance, de promotion de répliques et de gestion de l'état de cluster pour assurer le fonctionnement continu et la disponibilité des données. Il est conçu pour survivre à des échecs de quelques nœuds en favorisant automatiquement les répliques pour remplacer les maîtres inaccessibles, en maintenant l'intégrité de l'espace clé tout en minimisant les risques de perte de données.
Communication en grappe et détection de défaillance
Les nœuds de cluster redis communiquent via un protocole binaire basé sur TCP dédié appelé le bus Redis Cluster. Chaque nœud maintient les connexions avec tous les autres nœuds du cluster à l'aide de ce bus, permettant des contrôles de santé continus et une propagation d'état. Les nœuds envoient périodiquement des paquets de ping pour confirmer l'état opérationnel de leurs pairs et partager des informations sur l'état du cluster. Cette communication utilise un protocole de potins pour diffuser efficacement les informations de cluster, en aidant dans la détection des défaillances du nœud.
Les nœuds surveillent les pairs utilisant un mécanisme de ping actif. Si un nœud ne répond pas aux Pings dans une période de délai d'expiration configurée (Node_timeout), il est signalé comme éventuellement échoué avec un statut PFAIL. Il s'agit d'une indication de défaillance provisoire, ce qui signifie que le nœud peut être inaccessible ou en panne, mais il n'est pas encore confirmé. Si la condition PFAIL persiste et est confirmée par la majorité des nœuds maîtres, le nœud est marqué en échec, indiquant qu'il est considéré comme inaccessible ou en baisse par le cluster. Ce mécanisme de détection de défaillance basé sur le consensus aide à prévenir les faux positifs dans l'identification des nœuds défaillants.
Gestion des échecs de nœud maître
Lorsqu'un nœud maître est signalé en échec, Redis Cluster initie un processus de basculement pour promouvoir l'une de ses répliques pour devenir le nouveau maître. Ce processus est déclenché automatiquement par le détecteur de défaillance du cluster sans intervention administrative. La réplique promue prend la responsabilité de servir les créneaux de hachage précédemment gérés par le maître raté, garantissant que le cluster peut continuer à servir les demandes sans reconfiguration manuelle.
Le basculement ne se produit que s'il y a au moins une réplique disponible et accessible à promouvoir. Si aucune réplique appropriée n'existe, le cluster entre dans un état d'erreur où il cessera d'accepter les requêtes pour empêcher la servitude de données incohérentes. Cela met en évidence l'importance d'avoir des répliques configurées pour chaque maître afin de maintenir la haute disponibilité.
Mécanique et sécurité de basculement
Pendant le basculement, la réplique attend de se synchroniser complètement avec le maître qu'elle remplace, garantissant qu'elle a traité toutes les mises à jour en attente pour éviter la perte de données. Il y parvient en faisant correspondre le décalage de réplication avec le maître afin qu'il ait un ensemble de données à jour avant d'assumer le rôle de maître.
Une fois synchronisé, la réplique demande une nouvelle époque de configuration à partir de la majorité des maîtres. L'époque est un horodatage logique utilisé pour suivre les modifications de configuration dans le cluster. Après avoir obtenu un consensus, la réplique diffuse la configuration mise à jour de tous les nœuds, annonçant sa promotion au maître et la rétrogradation de l'ancien maître à la réplique ou à la suppression.
L'ancien maître, lorsqu'il récupère, reçoit cette mise à jour de configuration et cesse de servir les requêtes en tant que maître. Il redirige les demandes des clients vers le nouveau maître, garantissant que les clients continuent de continuer à interagir avec le cluster sans intervention manuelle.
Gestion des partitions de réseau et des scénarios de cerveau fendu
Redis Cluster utilise un consensus majoritaire basé sur la majorité pour éviter les problèmes de cerveau divisé pendant les partitions de réseau. Un maître ne manquera que s'il est inaccessible de plus de la moitié des maîtres du cluster. Les maîtres qui ne peuvent pas communiquer avec la majorité cesseront d'accepter les écritures, empêchant les états de données divergents entre les partitions.
Cependant, si une partition minoritaire contient des clients qui continuent d'écrire à un maître avant le basculement, il existe un potentiel de perte d'écriture. Redis atténue ce risque en refusant les écritures du côté minoritaire après un délai d'attente et du côté majoritaire en échouant rapidement sur le maître inaccessible.
Malgré ces précautions, les écritures peuvent être perdues pendant les fenêtres de basculement car Redis utilise une réplication asynchrone entre les maîtres et les répliques. Étant donné que les réponses pour écrire des commandes et des mises à jour de réplication sont envoyées presque simultanément, la fenêtre pour perdre des écritures est très étroite mais pas impossible.
Options de configuration affectant la manipulation des échecs
Le cluster Redis comprend des options de configuration qui influencent la disponibilité et le comportement lors des défaillances du nœud:
- `cluster-require-full-coverage` (par défaut oui): le cluster cesse d'accepter les écritures si une partie de l'espace clé est découverte en raison de défaillances de nœuds, assurant une cohérence des données solide.
- `cluster-allow reads-when-down` (par défaut n °): contrôle si les lectures sont autorisées lorsque le cluster est dans un état de défaillance. L'activation de cela permet de lire des nœuds même pendant les défaillances partielles, mais peut risquer de risquer les données périmées.
Ces paramètres permettent aux administrateurs d'équilibrer la disponibilité et la cohérence en fonction des exigences de demande.
Support de basculement manuel
En plus du basculement automatique, Redis Cluster fournit une commande de basculement manuel qui peut être émise sur des nœuds de répliques. Ceci est utile pour les scénarios de maintenance ou de test où un administrateur souhaite échanger des rôles maître sans attendre un événement de défaillance réel.
Le basculement manuel fonctionne en bloquant les clients sur le maître actuel, en attendant que la réplique se rattrape complètement, puis en faisant la promotion de la réplique avec une transition atomique lisse. Cela n'assure aucune perte de données pendant le changement de rôle et une perturbation minimale pour les clients.
Résumé
Le cluster Redis gère les défaillances du nœud principalement via un système de détection de défauts et de basculement basé sur une surveillance continue via le bus Redis Cluster et un protocole de potins. Les nœuds détectent des maîtres inaccessibles et favorisent automatiquement les répliques après un processus de consensus nécessitant une majorité de maîtres à s'entendre sur l'échec. Le basculement est conçu pour minimiser la perte de données en garantissant que les répliques sont entièrement synchronisées avant la promotion. Les partitions de réseau sont gérées via des décisions basées sur la majorité pour prévenir les conditions de cerveau fendu, bien qu'une fenêtre étroite de perte d'écriture puisse se produire en raison de la réplication asynchrone. Les options de configuration permettent le réglage de la disponibilité par rapport à la cohérence pendant les échecs, et les commandes de basculement manuel donnent aux opérateurs le contrôle de la maintenance.
Cette architecture permet à Redis le cluster de fournir une haute disponibilité et une tolérance de partition avec une récupération automatique à partir de défaillances des nœuds maître, garantissant que le cluster reste opérationnel et cohérent dans les scénarios de défaillance.