Redis sentinel vs clustering

Je comprends que redis sentinel est un moyen de configurer HA (haute disponibilité) entre plusieurs instances redis. Comme je le vois, il existe une instance de redis servant activement les demandes des clients à un moment donné. Il y a deux serveurs supplémentaires en attente (en attente d'une panne, donc l'un d'eux peut être à nouveau en action).

• Est-ce un gaspillage de ressources?
• Existe-t-il une meilleure façon d'utiliser pleinement les ressources disponibles?
• Redis clustering est-il une alternative à Redis sentinel?

J'ai déjà consulté la documentation Redis pour sentinel et clustering , quelqu'un ayant de l'expérience peut-il expliquer s'il vous plaît.

METTRE À JOUR

D'ACCORD. Dans mon scénario de déploiement réel, j'ai deux serveurs dédiés à redis. J'ai un autre serveur que mon serveur Jboss exécute. L'application exécutée dans Jboss est configurée pour se connecter au serveur maître redis (M).

Scénario de basculement

Idéalement, je pense que lorsque le serveur de cache maître échoue (que le processus Redis tombe en panne ou que la machine échoue), l'application dans Jboss doit se connecter au serveur de cache esclave. Comment configurer les serveurs Redis pour y parvenir?

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1

Tout d'abord, parlons sentinelle.

Sentinel gère le basculement, il ne configure pas Redis pour HA. C'est une distinction importante. Deuxièmement, le diagramme que vous avez publié est en fait une mauvaise configuration - vous ne voulez pas exécuter Sentinel sur le même nœud que les nœuds Redis qu'il gère. Lorsque vous perdez cet hôte, vous perdez les deux.

Quant à "Est-ce un gaspillage de ressources?" cela dépend de votre cas d'utilisation. Vous n'avez pas besoin de trois nœuds Redis dans cette configuration, vous n'en avez besoin que de deux. Trois augmente votre redondance, mais n'est pas obligatoire. Si vous avez besoin d'une redondance supplémentaire, ce n'est pas un gaspillage de ressources. Si vous n'avez pas besoin de redondance, exécutez simplement une seule instance Redis et appelez-la bien - car en exécuter plus serait «gaspillé».

Une autre raison pour exécuter deux esclaves serait de fractionner les lectures. Encore une fois, si vous en avez besoin, ce ne serait pas un gaspillage.

Quant à "Y a-t-il une meilleure façon d'utiliser pleinement les ressources disponibles?" nous ne pouvons pas répondre à cela car cela dépend beaucoup trop de votre scénario et de votre code spécifiques. Cela dit, si la quantité de données à stocker est "petite" et que le taux de commande n'est pas excessivement élevé, rappelez-vous que vous n'avez pas besoin de dédier un hôte à Redis.

Maintenant pour "Redis clustering est-il une alternative à Redis sentinel?". Cela dépend vraiment entièrement de votre cas d'utilisation. Redis Cluster n'est pas une solution HA - il s'agit d'une solution à plusieurs graveurs / plus grande que la RAM. Si votre objectif n'est que HA, il ne vous conviendra probablement pas. Redis Cluster est livré avec des limitations, en particulier en ce qui concerne les opérations multi-clés, ce n'est donc pas nécessairement une opération simple "juste utiliser le cluster".

Si vous pensez qu'avoir trois hôtes exécutant Redis (et trois sentinelles exécutant) est un gaspillage, vous tiendrez probablement Cluster encore plus car il nécessite plus de ressources.

Les questions que vous avez posées sont probablement trop larges et basées sur des opinions pour survivre telles qu'elles sont écrites. Si vous avez un cas / problème spécifique sur lequel vous travaillez, veuillez le mettre à jour afin que nous puissions vous fournir une assistance et des informations spécifiques.

Mise à jour pour les détails:

Pour une bonne gestion du basculement dans votre scénario, j'irais avec 3 sentinelles, une fonctionnant sur votre serveur JBoss. Si vous avez 3 nœuds JBoss, choisissez-en un sur chacun. J'aurais un pod Redis (maître + esclave) sur des nœuds séparés et laisserais sentinel gérer le basculement.

À partir de là, il s'agit de câbler JBoss / Jedis pour utiliser Sentinel pour sa gestion des informations et des connexions. Comme je ne les utilise pas, une recherche rapide indique que Jedis a le support pour cela, il vous suffit de le configurer correctement. Quelques exemples que j'ai trouvés sont à la recherche d'un exemple de Jedis avec Sentinel et https://github.com/xetorthio/jedis/issues/725 qui parlent d' JedisSentinelPoolêtre la route pour utiliser un pool.

Lorsque Sentinel exécute un basculement, les clients sont déconnectés et Jedis va (devrait?) Gérer la reconnexion en demandant aux Sentinels qui est le maître actuel.

La recommandation, partout, est de commencer avec un nombre impair d'instances, sans utiliser deux ou un multiple de deux. Cela a été corrigé, mais corrigeons d'autres points.

Tout d'abord, dire que Sentinel fournit un basculement sans HA est faux. Lorsque vous avez un basculement, vous disposez d'une haute disponibilité avec l'avantage supplémentaire de répliquer l'état de l'application. La différence est que vous pouvez avoir HA dans un système sans réplication (c'est HA mais ce n'est pas tolérant aux pannes).

Deuxièmement, exécuter une sentinelle sur la même machine que son instance redis cible n'est pas une "mauvaise configuration": si vous perdez votre sentinelle, ou votre instance redis, ou toute la machine, les résultats sont les mêmes. C'est probablement pourquoi chaque exemple de telles configurations montre que les deux fonctionnent sur la même machine.

Ce n'est pas une réponse directe à votre question, mais pensez, ce sont des informations utiles pour les débutants Redis, comme moi. Cette question apparaît également comme le premier lien dans google lors de la recherche du "cluster Redis vs sentinel".

Redis Sentinel est le nom de la solution de haute disponibilité Redis ... Il n'a rien à voir avec Redis Cluster et est destiné à être utilisé par des personnes qui n'ont pas besoin de Redis Cluster, mais simplement un moyen d'effectuer un basculement automatique lorsqu'un maître l'instance ne fonctionne pas correctement.

Tiré du projet de conception Redis Sentinel 1.3

Ce n'est pas évident lorsque vous êtes nouveau sur Redis et que vous implémentez une solution de basculement. Les documentations officielles sur la sentinelle et le clustering ne se comparent pas, il est donc difficile de choisir la bonne manière sans lire des tonnes de documentations.

C'est ce que je comprends après m'être cogné la tête tout au long de la documentation.

Sentinel est une sorte de solution de secours automatique où les esclaves sont répliqués et prêts à être promus à tout moment. Cependant, il ne prend pas en charge les écritures multi-nœuds. Les esclaves peuvent être configurés pour les opérations de lecture. Ce n'est PAS vrai que Sentinel ne fournira pas HA, il possède toutes les fonctionnalités d'un cluster actif-passif typique (bien que ce ne soit pas le bon terme à utiliser ici).

Le cluster Redis est plus ou moins une solution distribuée, fonctionnant par-dessus des fragments. Chaque bloc de données est distribué entre les nœuds maîtres et esclaves. Un facteur de réplication minimum de 2 garantit que vous disposez de deux fragments actifs disponibles sur le maître et les esclaves. Si vous connaissez le sharding dans Mongo ou Elasticsearch, ce sera facile à rattraper.

Redis peut fonctionner en cluster partitionné (avec de nombreux maîtres et esclaves de ces maîtres) ou en mode d'instance unique (maître unique avec répliques d'esclaves).
Le lien ici dit:

