Comment configurer la réplication Redis sur Ubuntu 16.04

introduction

Redis est un magasin de données clé-valeur open source, utilisant un modèle de stockage en mémoire avec des écritures de disque optionnelles pour la persistance. Il comporte des transactions, un modèle de messagerie pub / secondaire et un basculement automatique, entre autres fonctionnalités. Redis a des clients écrits dans la plupart des langues, les recommandées étant présentées surtheir website.

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. Cela permet une 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 s'agrandit. Il vous permet également d'interagir en toute sécurité avec les données de production sans les modifier ni affecter les performances.

Dans ce guide, nous allons configurer la réplication entre deux serveurs, exécutant tous deux Ubuntu 16.04. Ce processus peut être facilement adapté pour plus de serveurs si nécessaire.

Conditions préalables

Pour compléter ce guide, vous devez avoir accès à deux serveurs Ubuntu 16.04. Conformément à la terminologie utilisée par Redis, nous désignerons les serveurs principaux responsables de l'acceptation des demandes d'écriture comme le serveurmaster et le serveur secondaire en lecture seule comme le serveurslave.

Vous devez avoir un utilisateur non root avec les privilègessudo configurés sur chacun de ces serveurs. De plus, ce guide supposera que vous avez un pare-feu de base en place. Vous pouvez suivre nosUbuntu 16.04 initial server setup guide pour remplir ces conditions.

Lorsque vous êtes prêt à commencer, continuez avec ce guide.

Étape 1: Installez Redis

Pour commencer, nous installerons Redis sur les serveursmaster etslave.

Nous installerons un package Redis Server à jour en utilisantChris Lea’s Redis PPA. Soyez toujours prudent lorsque vous activez des référentiels tiers. Dans ce cas, Chris Lea est un emballeur bien établi qui gère de nombreux emballages de haute qualité.

Tout d’abord, ajoutez le PPA à vos deux serveurs:

sudo apt-add-repository ppa:chris-lea/redis-server

Appuyez surENTER pour accepter le référentiel.

Ensuite, mettez à jour l’index de paquet local du serveur et installez le paquet du serveur Redis en tapant:

sudo apt-get update
sudo apt-get install redis-server

Cela installera le serveur Redis et lancera le service.

Vérifiez que Redis est opérationnel en tapant:

redis-cli ping

Vous devriez recevoir la réponse suivante:

OutputPONG

Cela indique que Redis est en cours d'exécution et est accessible au client local.

Étape 2: Sécuriser le trafic entre les deux serveurs

Avant de configurer la réplication, il est important de comprendre les implications du modèle de sécurité de Redis. Redis n'offre aucune option de cryptage native et suppose qu'il a été déployé sur un réseau privé de pairs de confiance.

Si Redis est déployé sur un réseau isolé…

Si vos serveurs fonctionnent sur un réseau isolé, il vous suffira probablement d’ajuster le fichier de configuration de Redis pour vous connecter à l’adresse IP de votre réseau isolé.

Ouvrez le fichier de configuration Redis sur chaque ordinateur:

sudo nano /etc/redis/redis.conf

Recherchez la lignebind et ajoutez la propre adresse IP du réseau isolé du serveur:

/etc/redis/redis.conf

bind 127.0.0.1 isolated_IP_address

Enregistrez et fermez le fichier. Redémarrez le service en tapant:

sudo systemctl restart redis-server.service

Ouvrez l'accès au port Redis:

sudo ufw allow 6379

Vous devriez maintenant pouvoir accéder à un serveur depuis l’autre en fournissant l’adresse IP du serveur alternatif à la commanderedis-cli avec l’indicateur-h:

redis-cli -h isolated_IP_address ping
OutputPONG

Redis peut maintenant accepter les connexions de votre réseau isolé.

Si Redis n'est pas déployé sur un réseau isolé…

