Aperçu

Redis est un magasin de structure de données en mémoire open-source qui peut être utilisé en tant que courtier de messages, cache et base de données clé-valeur. Il supporte plusieurs structures de données: hachages, listes, ensembles, ensembles triés, images bitmap, index géospatiaux, hyperloglogs, etc.

La particularité de Redis est qu’elle peut être considérée à la fois comme un magasin et comme un cache. Il est conçu de manière à ce que les données soient modifiées et / ou lues à partir de la mémoire principale de l’ordinateur.

Redis fournit, entre autres, une haute disponibilité via: Redis Sentinel, et partitionnement automatique, via Redis Cluster. De plus, Redis dispose d'un mécanisme de réplication qui permet aux instances esclaves d'être des copies exactes des instances maîtres. L'esclave se reconnectera automatiquement au maître chaque fois que le lien sera rompu et son objectif sera d'en être une copie exacte.

Redis Sentinel offrant une haute disponibilité, Redis peut gérer les pannes automatiquement sans intervention humaine dans de nombreux cas, mais fournit également d'autres tâches telles que la surveillance, les notifications et joue le rôle de fournisseur de configuration pour les clients.

Mais, Que se passe-t-il lorsque Sentinel détecte un serveur Redis comme étant en panne? Nous découvrirons dans cet article comment créer un service virtuel hautement disponible complet pour Redis.

Notez que cette configuration peut également être effectuée même si votre serveur Redis n'utilise pas Sentinel pour la surveillance.

Environnement d'équilibrage de charge Redis

Le scénario que nous souhaitons atteindre dans cet article est présenté dans le diagramme ci-dessous.

Redis Sentinel vérifie l'état de tous les nœuds Redis et modifie le rôle du serveur Redis une fois qu'une erreur est détectée.

L'équilibreur de charge vérifie également l'état, mais il le fait périodiquement toutes les quelques secondes. Il se peut que Sentinel détecte le problème mais que l'équilibrage de charge prenne quelques secondes à se réaliser. Cela pourrait amener l'équilibreur à envoyer des demandes au mauvais maître, celui qui vient d'échouer mais qui a été basculé par Sentinel.

Zevenet offre un moyen de résoudre ce problème, la ferme L4 effectue des vérifications périodiquement. D'autre part, il y a aussi le flux passé au backend qui ne contient aucune vérification précédente. Lorsque le gardien de la ferme se rend compte que le backend ne répond pas, il déclenche l'alarme, indiquant que le flux ne devrait pas suivre cette direction.

En tenant compte de cela, nous avons d’une part les chèques et de l’autre les demandes. Si la vérification échoue, le flux est immédiatement envoyé à un autre noeud. Même les pétitions en cours sont redirigées vers un autre nœud en ligne. Ceci sera expliqué plus en détail dans la configuration.

Redis configuration de l'équilibrage de charge

Avant de configurer la batterie, nous devons avoir une adresse IP virtuelle. Pour y parvenir, allez à Réseau> Interfaces virtuelles. Puis cliquez sur Action> Créer une interface virtuelle. Ensuite, sélectionnez Interface parent, Nom de l'interface virtuelle ainsi que ses adresse IP:

Ensuite, pour le serveur virtuel Redis, nous devons créer une batterie L4xNAT. Pour cela, allez à LSLB> Fermes, puis cliquez sur Action et Créer une ferme.

Une fois les paramètres initiaux définis, cliquez sur Création. Ensuite, allez au Avancé onglet et assurez-vous que le type de protocole est TCP.

Ensuite, allez à Prestations. Backends et Farm Guardian seront configurés ici pour un contrôle de santé avancé. Tout d'abord trouver le Backends section, et cliquez sur Actions> Ajouter le backend comme indiqué ci-dessous:

Surveillance Redis et vérification de l'état de santé avancé

Enfin, les vérifications Farm Guardian sont nécessaires pour nous assurer que nous utilisons toujours le nœud en ligne, comme expliqué précédemment. Pour cela, nous devons configurer les éléments suivants en tant que commande Farm Guardian:

check_tcp -E -H HOST -p PORT -s 'info replication\r\n' -e role:master -t 3

Où HÔTE et PORT sera remplacé par l'adresse IP et le port du serveur Redis de chaque backend. La commande réplication d'informations obtiendra les informations du serveur Redis afin de vérifier quel maître est actif, les connexions ne seront redirigées vers le serveur que si le rôle du maître est présenté, dès que Sentinel modifie le rôle, l'équilibreur de charge détecte le changement et le Redis le serveur sera marqué comme étant en panne. Le drapeau -t correspond au nombre de secondes pendant lesquelles Farm Guardian attend une réponse du serveur Redis, puis si le délai est atteint sans réponse, le serveur Redis est marqué comme étant en panne. D'autre part, une fois que l'état du serveur Redis est restauré, il redevient actif.

Mais avant de modifier le Farm Guardian pour cette ferme, allez à Surveillance> Farmguardian puis cliquez sur Action> Créer Farmguardian.

Choisissez un nom descriptif pour votre nouveau vérificateur d'intégrité Redis Sentinel, par exemple, check_redis_master comme dans l'exemple, choisissez maintenant check_tcp dans le déposé Farmguardian à copier et cliquez sur Création comme indiqué ci-dessous.

Enfin, copiez la commande mentionnée ci-dessus dans le Command paramètre et effectuez la configuration comme indiqué ci-dessous.

Cliquez sur Envoyer.

Sélectionnez maintenant cette nouvelle vérification d’état de santé avancée Farm Guardian dans le service virtuel Redis. Revenir à LSLB> Fermes, à la ferme créée avec le nom RedisFarm, Prestations languette. Enfin, sélectionnez le check_redis_master commande vient d'être créée sous Bilans de santé pour le backend.

Cliquez sur Mises à jour la ferme et maintenant Redis seront pleinement disponibles.

Références

https://redis.io/topics/sentinel
https://redis.io/topics/cluster-tutorial