Comment choisir un noeud maître parmi les noeuds tournant dans un cluster?
j'écris une pile infonuagique gérée (en plus des fournisseurs de cloud au niveau matériel comme EC2), et un problème auquel je vais bientôt faire face est:
comment plusieurs noeuds identiques décident-ils lequel d'entre eux devient un maître? (C'est-à-dire: pensez à 5 serveurs tournant sur EC2. L'un d'eux doit devenir un maître, et les autres doivent devenir des esclaves.)
j'ai lu une description de l'algorithme utilisé par MongoDB , et il semble assez compliqué, et cela dépend aussi d'un concept de vote - c'est-à-dire que deux noeuds laissés à eux-mêmes ne pourront rien décider. En outre, leur approche a un retard important avant de produire les résultats.
-
je me demande s'il y a des approches moins compliquées, qui embrassent les baisers? Ils sont largement utilisés, ou sont-ils risqués à adopter?
-
supposons que nous ayons déjà une liste de serveurs. Ensuite, nous pouvons juste élire celui qui est en place et a un adresse IP numériquement la plus petite. Quels sont les inconvénients de cette approche?
-
pourquoi L'algorithme de MongoDB est-il si compliqué?
ceci est un duplicata de Comment choisir un nouveau maître dans Cluster? , qui donne moins de détails et n'a pas reçu de réponse depuis 6 mois, donc je pense qu'il est approprié de commencer une nouvelle question.
(la pile sur laquelle je travaille est open-source, mais il est à un stade très précoce de développement Donc ne pas donner un lien ici.)
mise à jour: basé sur les réponses, j'ai conçu un algorithme de consensus simple, vous pouvez trouver une implémentation JavaScript (CoffeeScript) sur GitHub: majorité.js .
4 réponses
Chef de file de l'élection des algorithmes généralement considérer le split-brain comme un cas de défaut à l'appui. Si vous supposez que ce ne sont pas les noeuds qui échouent mais le réseau, vous pouvez courir dans le cas où tous les noeuds sont en place, mais ne parviennent pas à parler à l'autre. Alors, vous pouvez finir avec deux maîtres.
si vous pouvez exclure "split brain" de votre modèle de défaillance( i.e. si vous ne considérez que les échecs de noeud), votre algorithme (leader est celui avec le plus petit l'adresse) est très bien.
Use Apache ZooKeeper . Il résout exactement ce problème (et beaucoup plus).
si vos noeuds ont aussi besoin de s'entendre sur les choses et leur ordre total, vous pourriez vouloir considérer Paxos . C'est compliqué, mais personne n'a trouvé de solution plus facile pour un consensus distribué.
Moi comme cet algorithme:
- chaque noeud calcule le plus bas ID de noeud connu et envoie un vote pour le leadership à ce noeud
- si un noeud reçoit suffisamment de voix et que le noeud a également voté pour lui-même, alors il assume le rôle de leader et commence à publier l'état du cluster.
et au lien ci-dessous ont quelques beaucoup d'algorithme de maître-noeud d'élection dans le cluster: https://www.elastic.co/blog/found-leader-election-in-general#the-zen-way
peut également voir Raft-algorithme: https://raft.github.io