Recherche de site Web

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


Redis assure une haute disponibilité via le système distribué Redis Sentinel. Sentinel permet de surveiller les instances Redis, de détecter les défaillances et d’effectuer automatiquement des changements de rôles, permettant ainsi à un déploiement Redis de résister à tout type de défaillance.

Il permet de surveiller les 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 explique 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 de 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 seront d’accord sur l’échec et pourront autoriser un basculement, rendant les opérations du client pouvant continuer.

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

1. Sur CentOS 8, le service Redis Sentinel est installé en même temps que le 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. Vérifiez également qu’il est opérationnel en vérifiant son état (faites-le 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 d’origine et ouvrez-la pour l’éditer.

# 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 en commentaire (ou défini sur 0.0.0.0).

port 26379

4. Ensuite, dites à la Sentinelle de surveiller notre maître, et de ne le considérer dans l’état « Objectivement en baisse » que 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 maître de ce type 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 en a), 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 en panne ».

La configuration suivante signifie que le maître sera considéré comme en échec dès que nous ne recevons pas de 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 d’expiration du basculement en millisecondes qui définit beaucoup de 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épliques qui peuvent être reconfigurées pour utiliser le nouveau maître après un basculement en même temps. Comme nous avons deux répliques, nous allons définir 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, ainsi que 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, de recevoir des connexions des autres instances Sentinel, à l’aide du 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éplicas. Vous pouvez le vérifier 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 devez voir les instructions known-sentinels et known-replica, comme illustré dans la capture d’écran suivante.

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

Notez que la configuration de Sentinel est également réécrite/mise à jour chaque fois qu’un réplica est promu à l’état maître lors d’un basculement et chaque fois qu’un nouveau Sentinel est découvert dans le programme d’installation.

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

12. Vérifiez maintenant l’état/les informations de Sentinel sur le maître à l’aide de la commande info sentinel comme suit.

# redis-cli -p 26379 info sentinel

D’après la sortie de la commande comme on le voit dans 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 respectivement le commandement des esclaves sentinelles et le commandement des sentinelles sentinelles.

# 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 à l’aide de la commande sentinel get-master-addr-by-name comme suit.

La sortie doit être l’adresse IP et le port de l’instance maître 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. Interrogez 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

À partir de la sortie de la requête, le nouveau maître est maintenant 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 de Redis Sentinel. Mais si vous avez des réflexions à partager ou des questions, le formulaire de commentaires ci-dessous est votre porte d’entrée vers nous.

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

Articles connexes: