Comment configurer un cluster Redis sur CentOS 7

introduction

Redis est un magasin de données open source clé-valeur utilisant un modèle de stockage en mémoire avec des écritures de disque facultatives pour la persistance. Il comporte, entre autres fonctionnalités, des transactions, des publications / sous-publications et des basculements automatiques. Il est recommandé d’utiliser Redis avec Linux pour les environnements de production, mais les développeurs mentionnent également OS X en tant que plate-forme sur laquelle ils développent et testent. Redis a des clients écrits dans la plupart des langues, les plus recommandés figurant sur their leur site Web.

Pour les environnements de production, la réplication de vos données sur au moins deux nœuds est considérée comme la meilleure pratique. La redondance permet la récupération en cas de défaillance de l’environnement, ce qui est particulièrement important lorsque le nombre d’utilisateurs de votre application augmente.

À la fin de ce guide, nous aurons mis en place deux droplets Redis sur DigitalOcean, comme suit:

  • un Droplet pour le serveur maître Redis

  • un droplet pour le serveur esclave Redis

Nous montrerons également comment passer au serveur esclave et le configurer en tant que maître temporaire.

N’hésitez pas à configurer plusieurs serveurs esclaves.

Cet article se concentre sur la configuration d’un cluster Redis maître-esclave; Pour en savoir plus sur Redis en général et sur son utilisation de base en tant que base de données, voir cien tutoriel d’utilisation.

Conditions préalables

Bien que cela puisse fonctionner sur des versions antérieures et d’autres distributions Linux, nous vous recommandons d’utiliser CentOS 7.

À des fins de test, nous utiliserons de petites instances car il n’ya pas de charge de travail réelle à traiter, mais les environnements de production peuvent nécessiter des serveurs plus grands.

  • CentOS 7

  • Deux gouttelettes, de n’importe quelle taille; un * maître * et un ou plusieurs * esclave (s) *

  • Accès à vos machines via SSH avec un utilisateur sudo non root, comme expliqué dans Paramètres de serveur initial avec CentOS 7

Étape 1 - Installez Redis

En commençant par le Droplet qui hébergera notre * serveur maître *, nous commencerons par installer Redis. Nous devons d’abord activer le référentiel EPEL sur notre machine. Si vous ne le connaissez pas, EPEL est le référentiel Extra Packages for Enterprise Linux, développé par le projet Fedora dans le but de fournir des packages tiers de qualité aux entreprises utilisatrices de distributions basées sur RHEL.

wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

Si + wget + n’est pas reconnu, essayez d’exécuter + yum install wget + avant la commande ci-dessus.

Maintenant, lancez:

sudo rpm -ivh epel-release-7-5.noarch.rpm

Et maintenant, tapez:

sudo yum -y update

Notez que cela peut prendre un certain temps. Maintenant, vous pouvez installer Redis sur votre machine en lançant:

sudo yum install redis -y

Une fois le processus d’installation terminé, le service Redis est lancé à l’aide de la commande suivante:

sudo systemctl start redis.service

Et vérifier son statut peut être fait avec la commande suivante:

sudo systemctl status redis.service

Ce qui produit quelque chose de similaire à:

Output

Enfin, testons notre configuration Redis en exécutant:

redis-cli ping

Cela devrait imprimer un + PONG + comme réponse. Si tel est le cas, Redis est installé sur votre serveur et nous pouvons commencer à le configurer. Un test supplémentaire pour notre configuration peut être effectué en exécutant:

redis-benchmark -q -n 1000 -c 10 -P 5

La commande ci-dessus indique que nous voulons que le + redis-benchmark + soit exécuté en mode silencieux, avec un total de 1 000 requêtes, 10 connexions parallèles et 5 requêtes en pipeline. Pour plus d’informations sur l’exécution de tests de performances pour Redis, saisissez + redis-benchmark --help + dans votre terminal pour afficher des informations utiles avec des exemples.

Laissez le repère courir. Une fois terminé, vous devriez voir une sortie semblable à celle-ci:

Output

Répétez maintenant cette section pour le serveur esclave Redis *. Si vous configurez plus de gouttelettes, vous pouvez configurer autant de serveurs esclaves que nécessaire.

À ce stade, Redis est installé et fonctionne sur nos deux nœuds. Si la sortie d’un nœud ne ressemble pas à ce qui est présenté ci-dessus, répétez soigneusement le processus d’installation et vérifiez que toutes les conditions préalables sont remplies.

Étape 2 - Configurer Redis Master