Lors de l'utilisation de Redis en mode d'instance unique, dans lequel un seul serveur Redis gère l'ensemble de la base de données non partitionnée, Redis Sentinel est utilisé pour gérer sa disponibilité

Il dit aussi:

Un cluster Redis, dans lequel les données sont partitionnées entre plusieurs instances principales, gère la disponibilité par lui-même et ne nécessite aucun composant supplémentaire.

Ainsi, HA peut être assuré dans les 2 scénarios mentionnés. J'espère que cela dissipe les doutes. Le cluster Redis et les sentinelles ne sont pas alternatifs. Ils sont simplement utilisés pour assurer la haute disponibilité dans différents cas de maître partitionné ou non partitionné.

Redis Sentinel effectue le basculement en promouvant les réplicas lorsqu'ils voient qu'un maître est en panne. Vous voulez généralement un nombre impair de nœuds sentinelles. Pour l'exemple d'un maître et d'une réplique, 3 sentinelles doivent être utilisées afin qu'il puisse y avoir un consensus sur la décision. Idéalement, la 3ème sentinelle est sur un 3ème serveur afin que la décision ne soit pas biaisée (en fonction de l'échec). Sentinel se charge de modifier les paramètres de configuration du maître / réplica sur vos nœuds afin que la promotion et la synchronisation se produisent dans le bon ordre et que vous n'écrasiez pas les données en apportant un ancien maître défaillant qui contient désormais des données plus anciennes.

Une fois que vos nœuds sentinelles sont configurés pour effectuer des basculements, vous devez vous assurer que vous pointez vers la bonne instance. Voir un exemple de configuration HAProxy pour cela . HAProxy effectue des vérifications de l'état et pointera vers le nouveau maître en cas de panne.

Le regroupement vous permettra de vous mettre à l'échelle horizontalement et peut aider à gérer des charges élevées. La mise en place et la configuration à l'avance demandent un peu de travail.

Il existe un fork open source de Redis, «KeyDB», qui a éliminé le besoin de nœuds sentinelles avec une option de réplique active. Cela permet au nœud de réplique d'accepter les lectures et les écritures. Lors d'un basculement, HAProxy arrête les lectures / écritures avec le nœud défaillant et utilise uniquement le nœud actif restant qui est déjà synchronisé. L'horodatage permet aux nœuds défaillants de se rejoindre automatiquement et de se resynchroniser sans perdre de données lorsqu'ils reviennent en ligne. La configuration est simple et pour un trafic plus élevé, vous n'avez pas besoin de configuration initiale spéciale pour diriger les lectures vers le nœud de réplique et les lectures / écritures vers le maître. Voir l'exemple de réplication active ici . KeyDB est également multithread, ce qui pour certaines applications peut être une alternative au clustering, mais dépend vraiment de vos besoins.

Il existe également un exemple de configuration manuelle du clustering et avec l' outil create-cluster . Ce sont les mêmes étapes si vous utilisez Redis (remplacez 'keydb' par 'redis' dans l'instruction)

