Comment configurer Redis pour une haute disponibilité avec Sentinel sous CentOS 8 – Partie 2

Redis fournit une haute disponibilité via le système distribué Redis Sentinel. Sentinel aide à surveiller les instances Redis, détecter les pannes et effectuer automatiquement des basculements de rôles, permettant ainsi à un déploiement Redis de résister à tout type de défaillance.

Il offre la surveillance des instances Redis (maître et répliques), prend en charge la notification d’autres services/processus ou de l’administrateur système via un script, le basculement automatique pour promouvoir une réplique en maître lorsque le maître tombe en panne et fournit une configuration pour que les clients découvrent le maître actuel offrant un service particulier.

Cet article montre comment configurer Redis pour une haute disponibilité avec Redis Sentinel dans CentOS 8, y compris la configuration des sentinelles, la vérification de l’état de la configuration et le test d’un basculement de Sentinel.

Prérequis :

  1. Comment configurer la réplication Redis (avec le mode cluster désactivé) dans CentOS 8 – Partie 1

Configuration de l’environnement de test

Master Server and Sentinel1: 10.42.0.247
Redis Replica1 and Sentinel2: 10.42.0.21
Redis Replica2 and Sentinel3: 10.42.0.34
Redis Sentinel Setup Logical Diagram

Selon la documentation de Redis Sentinel, il faut au moins trois instances de Sentinel pour un déploiement robuste. En tenant compte de notre configuration ci-dessus, si le maître échoue, Sentinels2 et Sentinel3 seront d’accord sur l’échec et pourront autoriser une bascule, permettant ainsi aux opérations client de continuer.

Étape 1 : Démarrage et activation du service Redis Sentinel

1. Sur CentOS 8, le service Redis Sentinel est installé aux côtés du serveur Redis (que nous avons déjà configuré dans la Configuration de la Réplication Redis).

Pour démarrer le service Redis sentinel et le configurer pour démarrer automatiquement au démarrage du système, utilisez les commandes systemctl suivantes. Confirmez également qu’il est en cours d’exécution en vérifiant son état (faites ceci sur tous les nœuds) :

# systemctl start redis-sentinel
# systemctl enable redis-sentinel
# systemctl status redis-sentinel
Start Redis Sentinel Service

Étape 2 : Configuration de Redis Sentinel sur tous les nœuds Redis

2. Dans cette section, nous expliquons comment configurer Sentinel sur tous nos nœuds. Le service Sentinel a un format de configuration similaire au serveur Redis. Pour le configurer, utilisez le fichier de configuration auto-documenté /etc/redis-sentinel.conf.

Créez d’abord une sauvegarde du fichier original et ouvrez-le pour l’édition.

# cp /etc/redis-sentinel.conf /etc/redis-sentinel.conf.orig
# vi /etc/redis-sentinel.conf

3. Par défaut, Sentinel écoute sur le port 26379, vérifiez cela sur toutes les instances. Notez que vous devez laisser le paramètre bind en commentaire (ou défini sur 0.0.0.0).

port 26379
Set Sentinel Listen Interface and Port

4. Ensuite, indiquez à Sentinel de surveiller notre maître, et de le considérer comme étant dans l’état « Objectivement Down » uniquement si au moins 2 sentinelles de quorum sont d’accord. Vous pouvez remplacer « mymaster » par un nom personnalisé.

#On Master Server and Sentinel1
sentinel monitor mymaster 127.0.0.1 6379 2

#On Replica1 and Sentinel2
sentinel monitor mymaster 10.42.0.247 6379 2

#On Replica1 and Sentinel3
sentinel monitor mymaster 10.42.0.247 6379 2
Set Redis Master to Monitor

Important: La déclaration de surveillance de sentinel doit être placée avant la déclaration auth-pass de sentinel pour éviter l’erreur « Aucun maître avec le nom spécifié. » lors du redémarrage du service de sentinel.

5. Si le maître Redis à surveiller a un mot de passe défini (dans notre cas, le maître en a un), fournissez le mot de passe afin que l’instance de Sentinel puisse s’authentifier auprès de l’instance protégée.

 
sentinel auth-pass mymaster Securep@55Here
Set Master Auth Password

6. Ensuite, définissez le nombre de millisecondes pendant lesquelles le maître (ou toute réplique ou sentinelle attachée) doit être inaccessible pour le considérer comme étant dans l’état « Subjectivement Down« .

La configuration suivante signifie que le maître sera considéré comme défaillant dès que nous ne recevons aucune réponse de nos pings dans les 5 secondes (1 seconde équivaut à 1000 millisecondes).

