Redis est un système de gestion de base de données de la classe NoSQL (SGBD non relationnels) placé entièrement en RAM. Pour accéder aux données, le modèle «clé» - «valeur» est utilisé. Un tel SGBD est souvent utilisé pour stocker des caches dans des services évolutifs, pour stocker des images et de petites données.
Redis DBMS est largement utilisé en raison de:
- haute vitesse, car toutes les données sont stockées dans la RAM;
- multiplateforme;
- distribution sous licence BSD (s'applique aux logiciels open source).
L'étendue de la distribution et de l'applicabilité de Redis peut être estimée par l'énorme quantité de documentation avec toutes sortes de cas sur le
site officiel du projet .
Si vous utilisez la mise à l'échelle horizontale des services DirectumRX, vous devez utiliser l'installation à tolérance de pannes Redis pour fonctionner correctement avec le service de stockage DirectumRX et le service d'accès Web DirectumRX.
Redis stockera les données opérationnelles, les caches et autres informations nécessaires au fonctionnement des services en mode évolutif afin que le processus d'interaction de l'utilisateur avec le système ne dépende pas de l'installation avec laquelle il travaille actuellement.
Redis ne stockera pas de données sensibles et ne sera pas soumis à une charge importante. Mais en cas de panne de Redis, les utilisateurs rencontreront de nombreuses erreurs lors du basculement entre les installations.
Sur le site officiel de Redis, il existe 2 façons d'assurer la mise à l'échelle horizontale et la tolérance aux pannes:
- Utilisation de Redis Sentiel .
- Utilisation de Redis Cluster .
Pensez à personnaliser ces options.
Configurer Redis Sentiel
L'option utilisant le Redis Sentiel (Redis Tracking Node) a été implémentée dans Redis 2.4 et consiste à utiliser le service supplémentaire Redis Sentiel pour surveiller la disponibilité de l'assistant. Il effectue également la configuration des nœuds de réplique en cas de panne de l'assistant. Détermine lequel des nœuds SLAVE deviendra MASTER et effectuera la reconfiguration en déplacement.
Met en œuvre le schéma classique:
Il peut y avoir de nombreux nœuds SLAVE (jusqu'à 1000 selon le site officiel), pour un travail productif, il est recommandé d'utiliser au moins deux nœuds SLAVE.
En règle générale, le schéma est configuré de telle manière que le service Redis Sentiel est configuré sur les nœuds MASTER et SLAVE, et si le nœud MASTER échoue, les nœuds de surveillance restants décident d'introduire un nouveau MASTER.
La version actuelle de Redis est disponible en téléchargement sur le
site officiel du développeur du produit . Cependant, le site de distribution n'est disponible que pour Linux. À un moment donné,
le projet Microsoft de portage de Redis vers Windows était en cours de développement, mais à l'heure actuelle, le projet a arrêté le développement sur la version 3.2.100, donc dans cet article, nous considérerons l'option de déploiement la plus pertinente - sous Linux.
Comme nœuds de test, nous utiliserons deux hôtes virtuels redis1 et redis2 avec la distribution Linux installée de Debian 10.
Tout d'abord, mettez à jour les listes de packages à partir du référentiel par défaut et installez Redis:
apt-get update && apt-get upgrade apt install redis-server
Vérifiez la version:
root@redis1:/home/user
Laissez redis1 agir en tant que nœud MASTER et redis2 agir en tant que nœud SLAVE.
Pour ce faire, nous écrivons dans les fichiers de configuration Redis les paramètres nécessaires qui vous permettront de créer une réplique (pas encore tolérante aux pannes).
Pour redis1 dans le fichier de configuration /etc/redis/redis.conf, spécifiez:
Pour redis2 dans le fichier de configuration /etc/redis/redis.conf, spécifiez:
Redémarrez les services redis-server sur les deux nœuds:
root@redis1:/etc/redis
Nous vérifions côté MASTER que les nœuds sont devenus des répliques et ont reçu les rôles nécessaires:
root@redis1:/etc/redis
Côté ESCLAVE, on voit la même situation:
root@redis2:/etc/redis
Vous devez maintenant configurer la réplique pour qu'elle soit automatiquement restaurée en cas de défaillance de l'un des nœuds. Pour ce faire, nous avons besoin du service de suivi Redis Sentinel.
Sur la base de la
documentation , le service de surveillance Redis Sentinel peut effectuer les opérations suivantes:
- Vérifie la disponibilité des nœuds MASTER et SLAVE et est capable d'envoyer des alertes sur l'inaccessibilité des nœuds.
- Si le nœud MASTER échoue, le nœud témoin peut mettre le nœud SLAVE en mode MASTER, ainsi que reconfigurer les nœuds SLAVE restants, et ils commencent à fonctionner avec le nouveau MASTER.
- Apporte des modifications aux fichiers de configuration des nœuds MASTER et SLAVE.
Pour la pureté de l'expérience, nous placerons un service témoin sur une machine virtuelle redis3 distincte.
Nous connectons le référentiel Redis de la même manière et installons le package redis-sentinel:
apt install redis-sentinel
Après l'installation, vous devez effectuer les réglages dans le fichier de configuration du nœud de surveillance /etc/redis/sentinel.conf:
Redémarrez le service après avoir effectué les réglages:
root@redis3:/etc/redis
Vérifiez que le service de suivi a vu MASTER et SLAVE:
root@redis3:/etc/redis
Nous commençons les expériences.
Nous simulons un échec, arrêtons le service redis-server sur le nœud redis1 et obtenons les informations actuelles du nœud témoin:
root@redis3:/etc/redis
Nous voyons que MASTER a changé.
Nous allons restaurer le fonctionnement du nœud redis1 et vérifier son état:
root@redis3:/var/log/redis
Nous voyons que le nœud a reçu le rôle SLAVE, et le nœud redis2 est un nœud MASTER.
Simulez la défaillance du nœud redis2 et vérifiez l'état du nœud témoin:
root@redis3:/var/log/redis
Et l'état du nœud redis1:
root@redis3:/var/log/redis
Génial, le mécanisme fonctionne. Mais maintenant, la question s'est posée de savoir comment nous connecterons nos services DirectumRX, car ils ont besoin d'une adresse de nœud unique. Nous allons résoudre la situation en utilisant le service HAProxy.
Redis Node Proxying
Tout service TCP proxy peut agir comme un proxy inverse pour les nœuds Redis. Dans cet article, nous considérerons l'utilisation de HAProxy, car il s'agit d'un outil spécialisé conçu pour fournir une haute disponibilité et un équilibrage de charge, et qui est utilisé par des services en ligne universellement connus. En savoir plus sur HAProxy
sur la page développeur .
Installez HAProxy sur le nœud redis3:
root@redis3:/var/log/redis
Dans le fichier de configuration HAProxy /etc/haproxy/haproxy.cfg, ajoutez les paramètres des requêtes de proxy aux nœuds Redis:
… frontend ft_redis bind *:6379 name redis mode tcp default_backend bk_redis backend bk_redis mode tcp option tcp-check tcp-check connect
Dans cette configuration, il est indiqué que nous allons proxy toutes les requêtes qui arrivent à toutes les interfaces de la machine virtuelle actuelle à l'adresse sur le port 6379. Nous transmettrons les requêtes au nœud qui répondra qu'il a le rôle MASTER.
Redémarrez le service haproxy:
root@redis3:/etc/haproxy
Essayons de nous connecter en utilisant le client redis-cli et créons une clé de test:
root@redis3:/etc/haproxy
Arrêtez le nœud redis1 et interrogez à nouveau la liste des clés:
127.0.0.1:6379> info keyspace Error: Server closed the connection (3.01s) 127.0.0.1:6379> info keyspace
Nous voyons que pendant un certain temps la connexion a été déconnectée, mais ensuite la connexion a été rétablie et toutes les données sont restées en place.
Il suffit maintenant d'enregistrer l'adresse proxy inverse dans les fichiers de configuration des services DirectumRX pour se connecter à Redis.
Configurer le cluster Redis
L'option de clustering Redis Cluster, implémentée pour la version redis 3.0 et supérieure, est une solution pour créer et gérer un cluster avec segmentation et réplication de données. Effectue des tâches de gestion des nœuds, de réplication, de synchronisation des données sur les nœuds et assure l'accès de l'application cliente au nœud MASTER en cas de défaillance de l'un des nœuds MASTER.
Redis Cluster fonctionne en mode multimaître, chaque nœud MASTER peut avoir un ou plusieurs nœuds SLAVE (jusqu'à 1000).
La mise à l'échelle est la fonction principale du cluster. De plus, le cluster peut garantir la tolérance aux pannes du service Redis:
- si certains nœuds ne fonctionnent pas, le cluster redistribue la charge d'eux vers d'autres nœuds;
- si les nœuds clés ne fonctionnent pas, l'ensemble du cluster se termine.
Une situation peut se produire lorsque le client 2 écrit sur le nœud M2. M2 répond «OK» et essaie d'écrire à S2. Dans le même temps, M2 n'attend pas la fin correcte de l'échange de données avec S2, mais répond immédiatement au client. Dans ce cas, la réplique S2 peut ne pas avoir toutes les données. Par conséquent, il est recommandé d'utiliser plusieurs répliques SLAVE.
Une situation peut également survenir lorsque M1, M3 cessent de «voir» M2 et que le client continue d'écrire des données dans M2. Si l'indisponibilité continue pendant un certain temps (le paramètre cluster-node-timeout), alors dans ce cas, S2 sera mis en mode MASTER et M2 cessera de fonctionner de lui-même.
La documentation officielle recommande d'utiliser 6 nœuds - une instance Redis par nœud, ce qui permet
une plus grande fiabilité, mais personne n'interdit d'utiliser trois nœuds avec la topologie de connexion suivante:
Si l'un des nœuds physiques tombe en panne, les répliques SLAVE correspondantes passeront en mode MASTER et le fonctionnement ne sera pas interrompu.
Nous implémentons 3 machines virtuelles (redis1, redis2 et redis3) sur le banc de test, chacune exécutant 2 instances Redis.
L'application cliente se connectera à un port spécifique spécifié dans le fichier de configuration client, par conséquent, les paires MASTER - SLAVE devraient fonctionner sur les mêmes ports.
Pour la paire M1 - S1, nous utiliserons le port 6381
Pour la paire M2 - S2, nous utiliserons le port 6382
Pour la paire M3 - S3, nous utiliserons le port 6383
Préparez les fichiers de configuration
Sur redis1:
cp /etc/redis/redis.conf /etc/redis/m1_redis.conf cp /etc/redis/redis.conf /etc/redis/s2_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Sur redis2:
cp /etc/redis/redis.conf /etc/redis/m2_redis.conf cp /etc/redis/redis.conf /etc/redis/s3_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Sur redis3:
cp /etc/redis/redis.conf /etc/redis/m3_redis.conf cp /etc/redis/redis.conf /etc/redis/s1_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Remplissez les fichiers de configuration selon le modèle:
bind <IP- > protected-mode no
Lançons les nœuds Redis:
Noeud redis1:
root@redis1:/etc/redis
Noeud Redis2:
root@redis2:/etc/redis
Noeud Redis3:
root@redis3:/etc/redis
Pour configurer le cluster, vous devez utiliser l'utilitaire client redis-cli, en lui passant une liste de paires de serveurs ip: port qui joueront les rôles de MASTER et SLAVE:
redis-cli --cluster create redis1-ip:6381 redis2-ip:6382 redis3-ip:6383 redis1-ip:6382 redis2-ip:6383 redis3-ip:6381 --cluster-replicas 1
, où l'option --cluster-replicas 1 vous indique le nombre d'esclaves que chaque maître aura et ils sont automatiquement sélectionnés dans la liste des réplicas transférés.
root@redis1:~/redis/src
Le cluster est correctement construit. Nous afficherons des informations sur le cluster:
root@redis1:~/redis/src
Pour tester une réplique spécifique, comme avec Redis Sentiel, vous pouvez utiliser la commande de réplication INFO:
root@redis1:~/redis/src
Essayons de créer plusieurs clés et vérifions que ces clés sont apparues sur les répliques:
192.168.9.51:6381> SET key1 test1 -> Redirected to slot [9189] located at 192.168.9.52:6382 OK 192.168.9.52:6382> SET key2 test2 -> Redirected to slot [4998] located at 192.168.9.51:6381 OK 192.168.9.51:6381> SET key3 test3 OK 192.168.9.51:6381>
Vérifiez sur M2:
root@redis2:/home/user
Et sur le M3:
root@redis3:/home/user
Nous désactiverons le nœud redis1 et vérifierons le fonctionnement de S1:
192.168.9.52:6382> CLUSTER NODES <b>182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave,fail d499af3672b3063c7239572ec311ad3160f280ae 1569509904727 1569509900000 4 connected</b> 485ffb786e9763955e6f10ffc59247690ad9bc11 <i>192.168.9.53:6381@16381 master</i> - 0 1569510017272 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569510018274 5 connected <b>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 master,fail - 1569509906731 1569509901721 1 connected</b> 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569510019275 3 connected 10923-16383 d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 myself,master - 0 1569510017000 2 connected 5461-10922
Nous voyons des informations sur l'échec de M1 et S2 et que S3 est passé en mode MASTER.
Vérifiez où les clés sont stockées:
192.168.9.52:6382> GET key1 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6381> GET key3 "test3" 192.168.9.53:6381>
Les clés qui étaient précédemment stockées sur redis1 sont désormais disponibles sur redis3.
Restaurez le fonctionnement du nœud redis1 et vérifiez l'état des nœuds M1 et S2:
192.168.9.53:6381> CLUSTER NODES <i>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 slave 485ffb786e9763955e6f10ffc59247690ad9bc11 0 1569511658217 7 connected 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave d499af3672b3063c7239572ec311ad3160f280ae 0 1569511657000 4 connected</i> d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 master - 0 1569511656000 2 connected 5461-10922 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569511656000 3 connected 10923-16383 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381@16381 myself,master - 0 1569511656000 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569511657216 5 connected
La santé de M1 et S2 a récupéré, mais maintenant M1 est en mode ESCLAVE.
Et les clés sont également sur le nœud redis3:
192.168.9.53:6383> GET key1 -> Redirected to slot [9189] located at 192.168.9.52:6382 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6383> GET key3 -> Redirected to slot [935] located at 192.168.9.53:6381 "test3"
Le cluster est configuré et la récupération Redis est testée.
Pour accéder aux services DirectumRX, vous devrez également configurer des proxys inverses, comme dans le cas de la configuration de Redis Sentiel.
Au lieu d'une conclusion
Cet article n'a pas envisagé une autre façon d'augmenter la tolérance aux pannes de Redis - en utilisant un gestionnaire de ressources de cluster tiers, par exemple,
Pacemaker . Dans ce cas, il sera possible de s'en sortir avec deux nœuds, mais il y a une forte probabilité de perte de données en cas d'urgence.
Pour un proxy inverse (dans ce cas, HAProxy), il est également souhaitable de fournir une tolérance aux pannes, mais ce problème dépassait également la portée de cet article. Si vous êtes intéressé par la rubrique, ces options de déploiement peuvent également être examinées dans des articles séparés avec un réglage pas à pas et un test des résultats.
Vous pouvez trouver les liens ci-dessous pour en savoir plus sur le sujet:
Tutoriel de cluster RedisDocumentation de Redis SentinelManuel de configuration HAProxy .