Pour les réseaux qui ne sont pas isolés ou que vous ne contrôlez pas, il est impératif que le trafic soit sécurisé par d'autres moyens. Il existe de nombreuses options pour sécuriser le trafic entre les serveurs Redis, notamment:

  • Tunneling with stunnel: Vous aurez besoin d'un tunnel entrant et sortant pour chaque serveur. Un exemple est disponible vers le bas du guide.

  • Tunneling with spiped: Vous devrez créer deux fichiers d'unité systemd par serveur, un pour communiquer avec le serveur distant et un pour transférer les connexions vers son propre processus Redis. Les détails sont inclus vers le bas du guide.

  • Setting up a VPN with PeerVPN: les deux serveurs devront être accessibles sur le VPN.

En utilisant l’une des méthodes ci-dessus, établissez une méthode de communication sécurisée entre votre serveur Redis maître et votre serveur esclave. Vous devez connaître l'adresse IP et le port dont chaque machine a besoin pour se connecter en toute sécurité au service Redis sur son homologue.

Étape 3: Configurez Redis Master

Maintenant que Redis est opérationnel sur chaque serveur et qu'un canal de communication sécurisé a été établi, nous devons modifier leurs fichiers de configuration. Commençons par le serveur qui fonctionnera en tant quemaster.

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

sudo nano /etc/redis/redis.conf

Commencez par trouver le paramètretcp-keepalive et réglez-le sur 60 secondes comme le suggèrent les commentaires. Cela aidera Redis à détecter les problèmes de réseau ou de service:

/etc/redis/redis.conf

. . .
tcp-keepalive 60
. . .

Recherchez la directiverequirepass et définissez-la sur une phrase de passe forte. Bien que votre trafic Redis doit être sécurisé de tiers, cela fournit une authentification à Redis lui-même. Comme Redis est rapide et n’évalue pas le nombre de tentatives de mot de passe, choisissez un mot de passe complexe et complexe pour vous protéger contre les tentatives de force brutale:

/etc/redis/redis.conf

requirepass your_redis_master_password

Enfin, il existe quelques paramètres facultatifs que vous voudrez peut-être ajuster en fonction de votre scénario d'utilisation.

Si vous ne voulez pas que Redis élague automatiquement les clés les plus anciennes et les moins utilisées au fur et à mesure de son remplissage, vous pouvez désactiver l'expulsion automatique des clés:

/etc/redis/redis.conf

maxmemory-policy noeviction

Pour des garanties de durabilité améliorées, vous pouvez activer la persistance de fichier avec ajout uniquement. Cela aidera à minimiser les pertes de données en cas de défaillance du système, aux dépens de fichiers plus volumineux et de performances légèrement plus lentes:

/etc/redis/redis.conf

appendonly yes
appendfilename "redis-staging-ao.aof"

Lorsque vous avez terminé, enregistrez et fermez le fichier.

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

sudo systemctl restart redis-server.service

Maintenant que le serveur maître est configuré, prenez le temps de le tester.

Étape 4: Testez le maître Redis

Vérifiez que vous pouvez vous authentifier à l'aide du mot de passe que vous avez défini en démarrant le client Redis:

redis-cli

Commencez par essayer une commande sans authentifier:

info replication

Vous devriez obtenir la réponse suivante:

Redis master outputNOAUTH Authentication required.

Ceci est attendu et indique que notre serveur Redis rejette correctement les requêtes non authentifiées.

Ensuite, utilisez la commandeauth pour vous authentifier:

auth your_redis_master_password

Vous devriez recevoir la confirmation que vos informations d'identification ont été acceptées:

Redis master outputOK

Si vous essayez à nouveau, la commande devrait réussir cette fois-ci:

info replication
Redis master output# Replication
role:master
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

Pendant que vous êtes authentifié, définissez une clé de test afin que nous puissions vérifier la réplication ultérieurement:

set test 'this key was defined on the master server'

Revenez au shell du système d'exploitation lorsque vous avez terminé:

exit

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

Étape 5: Configurez l'esclave Redis

Ensuite, nous devons apporter quelques modifications pour permettre à nosslave server de se connecter à notre instance maître.

Ouvrez/etc/redis/redis.conf sur le serveur esclave:

sudo nano /etc/redis/redis.conf

Tout d'abord, recherchez et supprimez les commentaires de la ligneslaveof. Cette directive utilise l'adresse IP et le port que vous utilisez pour contacter le serveur Redis maître en toute sécurité, séparés par un espace. Par défaut, le serveur Redis écoute 6379 sur l'interface locale, mais chacune des méthodes de sécurité réseau modifie en quelque sorte la valeur par défaut pour les tiers.

