Comment configurer Redis pour la haute disponibilité avec Sentinel dans CentOS 8 - Partie 2

Redis offre une haute disponibilité via le système distribué Redis Sentinel. Sentinel aide à surveiller les instances Redis, à détecter les échecs et effectuera automatiquement les changements de rôles, permettant ainsi à un déploiement Redis de résister à tout type d'échec.

Il propose 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 configuration permettant aux clients de découvrir le maître actuel offrant un service particulier.

Cet article montre comment configurer Redis pour la 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 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

Selon la documentation Redis Sentinel, il faut au moins trois instances Sentinel pour un déploiement robuste. Compte tenu de notre configuration ci-dessus, si le maître échoue, Sentinels2 et Sentinel3 se mettront d'accord sur l'échec et pourront autoriser un basculement, ce qui les opérations des clients peuvent se poursuivre.

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

1. Sur CentOS 8, le service Redis Sentinel est installé à côté du serveur Redis (ce que nous avons déjà fait dans la configuration de la réplication Redis).

Pour démarrer le service sentinelle Redis et lui permettre de démarrer automatiquement au démarrage du système, utilisez les commandes systemctl suivantes. Confirmez également qu'il est opérationnel en vérifiant son statut (faites ceci sur tous les nœuds) :

systemctl start redis-sentinel
systemctl enable redis-sentinel
systemctl status redis-sentinel

É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 à celui du serveur Redis. Pour le configurer, utilisez le fichier de configuration auto-documenté /etc/redis-sentinel.conf.

Tout d’abord, créez une sauvegarde du fichier original et ouvrez-le pour le modifier.

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-le sur toutes les instances. Notez que vous devez laisser le paramètre bind commenté (ou défini sur 0.0.0.0).

port 26379

4. Ensuite, dites à Sentinel de surveiller notre maître et de le considérer dans l'état « Objectivement Down » seulement si au moins 2 sentinelles du 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

Important : L'instruction sentinel monitor DOIT être placée avant l'instruction sentinel auth-pass pour éviter l'erreur « Aucun tel maître avec le nom spécifié. » lors du redémarrage du service sentinelle.

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

 
sentinel auth-pass mymaster Securep@55Here

6. Définissez ensuite le nombre de millisecondes pendant lesquelles le maître (ou toute réplique ou sentinelle attachée) doit être inaccessible pour le considérer dans l'état « Subjectivement désactivé ».

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

sentinel down-after-milliseconds mymaster 5000

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

sentinel failover-timeout mymaster 180000

8. Définissez ensuite le nombre de réplicas pouvant être reconfigurés pour utiliser le nouveau maître après un basculement en même temps. Puisque nous avons deux répliques, nous définirons une réplique car l’autre sera promue au nouveau maître.

sentinel parallel-syncs mymaster 1

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

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

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 à parler et de recevoir des connexions des autres Sentinel. Instances >Sentinel, en utilisant le pare-feu-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éplicas. 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 instructions known-sentinels et known-replica, comme indiqué dans la capture d'écran suivante.

Cela devrait être le même cas sur replica1 et replica2.

Notez que la configuration de Sentinel est également réécrite/mise à jour chaque fois qu'un réplica est promu au statut de maître lors d'un basculement 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/les informations Sentinel sur le maître, à l'aide de la commande info sentinel comme suit.

redis-cli -p 26379 info sentinel

À partir du résultat de la commande, comme le montre la capture d'écran suivante, nous avons deux répliques/esclaves et trois sentinelles.

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

14. Pour afficher des informations détaillées sur les esclaves et les sentinelles, utilisez la commande sentinel esclaves et sentinel commande sentinelles respectivement.

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 aux instances esclaves à l'aide de la commande sentinel get-master-addr-by-name comme suit.

Le résultat doit être l'adresse IP et le port de l'instance principale actuelle :

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

Étape 4 : tester le basculement Sentinel

16. Enfin, testons le basculement automatique dans notre configuration Sentinel. Sur le maître Redis/Sentinel, mettez le maître Redis (exécuté sur le port 6379) en veille pendant 60 secondes. . Recherchez ensuite l'adresse du maître actuel sur les répliques/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 le résultat de la requête, le nouveau maître est désormais replica/slave2 avec l'adresse IP 10.42.0.34, comme le montre la capture d'écran suivante.

Vous pouvez obtenir plus d'informations dans la documentation Redis Sentinel. Mais si vous avez des idées à partager ou des questions, le formulaire de commentaires ci-dessous est votre passerelle vers nous.

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