Premièrement, Sentinel n'est pas un équilibreur de charge ou un proxy pour Redis.
Deuxièmement, tous les échecs ne sont pas la mort de l'hôte. Parfois, le serveur se bloque brièvement, parfois un câble réseau se débranche, etc. Pour cette raison, il n'est pas recommandé d'exécuter Sentinel sur les mêmes hôtes que votre instance Redis. Si vous utilisez Sentinel pour gérer le basculement, moins de trois sentinelles s'exécutant sur des nœuds autres que votre maître Redis et vos esclaves posent problème.
Sentinel utilise un mécanisme de quorum pour voter sur un basculement et un esclave. Avec moins de deux sentinelles, vous courez le risque d'un cerveau divisé où deux serveurs Redis ou plus pensent qu'ils sont maîtres.
Imaginez le scénario dans lequel vous exécutez deux serveurs et exécutez Sentinel sur chacun. Si vous en perdez un, vous perdez la capacité de basculement fiable.
Les clients se connectent uniquement à Sentinel pour connaître les informations de connexion principales actuelles. Chaque fois que le client perd sa connectivité, il répète ce processus. Sentinel n'est pas un proxy pour Redis - les commandes pour Redis vont directement à Redis.
La seule raison fiable d'exécuter Sentinel avec moins de trois sentinelles est la découverte de service, ce qui signifie ne pas l'utiliser pour la gestion du basculement.
Considérez le scénario à deux hôtes :
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Si l'Hôte B perd temporairement la connectivité réseau avec l'Hôte A dans ce scénario, l'Hôte B se promeut maître. Vous avez maintenant :
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Tous les clients qui se connectent à Sentinel 2 seront informés que l'Hôte B est le maître, tandis que les clients qui se connectent à Sentinel 1 seront informés que l'Hôte A est le maître (ce qui, si vous avez vos Sentinelles derrière un équilibreur de charge, signifie la moitié de vos clients).
Ainsi, ce que vous devez exécuter pour obtenir une gestion de basculement fiable minimale acceptable est :
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Vos clients se connectent aux sentinelles et obtiennent le maître actuel de l'instance Redis (par nom), puis s'y connectent. Si le maître meurt, la connexion doit être interrompue par le client, après quoi le client se reconnectera à Sentinel et obtiendra les nouvelles informations.
La façon dont chaque bibliothèque cliente gère cela dépend de la bibliothèque.
Idéalement, les hôtes C, D et E se trouvent sur les mêmes hôtes à partir desquels vous vous connectez à Redis (c'est-à-dire l'hôte client). ou représentent un bon échantillonnage obtenu eux. L'objectif principal ici est de vous assurer que vous vérifiez d'où vous devez vous connecter à Redis. À défaut, placez-les dans le même DC/Rack/Région que les clients.
Si vous souhaitez que vos clients parlent à un équilibreur de charge, essayez si possible d'avoir vos Sentinels sur ces nœuds LB, en ajoutant des hôtes non LB supplémentaires si nécessaire pour obtenir un nombre impair de sentinelles> 2. Une exception à cela est si votre les hôtes clients sont dynamiques en ce sens que leur nombre est incohérent (ils augmentent pour le trafic, diminuent pour les périodes creuses, par exemple). Dans ce scénario, vous devez pratiquement exécuter vos Sentinels sur des hôtes non clients et non redis-server.
Notez que si vous faites cela, vous devrez alors écrire un démon qui surveille le canal Sentinel PUBSUB pour l'événement de commutateur principal pour mettre à jour le LB - que vous devez configurer pour ne parler qu'au maître actuel (n'essayez jamais de parler aux deux). C'est plus de travail à faire mais rend l'utilisation de Sentinel transparente pour le client - qui ne sait parler qu'à l'IP/Port LB.
