GNU/Linux >> Tutoriels Linux >  >> Cent OS

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

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

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

Cet article explique 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'une Sentinelle basculement.

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

Diagramme logique de configuration de Redis Sentinel

Selon Redis Sentinel documentation, il faut au moins trois Sentinel instances pour un déploiement robuste. Compte tenu de notre configuration ci-dessus, si le maître échoue, Sentinels2 et Sentinel3 sera d'accord sur l'échec et pourra autoriser un basculement, permettant aux opérations client de continuer.

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

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

Pour démarrer Redis service sentinelle et lui permettre de démarrer automatiquement au démarrage du système, utilisez le systemctl suivant commandes. 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

Démarrer le service Sentinelle Redis

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

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

Tout d'abord, créez une sauvegarde du fichier d'origine 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 ceci sur toutes les instances. Notez que vous devez quitter le bind paramètre commenté (ou défini sur 0.0.0.0 ).

port 26379

Définir l'interface et le port d'écoute Sentinel

4. Ensuite, dites à Sentinel pour surveiller notre maître , et de le considérer dans le "Objectively Down » n'indiquer que si au moins 2 sentinelles du quorum sont d'accord. Vous pouvez remplacer "mymaster ” avec 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

Définir Redis Master sur Monitor

Important  : la déclaration du moniteur sentinelle DOIT être placée avant la sentinelle 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 Redis maître à surveiller a un mot de passe défini (dans notre cas, le maître 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 [email protected]

Définir le mot de passe d'authentification principal

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 le "Subjectively Down ” état.

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

Définir le temps d'arrêt pour le maître

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

sentinel failover-timeout mymaster 180000

Définir le délai de basculement

8. Définissez ensuite le nombre de répliques pouvant être reconfigurées pour utiliser simultanément le nouveau maître après un basculement. Puisque 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

Définir le nombre de répliques de synchronisation parallèle

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

9. Ensuite, redémarrez le Sentinel services 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 activer la Sentinelle instances pour commencer à parler, recevoir des connexions de l'autre Sentinelle instances, en utilisant le firewall-cmd.

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

11. Toutes les répliques seront automatiquement découvertes. Surtout, Sentinelle mettra automatiquement à jour la configuration avec des informations supplémentaires sur les répliques. Vous pouvez le confirmer en ouvrant la Sentinelle fichier de configuration pour chaque instance et parcourez-le.

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

Configuration générée automatiquement dans Master

Cela devrait être le même cas sur replica1 et réplique2 .

Configuration générée automatiquement dans Replica1

Configuration générée automatiquement dans Replica2

Notez que la Sentinelle la configuration 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 la Sentinelle statut/informations sur le maître, à l'aide de la info sentinelle commande comme suit.

# redis-cli -p 26379 info sentinel

À partir de la sortie de la commande, comme illustré dans la capture d'écran suivante, nous avons deux répliques/esclaves et trois sentinelles.

Vérifier les informations Sentinel sur le maître

13. Pour afficher des informations détaillées sur le maître (appelé monmaître ), utilisez le maître sentinelle commande.

# redis-cli -p 26379 sentinel master mymaster

Afficher les informations détaillées sur Sentinel Master

14. Pour afficher des informations détaillées sur les esclaves et sentinelles , utilisez les esclaves sentinelles commande et sentinelles sentinelles commande 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 sentinelle get-master-addr-by-name commande 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

Obtenir l'adresse du maître par nom sur les esclaves

Étape 4 :Tester le basculement Sentinel

16. Enfin, testons le basculement automatique dans notre Sentinel mettre en place. Sur Redis/Sentinel maître, faites le Redis maître (fonctionnant sur le port 6379 ) pour dormir 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 [email protected]
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 on le voit dans la capture d'écran suivante.

Tester le basculement Sentinel Redis

Vous pouvez obtenir plus d'informations dans la documentation de 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 configurer un cluster Redis dans CentOS 8. Ce sera un article indépendant des deux premiers.

Partager c'est aimer…
Partager sur FacebookPartager sur TwitterPartager sur LinkedinPartager sur Reddit
Cent OS
  1. Comment configurer un serveur FTP avec VSFTPD sur CentOS 7

  2. Comment configurer un serveur FTP avec VSFTPD sur CentOS 8

  3. Comment configurer Apache Subversion avec HTTPS Letsencrypt sur CentOS 7

  4. Comment configurer la haute disponibilité Nginx avec Pacemaker et Corosync sur CentOS 7

  5. Comment configurer Pure-FTPD avec MySQL sur CentOS et RedHat

Comment installer Redis sur CentOS 7

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

Comment configurer un cluster Redis dans CentOS 8 - Partie 3

Comment configurer la haute disponibilité pour Namenode – Partie 5

Comment installer et configurer Hive avec une haute disponibilité – Partie 7

Comment configurer la haute disponibilité pour Resource Manager - Partie 6