Maintenant que Redis est opérationnel sur notre cluster à deux droplets, nous devons modifier leurs fichiers de configuration. Comme nous le verrons, il existe des différences mineures entre la configuration du serveur maître et de l’esclave.

Commençons d’abord par notre * maître *.

Ouvrez + / etc / redis.conf + avec votre éditeur de texte préféré:

sudo vi /etc/redis.conf

Editez les lignes suivantes.

Définissez une valeur raisonnable sur le timer keepalive pour TCP:

/etc/redis.conf

tcp-keepalive

Rendez le serveur accessible à tous sur le Web en commentant cette ligne:

/etc/redis.conf

bind 127.0.0.1

Étant donné la nature de Redis et ses vitesses très élevées, un attaquant peut forcer brutalement le mot de passe sans trop de problèmes. C’est pourquoi nous recommandons de supprimer la mise en commentaire de la ligne + requirepass + et d’ajouter un mot de passe complexe (ou une phrase secrète complexe, de préférence):

/etc/redis.conf

requirepass

Selon votre scénario d’utilisation, vous pouvez modifier la ligne suivante ou non. Pour les besoins de ce tutoriel, nous supposons qu’aucune suppression de clé ne doit avoir lieu. Décommentez cette ligne et définissez-la comme suit:

/etc/redis.conf

maxmemory-policy

Enfin, nous souhaitons apporter les modifications suivantes, nécessaires à la sauvegarde des données. Décommentez et / ou définissez ces lignes comme indiqué:

/etc/redis.conf

appendonly
appendfilename ""

Enregistrez vos modifications.

Redémarrez le service Redis pour recharger nos modifications de configuration:

sudo systemctl restart redis.service

Maintenant que le serveur maître est prêt, passons à la machine esclave.

Étape 3 - Configurez Redis Slave

Nous devons apporter certaines modifications permettant à notre * serveur esclave * de se connecter à notre instance maître:

Ouvrez + / etc / redis.conf + avec votre éditeur de texte préféré:

sudo vi /etc/redis.conf

Editez les lignes suivantes. certains réglages seront similaires à ceux du maître.

Rendez le serveur accessible à tous sur le Web en commentant cette ligne:

/etc/redis.conf

bind 127.0.0.1

Le serveur esclave a également besoin d’un mot de passe pour pouvoir lui donner des commandes (telles que + INFO +). Décommentez cette ligne et définissez un mot de passe serveur:

/etc/redis.conf

requirepass

Décommentez cette ligne et indiquez l’adresse IP à laquelle le * serveur maître * peut être atteint, suivi du port défini sur cette machine. Par défaut, le port est 6379:

/etc/redis.conf

slaveof

Décommentez la ligne + masterauth + et fournissez le mot de passe / phrase secrète que vous avez défini précédemment sur le * serveur maître *:

/etc/redis.conf

masterauth

Enregistrez maintenant ces modifications et quittez le fichier. Ensuite, redémarrez le service comme nous l’avons fait sur notre serveur maître:

sudo systemctl restart redis.service

Cela réinitialisera Redis et chargera nos fichiers modifiés.

Connectez-vous à Redis:

redis-cli -h 127.0.0.1 -p

Autoriser avec le * mot de passe du serveur esclave *:

AUTH

À ce stade, nous exécutons un cluster Redis maître-esclave fonctionnel, avec les deux machines correctement configurées.

Étape 4 - Vérification de la réplication maître-esclave

Tester notre configuration nous permettra de mieux comprendre le comportement de nos Redis Droplets, une fois que nous voulons commencer à écrire le comportement du basculement. Ce que nous voulons faire maintenant, c’est nous assurer que notre configuration fonctionne correctement et que notre maître discute avec les instances Redis esclaves.

Tout d’abord, nous nous connectons à Redis via notre terminal, sur le * serveur maître *:

Connectez-vous d’abord à l’instance locale, exécutée par défaut sur le port 6379. Si vous avez modifié le port, modifiez la commande en conséquence.

redis-cli -h 127.0.0.1 -p

Maintenant, authentifiez-vous avec Redis avec le mot de passe que vous avez défini lors de la configuration du maître:

AUTH

Et vous devriez obtenir un «+ OK +» comme réponse. Maintenant, il vous suffit de lancer:

INFO

Vous verrez tout ce que vous devez savoir sur le serveur maître Redis. Nous sommes particulièrement intéressés par la section + # Replication +, qui devrait ressembler à la sortie suivante:

Output. . .

# Replication
role:master
connected_slaves:1
slave0:ip=,port=,state=online,offset=407,lag=1
master_repl_offset:407
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:406

. . .