Les valeurs que vous utiliserez dépendront de la méthode utilisée pour sécuriser votre trafic réseau:

  • isolated network: utilisez l'adresse IP du réseau isolé et le port Redis (6379) du serveur maître (par exempleslaveof isolated_IP_address 6379).

  • stunnel ouspiped: utilisez l'interface locale (127.0.0.1) et le port configuré pour tunneliser le trafic (ce seraitslaveof 127.0.0.1 8000 si vous suiviez le guide).

  • PeerVPN: utilisez l’adresse IP VPN du serveur maître et le port Redis normal (ce seraitslaveof 10.8.0.1 6379 si vous suiviez le guide).

La forme générale est:

/etc/redis/redis.conf

slaveof ip_to_contact_master port_to_contact_master

Ensuite, décommentez et remplissez la lignemasterauth avec le mot de passe qui a été défini pour le serveur maître Redis:

/etc/redis/redis.conf

masterauth your_redis_master_password

Définissez un mot de passe pour votre serveur esclave afin d'empêcher les accès non autorisés. Les mêmes avertissements concernant la complexité du mot de passe s'appliquent ici:

/etc/redis/redis.conf

requirepass your_redis_slave_password

Enregistrez et fermez le fichier lorsque vous avez terminé.

Étape 6: Testez l'esclave Redis et appliquez les modifications

Avant de redémarrer le service pour implémenter nos modifications, connectons-nous à l'instance Redis locale sur la machine esclave et vérifions que la clétest n'est pas définie:

redis-cli

Interrogez la clé en tapant:

get test

Vous devriez obtenir la réponse suivante:

Redis slave output(nil)

Cela indique que l'instance Redis locale n'a pas de clé nomméetest. Revenez au shell en tapant:

exit

Redémarrez le service Redis sur l'esclave pour implémenter ces modifications:

sudo systemctl restart redis-server.service

Ceci appliquera toutes les modifications apportées au fichier de configuration de l'esclave Redis.

Reconnectez-vous à l'instance Redis locale à nouveau:

redis-cli

Comme avec le serveur maître Redis, les opérations devraient maintenant échouer si elles ne sont pas autorisées:

get test
Redis slave output(error) NOAUTH Authentication required.

Maintenant, authentifiez-vous en utilisant le mot de passe de l’esclave Redis que vous avez défini dans la dernière section:

auth your_redis_slave_password
Redis slave outputOK

Si nous essayons d'accéder à la clé cette fois-ci, nous constaterons qu'elle est disponible:

get test
Redis slave output"this key was defined on the master server"

Une fois que nous avons redémarré notre service Redis sur l'esclave, la réplication a commencé immédiatement.

Vous pouvez le vérifier avec la commandeinfo de Redis, qui fournit des informations sur la réplication. La valeur demaster_host etmaster_port doit correspondre aux arguments que vous avez utilisés pour l'optionslaveof:

info replication
Redis slave output# Replication
role:slave
master_host:10.8.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:1387
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

Si vous consultez les mêmes informations sur le serveur maître Redis, vous verrez quelque chose comme ceci:

info replication
Redis master output# Replication
role:master
connected_slaves:1
slave0:ip=10.8.0.2,port=6379,state=online,offset=1737,lag=1
master_repl_offset:1737
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1736

Comme vous pouvez le constater, les serveurs maître et esclave s’identifient correctement dans leur relation définie.

Étape 7: Promouvoir un esclave Redis en maître

Une des principales raisons de la configuration de la réplication est de gérer les pannes avec un minimum de pertes de données et de temps d'arrêt. Les esclaves Redis peuvent être promus au statut de maître pour gérer le trafic d'écriture en cas de défaillance du maître Redis.

Promouvoir un esclave Redis manuellement

Nous pouvons le faire manuellement à partir du serveur esclave Redis. Connectez-vous avec le client Redis:

redis-cli

Authentifiez-vous avec le mot de passe de l'esclave Redis:

auth your_redis_slave_password

Avant de promouvoir l'esclave Redis, essayez d'écraser la clé de test:

