Je me demandais pourquoi ZookePer a besoin de la majorité des machines de l'ensemble pour travailler du tout. Disons que nous avons un ensemble très simple de 3 machines - A, B, c.
Quand un échec, le nouveau dirigeant est élu - bien, tout fonctionne. Quand un autre meurt, disons B, le service n'est pas disponible. Est-ce que ça fait du sens? Pourquoi la machine C ne peut pas tout gérer seul, jusqu'à ce que A et B sont à nouveau en hausse?
Étant donné qu'une machine suffit à faire tout le travail (par exemple, l'ensemble de la machine unique fonctionne bien) ...
Y a-t-il une raison particulière pour laquelle Zookeper est conçu de cette manière? Existe-t-il un moyen de configurer ZookeEper qui, par exemple, l'ensemble est disponible toujours lorsque au moins un de N est en hausse?
Merci d'avance.
3 Réponses :
Zookeper est destiné à distribuer des choses de manière fiable. Si le réseau de systèmes devient segmenté, vous ne voulez pas que les deux moitiés fonctionnent de manière indépendante et potentiellement sorties de synchronisation, car lorsque l'échec est résolu, cela ne saura pas quoi faire. Si vous avez refuser de fonctionner lorsqu'il s'agit d'une majorité inférieure à une majorité, vous pouvez être assuré que lorsqu'un échec est résolu, tout reviendra de nouveau sans autre intervention.
Dans mon exemple, il n'y a pas de segmentation du système - seulement deux des 3 nœuds sont en panne. Si vous tuez des nœuds, cela ne signifie pas que le système est divisé en 2/3 / N plus petite une fois - il reste le même système avec moins de nœuds. Le système devrait être en panne, uniquement lorsque tous les nœuds sont. Même un seul nœud doit être capable de gérer des demandes de lecture / écriture des clients (et de l'arrière-plan informatique, il devrait continuer à essayer de renouer à d'autres nœuds). Le service ZOOODEPER avec 50% des nœuds de travail, sera en panne, a-t-il un sens? Si nous avons 100 machines, nous aurions toujours 50 nœuds pour tout gérer ... mais le système n'est pas disponible.
Remplacez le mot "tuer" avec "isoler" et vous verrez que dans le cas d'une défaillance du réseau (mais une machine toujours en marche), un nœud qui se trouve à ne pas faire partie de la majorité est logiquement déconnecté. La défaillance du réseau est un scénario mondial réel plus courant se comparer à l'arrêt de la machine.
@ Michałszkudlarek - La chose que vous ne réalisez pas est que les nœuds de zooêt ne savent pas si les nœuds manquants sont complètement en panne ou sont inaccessibles en raison de la défaillance du réseau. Ils se comportent donc comme s'il s'agissait d'une défaillance du réseau afin d'éviter des problèmes quand tout ce qui est faux est fixé.
La raison d'avoir un vote à la majorité est d'éviter un problème appelé "Split-cerveau".
Fondamentalement dans une défaillance réseau, vous ne voulez pas que les deux parties du système se poursuivent comme d'habitude. Vous voulez que vous continuiez et l'autre pour comprendre qu'il ne fait pas partie du cluster.
Il existe deux façons principales d'atteindre celui-ci pour contenir une ressource partagée, par exemple un disque partagé où le responsable détient une serrure, si vous pouvez voir le verrou, vous faites partie du cluster si vous ne le faites pas. re sortez. Si vous tenez la serrure, vous êtes le leader et si vous ne le faites pas. Le problème avec cette approche est que vous avez besoin de cette ressource partagée.
L'autre moyen d'empêcher un cérébral de scission est un nombre majoritaire, si vous obtenez suffisamment de votes, vous êtes le leader. Cela fonctionne toujours avec deux nœuds (pour un quorum de 3) où le chef dit que c'est le leader et l'autre noeud agissant en tant que "témoin" d'accord d'accord. Cette méthode est préférable car elle peut fonctionner dans une architecture de rien partagé et c'est ce que ZookePer utilise
Comme Michael mentionné, un nœud ne peut pas savoir si la raison pour laquelle il ne voit pas les autres nœuds du groupe est parce que ces nœuds sont en panne ou qu'il y a un problème de réseau - le pari sûr est de dire qu'il n'y a pas de quorum.
Regardons un exemple qui montre comment les choses peuvent aller mal si le quorum (la majorité des serveurs de course) est trop petit.
Disons que nous avons cinq serveurs et un quorum peuvent être un ensemble de deux serveurs. Dis maintenant que les serveurs S1 et S2 reconnaissent qu'ils ont répliqué une demande de création d'un Znode / Z. Le service retourne au client disant que le Znode a été créé. Supposons maintenant que les serveurs S1 et S2 soient partitionnés des autres serveurs et des clients pour une période arbitraire longue, avant d'avoir la possibilité de reproduire le nouveau Znode sur les autres serveurs. Le service dans cet état est en mesure de progresser car il existe trois serveurs disponibles et il n'entre vraiment que deux selon nos hypothèses, mais ces trois serveurs n'ont jamais vu le nouveau Znode / Z. Par conséquent, la demande de création / z n'est pas durable.
Avez-vous trouvé un moyen de modifier l'algorithme actuel de la sélection de leader? J'ai également trouvé un peu frustrant de payer 200K pour 3 machines censées éliminer le risque de non-défaillance unique de me retrouver fondamentalement dans la même position ...
@DCG Non, je n'ai même pas essayé de trouver une solution de contournement, car après avoir lu des réponses à ma question, j'ai compris une approche du zookeeper et il semble très logique.