Notez la ligne + connected_slaves: 1 +, qui indique que notre autre instance parle avec le droplet maître. Vous pouvez également voir que nous obtenons l’adresse IP de l’esclave, ainsi que le port, l’état et d’autres informations.

Voyons maintenant la section + # Replication + sur notre machine esclave. Le processus est le même que pour notre serveur maître. Connectez-vous à l’instance Redis, lancez la commande + INFO + et affichez le résultat:

Output. . .

# Replication
role:slave
master_host:
master_port:
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:1401
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

. . .

Nous pouvons voir que cette machine a le rôle d’esclave, communique avec le serveur maître Redis et ne possède pas d’esclave.

Étape 5 - Basculez vers l’esclave

La construction de cette architecture signifie que nous souhaitons également que les défaillances soient gérées de manière à garantir l’intégrité des données et le moins de temps d’arrêt possible pour notre application. Tout esclave peut être promu pour devenir un maître. Commençons par tester la commutation manuellement.

Sur une * machine esclave *, nous devrions nous connecter à l’instance Redis:

redis-cli -h 127.0.0.1 -p

Maintenant, authentifiez-vous avec Redis avec le mot de passe que vous avez défini lors de la configuration de l’esclave.

AUTH

Désactiver le comportement des esclaves:

SLAVEOF NO ONE

La réponse devrait être + OK +. Maintenant tapez:

INFO

Recherchez la section + # Replication + pour trouver le résultat suivant:

Output. . .

# Replication
role:master
connected_slaves:0
master_repl_offset:1737
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

. . .

Comme nous nous y attendions, l’esclave est devenu un maître et est maintenant prêt à accepter les connexions d’autres machines (le cas échéant). Nous pouvons l’utiliser comme une sauvegarde temporaire pendant le débogage de notre serveur maître principal.

Cela peut être scripté facilement, avec les étapes suivantes devant être implémentées une fois qu’un échec est détecté:

  • Depuis l’application, envoyez toutes les demandes de Redis à une machine esclave.

  • Sur cet esclave, exécutez la commande + SLAVEOF NO ONE +. À partir de Redis version 1.0.0, cette commande demande à l’esclave de cesser de répliquer les données et de commencer à agir en tant que serveur maître.

  • L’exécution de + SLAVEOF + sur tous les esclaves restants (le cas échéant) leur indiquera d’arrêter la réplication à partir de l’ancien maître, à supprimer complètement les données désormais obsolètes et à commencer à répliquer à partir du nouveau maître. Assurez-vous de remplacer ` et ` par les valeurs correctes de votre maître nouvellement promu

  • Après avoir analysé le problème, vous pouvez rétablir votre serveur initial en tant que maître si votre configuration particulière le requiert.

Étape 6 - Reconnecter au maître

Reconnectons-nous au serveur maître d’origine. Sur le * serveur esclave *, connectez-vous à Redis et exécutez les opérations suivantes:

SLAVEOF

Si vous exécutez à nouveau la commande + INFO +, vous devriez voir que nous sommes revenus à la configuration d’origine.

Conclusion

Nous avons correctement configuré un environnement composé de deux serveurs, l’un faisant office de maître Redis et l’autre répliquant les données sous forme d’esclave. Ainsi, si le serveur maître se déconnecte ou perd nos données, nous savons comment passer à l’un de nos esclaves pour la récupération jusqu’à ce que le problème soit résolu.

Les étapes suivantes peuvent inclure la création de scripts de la procédure de basculement automatique ou la sécurisation des communications entre toutes vos droplets à l’aide de solutions VPN telles que https://www.digitalocean.com/community/tutorials/how-to-setup-and-configure- un-openvpn-server-on-centos-7 [OpenVPN]. En outre, les procédures de test et les scripts sont essentiels pour la validation de vos configurations.

De plus, vous devez prendre des précautions lors du déploiement de ce type de configuration dans des environnements de production. La page Redis Documentation doit être étudiée et vous devez avoir une idée claire du modèle de sécurité adéquat pour votre application. Nous utilisons souvent Redis comme magasin de session, et les informations qu’il contient peuvent être utiles à un attaquant. La pratique courante consiste à rendre ces machines accessibles uniquement via un réseau privé et à les placer derrière plusieurs couches de sécurité.

C’est un point de départ simple sur lequel votre magasin de données peut être construit; Il ne s’agit nullement d’un guide exhaustif sur l’utilisation de l’architecture maître-esclave par Redis. Si vous pensez que ce guide devrait couvrir quelque chose, veuillez laisser des commentaires ci-dessous. Pour plus d’informations et d’aide sur ce sujet, la DigitalOcean Q & R est un bon point de départ.