Redis sentinelle vs clustering
Je comprends que Redis Sentinel est un moyen de configurer la haute disponibilité entre plusieurs instances Redis. Comme je le vois, une instance Redis répond activement aux demandes des clients à un moment donné. Deux serveurs supplémentaires sont en attente (en attente d'une panne, l'un des serveurs peut de nouveau fonctionner).
- Est-ce un gaspillage de ressources?
- Existe-t-il un meilleur moyen d’utiliser pleinement les ressources disponibles?
- Redis regroupe-t-il une alternative à Redis sentinel?
J'ai déjà regardé la documentation redis pour sentinel et clustering , quelqu'un ayant de l'expérience peut-il expliquer s'il vous plaît.
UPDATE
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 est en cours d'exécution. L'application qui s'exécute 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 principal tombe en panne (le processus Redis tombe en panne ou en cas de défaillance de la machine), l’application de Jboss doit se connecter au serveur de cache esclave. Comment pourrais-je 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'avez besoin que de deux. Trois augmente votre redondance, mais n'est pas obligatoire. Si vous avez besoin de la redondance supplémentaire, il ne s'agit pas d'un gaspillage de ressources. Si vous n'avez pas besoin de redondance, exécutez simplement une seule instance Redis et appelez-la "bonne", car en exécuter plus serait "gaspillé".
Une autre raison pour exécuter deux esclaves serait de diviser les lectures. Encore une fois, si vous en avez besoin, alors ce ne serait pas une perte.
Quant à "Existe-t-il un meilleur moyen 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. Cela dit, si la quantité de données à stocker est "petite" et que le taux de commande n'est pas excessivement élevé, souvenez-vous qu'il n'est pas nécessaire de dédier un hôte à Redis.
Passons maintenant à "Redis regroupe-t-il une alternative à Redis sentinel?". Cela dépend entièrement de votre cas d'utilisation. Redis Cluster n'est pas une solution de haute disponibilité, c'est une solution pour plusieurs rédacteurs/plus gros que le ram. Si votre objectif est simplement HA, il ne vous conviendra probablement pas. Redis Cluster comporte des limitations, en particulier en ce qui concerne les opérations multi-clés. Il ne s’agit donc pas nécessairement d’une opération simple consistant à "utiliser uniquement un cluster".
Si vous pensez que le fait de disposer de trois hôtes exécutant Redis (et de trois exécutant Sentinel) est une perte de temps, il est probable que Cluster le sera encore plus, car il nécessite davantage de ressources.
Les questions que vous avez posées sont probablement trop générales et fondées sur les opinions pour survivre telles quelles. 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, je choisirais 3 sentinelles, une 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 laisser Sentinel gérer le basculement.
À partir de là, il suffit de connecter JBoss/Jedis pour utiliser Sentinel pour la gestion de ses informations et de sa connexion. Comme je ne les utilise pas, une recherche rapide révèle que Jedis a le support, il vous suffit de le configurer correctement. Quelques exemples que j'ai trouvés sont à Recherche d'un exemple de Jedis avec Sentinel et https://github.com/xetorthio/jedis/issues/725 qui parlent de JedisSentinelPool étant la route pour utiliser une piscine.
Lorsque Sentinel exécute un basculement, les clients seront déconnectés et Jedis gérera (devrait?) 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 permet de corriger certains autres points.
Tout d'abord, dire que Sentinel fournit un basculement sans HA est faux. Lorsque vous effectuez un basculement, vous bénéficiez d'une haute disponibilité avec l'avantage supplémentaire de la réplication de l'état de l'application. La différence est que vous pouvez avoir une haute disponibilité dans un système sans réplication (c'est une haute disponibilité mais ce n'est pas tolérant aux pannes).
Deuxièmement, exécuter une sentinelle sur le même ordinateur que son instance redis cible n’est pas une "mauvaise configuration": si vous perdez votre sentinelle, votre instance redis ou l’ensemble de la machine, les résultats sont identiques. C'est probablement pourquoi chaque exemple de telles configurations montre que les deux s'exécutent sur le même ordinateur.
Ce n'est pas une réponse directe à votre question, mais pensez que c'est une information utile pour les débutants Redis, comme moi. Cette question apparaît également comme le premier lien de Google lors de la recherche sur "Redis cluster vs sentinel".
Redis Sentinel est le nom de la solution haute disponibilité Redis ... Cela 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 l'instance ne fonctionne pas correctement.
Tiré du Redis Sentinel Design Draft 1.
Ce n'est pas évident quand vous découvrez Redis et que vous implémentez une solution de basculement. Les documentations officielles sur sentinelle et regroupement ne se comparent pas, il est donc difficile de choisir la bonne méthode sans lire des tonnes de documentations.
C'est ce que j'ai compris après m'être cogné la tête avec la documentation.
Sentinel est un type de solution de secours automatique dans laquelle les esclaves sont répliqués et prêts à être promus à tout moment. Cependant, il ne supportera pas les écritures multi-nœuds. Les esclaves peuvent être configurés pour les opérations de lecture. Il n'est PAS vrai que Sentinel ne fournisse pas de haute disponibilité, il présente 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, travaillant au-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 avez deux fragments actifs disponibles sur le maître et les esclaves. Si vous connaissez le sharding en mongo ou en elasticsearch, il sera facile à rattraper.
Redis peut fonctionner en cluster partitionné (avec de nombreux maîtres et esclaves de ces maîtres) ou en mode instance unique (un seul maître avec des esclaves de réplica).
Le lien ici dit:
Lors de l'utilisation de Redis en mode d'instance unique, dans lequel un seul serveur Redis gère la totalité 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 lui-même la disponibilité et ne nécessite aucun composant supplémentaire.
Donc, HA peut être assuré dans les 2 scénarios mentionnés. J'espère que cela efface les doutes. Le cluster Redis et les sentinelles ne sont pas une alternative. Ils sont simplement utilisés pour assurer la haute disponibilité dans différents cas de maître partitionné ou non partitionné.
Redis Sentinel effectue la réplication des réplicas lorsqu’ils constatent la défaillance d’un maître. Vous voulez généralement un nombre impair de nœuds sentinelles. Pour l'exemple d'un maître et d'un réplica, 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 prend en charge la modification des paramètres de configuration maître/réplica sur vos nœuds afin que la promotion et la synchronisation se déroulent dans le bon ordre et que vous n'écrasiez pas les données en activant un ancien maître défaillant contenant désormais des données plus anciennes.
Une fois que vos noeuds sentinelles sont configurés pour effectuer des basculements, vous devez vous assurer que vous pointez sur la bonne instance. Voir un exemple de configuration HAProxy pour cela . HAProxy effectue des contrôles de santé et pointe vers le nouveau maître en cas de défaillance.
Le regroupement vous permettra d’évoluer horizontalement et vous aidera à gérer des charges élevées. Il faut un peu de travail pour installer et configurer à l’avance.
Il existe un fork open source de Redis, "KeyDB", qui élimine le besoin de nœuds sentinelles avec une option de réplica actif. Cela permet au nœud de réplique d'accepter les lectures et les écritures. Lorsqu'un basculement se produit, HAProxy arrête les lectures/écritures avec le nœud en échec 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 important, vous n’avez pas besoin d’une configuration spéciale pour diriger les lectures sur le nœud de réplique et les lectures/écritures sur le maître. Voir exemple de réplication active ici . KeyDB est également multi-thread, ce qui peut, pour certaines applications, être une alternative au clustering, mais dépend vraiment de vos besoins.
Il existe également un exemple de configuration de mise en cluster manuelle et avec le outil de création de cluster . Ce sont les mêmes étapes si vous utilisez Redis (remplacez 'keydb' par 'redis' dans l'instruction)