sentinel down-after-milliseconds mymaster 5000
Set Down Time for Master

7. Ensuite, définissez le délai de basculement en millisecondes qui définit de nombreuses choses (lisez la documentation du paramètre dans le fichier de configuration).

sentinel failover-timeout mymaster 180000
Set Fail Over Timeout

8. Ensuite, définissez le nombre de répliques pouvant être reconfigurées pour utiliser le nouveau maître après une bascule en même temps. Comme nous avons deux répliques, nous en définirons une comme l’autre sera promue au nouveau maître.

sentinel parallel-syncs mymaster 1
Set Number of Parallel Sync Replicas

Notez que les fichiers de configuration sur Redis Replica1 et Sentinel2, et Redis Replica1 et Sentinel2 doivent être identiques.

9. Ensuite, redémarrez les services Sentinel sur tous les nœuds pour appliquer les changements récents.

# systemctl restart redis-sentinel

10. Ensuite, ouvrez le port 26379 dans le pare-feu sur tous les nœuds pour permettre aux instances Sentinel de commencer à communiquer, à recevoir des connexions des autres instances Sentinel, en utilisant la commande firewall-cmd.

# firewall-cmd --zone=public --permanent --add-port=26379/tcp
# firewall-cmd --reload

11. Toutes les répliques seront automatiquement découvertes. Il est important de noter que Sentinel mettra automatiquement à jour la configuration avec des informations supplémentaires sur les répliques. Vous pouvez le confirmer en ouvrant le fichier de configuration Sentinel pour chaque instance et en le parcourant.

Par exemple, lorsque vous regardez à la fin du fichier de configuration du maître, vous devriez voir les déclarations known-sentinels et known-replica comme indiqué dans la capture d’écran suivante.

Auto Generated Config in Master

Il devrait en être de même pour replica1 et replica2.

Auto Generated Config in Replica1
Auto Generated Config in Replica2

Notez que la configuration du Sentinel est également réécrite/mise à jour à chaque fois qu’une réplique est promue au statut de maître lors d’une bascule et à chaque fois qu’un nouveau Sentinel est découvert dans la configuration.

Étape 3 : Vérifiez l’état de la configuration de Redis Sentinel

12. Vérifiez maintenant l’état/information du Sentinel sur le maître en utilisant la commande info sentinel comme suit.

# redis-cli -p 26379 info sentinel

À partir de la sortie de la commande comme le montre la capture d’écran suivante, nous avons deux réplicas/esclaves et trois sentinelles.

Check Sentinel Info on Master

13. Pour afficher des informations détaillées sur le maître (appelé mymaster), utilisez la commande sentinel master.

# redis-cli -p 26379 sentinel master mymaster
Show Detailed Info About Sentinel Master

14. Pour afficher des informations détaillées sur les esclaves et les sentinelles, utilisez respectivement les commandes sentinel slaves et sentinel sentinels.

# redis-cli -p 26379 sentinel slaves mymaster
# redis-cli -p 26379 sentinel sentinels mymaster

15. Ensuite, demandez l’adresse du maître par son nom à partir des instances esclaves en utilisant la commande sentinel get-master-addr-by-name comme suit.

La sortie devrait être l’adresse IP et le port de l’instance maître actuelle:

# redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
Get the Address of Master by Name on Slaves

Étape 4 : Testez le basculement automatique du Sentinel

16. Enfin, testons le basculement automatique dans notre configuration Sentinel. Sur le maître Redis/Sentinel, mettez le maître Redis (fonctionnant sur le port 6379) en pause pendant 60 secondes. Ensuite, interrogez l’adresse du maître actuel sur les réplicas/esclaves comme suit.

# redis-cli -p 6379
127.0.0.1:6379> AUTH Securep@55Here
127.0.0.1:6379>  debug sleep 60
# redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
# redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

D’après la sortie de la requête, le nouveau maître est maintenant réplica/esclave2 avec l’adresse IP 10.42.0.34 comme le montre la capture d’écran suivante.

Test Redis Sentinel Failover

Vous pouvez obtenir plus d’informations à partir de la documentation de Redis Sentinel. Mais si vous avez des réflexions à partager ou des questions, le formulaire de rétroaction ci-dessous est votre passerelle vers nous.

Dans la prochaine et dernière partie de cette série, nous verrons comment configurer un cluster Redis sous CentOS 8. Ce sera un article indépendant des deux premiers.

Source:
https://www.tecmint.com/setup-redis-high-availability-with-sentinel-in-centos-8/