Informations supplémentaires aux réponses ci-dessus

Cluster Redis

• L'un des principaux objectifs du cluster Redis est de répartir de manière égale / uniforme votre charge de données par partitionnement

• Redis Cluster n'utilise pas de hachage cohérent, mais une forme différente de partitionnement où chaque clé fait partie de ce que l'on appelle un emplacement de hachage

• Il y a 16384 emplacements de hachage dans Redis Cluster, chaque nœud d'un cluster Redis est responsable d'un sous-ensemble des emplacements de hachage, donc, par exemple, vous pouvez avoir un cluster avec 3 nœuds, où:

  Le nœud A contient des emplacements de hachage de 0 à 5500, le nœud B contient des emplacements de hachage de 5501 à 11000, le nœud C contient des emplacements de hachage de 11001 à 16383

Cela nous permet d'ajouter et de supprimer facilement des nœuds dans le cluster. Par exemple, si nous voulons ajouter un nouveau nœud D, nous devons déplacer un emplacement de hachage des nœuds A, B, C vers D

• Le cluster Redis prend en charge la structure maître-esclave, vous pouvez créer des esclaves A1, B1, C2 avec le maître A, B, C lors de la création d'un cluster, donc lorsque le maître B descend, l'esclave B1 est promu comme maître

Vous n'avez pas besoin d'une gestion de basculement supplémentaire lors de l'utilisation de Redis Cluster et vous ne devez absolument pas pointer les instances Sentinel vers l'un des nœuds du cluster.

Donc, en termes pratiques, qu'obtenez-vous avec Redis Cluster?

1.La possibilité de diviser automatiquement votre ensemble de données entre plusieurs nœuds.

La possibilité de poursuivre les opérations lorsqu'un sous-ensemble de nœuds rencontre des pannes ou ne parvient pas à communiquer avec le reste du cluster.

Redis Sentinel

• Redis prend en charge plusieurs esclaves répliquant des données à partir d'un nœud maître.
• Cela fournit une sauvegarde des données dans le nœud maître.
• Redis Sentinel est un système conçu pour gérer le maître et l'esclave. Il fonctionne comme un programme séparé. Le nombre minimum de sentinelles requis dans un système idéal est de 3. Ils communiquent entre eux et s'assurent que le maître est vivant, sinon en vie, ils promouvront l'un des esclaves en tant que maître, donc plus tard, lorsque le nœud mort tournera, ce sera agissant en tant qu'esclave pour le nouveau maître
• Le quorum est configurable. Fondamentalement, c'est le nombre de sentinelles qui doivent s'entendre car le capitaine est en panne. N / 2 +1 devrait être d'accord. N est le nombre de nœuds dans le pod (notez que cette configuration est appelée un pod et n'est pas un cluster)

Donc, en termes pratiques, qu'obtenez-vous avec Redis Sentinel?

Il s'assurera que le maître est toujours disponible (si le maître tombe en panne, l'esclave sera promu comme maître)

Référence :

https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/

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