set test 'this key was overwritten on the slave server'

Cela devrait échouer car, par défaut, les esclaves Redis sont configurés pour être en lecture seule avec l'optionslave-read-only yes:

Redis slave output(error) READONLY You can't write against a read only slave.

Pour désactiver la réplication et promouvoir le serveur actuel au statut de maître, utilisez la commandeslaveof avec la valeurno one:

slaveof no one
Redis slave outputOK

Vérifiez à nouveau les informations de réplication:

info replication
Redis slave output# Replication
role:master
connected_slaves:0
master_repl_offset:6749
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Comme vous pouvez le constater, l’esclave est désormais désigné maître Redis.

Essayez d'écraser à nouveau la clé, et cette fois-ci, elle devrait réussir:

set test 'this key was overwritten on the slave server'
Redis slave outputOK

N'oubliez pas que, le fichier de configuration désignant toujours ce nœud comme esclave Redis, si le service est redémarré sans modifier la configuration, il reprendra la réplication. Notez également que vous devrez peut-être réappliquer ici tous les paramètres que vous avez utilisés pour le maître Redis (par exemple, activer des fichiers ne contenant que des ajouts ou modifier la stratégie d'expulsion).

S'il existe d'autres esclaves, dirigez-les vers le maître nouvellement promu pour continuer à répliquer les modifications. Cela peut être fait en utilisant la commandeslaveof et les informations de connexion du nouveau maître.

Pour reprendre manuellement la réplication vers le maître d'origine, pointez le maître provisoire et les esclaves vers le maître d'origine à l'aide de la commandeslaveof avec les valeurs utilisées dans le fichier de configuration:

slaveof ip_to_contact_master port_to_contact_master
Redis slave outputOK

Si vous vérifiez à nouveau la clé sur l'esclave, vous devriez voir que la valeur d'origine a été restaurée par le maître Redis:

get test
Redis slave output"this key was defined on the master server"

Pour des raisons de cohérence, toutes les données de l'esclave sont vidées lors de la resynchronisation avec un serveur maître.

Promouvoir un esclave Redis automatiquement

La promotion automatique d'un esclave Redis nécessite une coordination avec la couche application. Cela signifie que la mise en œuvre dépend fortement de l'environnement de l'application, ce qui rend difficile la suggestion d'actions spécifiques.

Cependant, nous pouvons passer en revue les étapes générales nécessaires pour effectuer un basculement automatique. Les étapes ci-dessous supposent que tous les serveurs Redis ont été configurés pour accéder les uns aux autres:

  • À partir de l'application, détectez que le serveur maître n'est plus disponible.

  • Sur un esclave, exécutez la commandeslaveof no one. Cela arrêtera la réplication et favorisera son statut de maître.

  • Ajustez tous les paramètres du nouveau maître afin de les aligner sur les paramètres précédents. Cela peut être fait à l'avance dans le fichier de configuration pour la plupart des options.

  • Trafic direct de votre application vers le maître Redis nouvellement promu.

  • Sur tous les esclaves restants, exécutezslaveof new_master_ip new_master_port. Ainsi, les esclaves cesseront de se répliquer à partir de l'ancien maître, abandonneront complètement leurs données (maintenant obsolètes) et commenceront à se répliquer à partir du nouveau maître.

Une fois que vous avez restauré le service sur le serveur maître d'origine, vous pouvez soit lui permettre de rejoindre le poste en tant qu'esclave pointant vers le maître nouvellement promu, soit lui permettre de reprendre le service en tant que maître si nécessaire.

Conclusion

Nous avons mis en place un environnement composé de deux serveurs, l’un jouant le rôle de maître Redis et l’autre reproduisant les données sous forme d’esclave. Cela permet la redondance en cas de défaillance des systèmes ou du réseau et peut aider à répartir les opérations de lecture sur plusieurs serveurs pour des raisons de performances. C’est un bon point de départ pour concevoir une configuration Redis qui réponde à vos besoins en matière d’application de production et d’infrastructure, mais ce n’est en aucun cas un guide exhaustif sur le sujet. Pour en savoir plus sur l'utilisation de Redis pour les besoins de vos applications, consultez nosother Redis tutorials.