¿Cómo elegir un nodo maestro entre los nodos que se ejecutan en un clúster?

Estoy escribiendo una pila de nube administrada (además de proveedores de nube a nivel de hardware como EC2), y un problema que enfrentaré pronto es:

¿Cómo deciden varios nodos idénticos cuál de ellos se convierte en maestro? (Es decir, piense en 5 servidores que se ejecutan en EC2. Uno de ellos tiene que convertirse en un amo, y otros tienen que convertirse en esclavos.)

Leí una descripción de el algoritmo utilizado por MongoDB , y parece bastante complicado, y también depende de un concepto de votos-es decir, dos nodos si te quedas solo no podrás decidir nada. También su enfoque tiene un retraso significativo antes de que produzca los resultados.

  1. Me pregunto si hay algún enfoque menos complicado, de abrazo de BESO? Se utilizan ampliamente, o son riesgosos para adoptar?

  2. Supongamos que ya tenemos una lista de servidores. Entonces podemos elegir la que está arriba y tiene una dirección IP numéricamente más pequeña. ¿Cuáles son las desventajas de este enfoque?

  3. Por qué es el algoritmo de MongoDB tan complicado?

Este es un duplicado de ¿Cómo elegir un nuevo Maestro en el clúster?, que da menos detalles y no ha sido contestada durante 6 meses, por lo que creo que es apropiado comenzar una nueva pregunta.

(La pila en la que estoy trabajando es de código abierto, pero está en una etapa muy temprana de desarrollo, así que no estoy dando un enlace aquí.)

ACTUALIZACIÓN: basado en las respuestas, he diseñado un algoritmo de consenso simple, puede encontrar una implementación de JavaScript (CoffeeScript) sobre GitHub: mayoría.js .

Author: Community, 2010-12-24
Source

4 answers

Los algoritmos de elección de líderes típicamente consideran el cerebro dividido como un caso de falla para apoyar. Si asume que no son los nodos los que fallan, sino la red, puede encontrarse con el caso en el que todos los nodos están activados, pero no pueden comunicarse entre sí. Entonces, usted puede terminar con dos maestros.

Si puede excluir "cerebro dividido" de su modelo de fallas (es decir, si considera solo fallas de nodo), su algoritmo (leader es el que tiene la dirección más pequeña) está bien.

 14
Author: Martin v. Löwis,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-12-23 23:30:00

Use Apache ZooKeeper. Resuelve exactamente este problema (y muchos más).

 6
Author: Spike Gronim,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-03-12 18:06:46

Si sus nodos también necesitan ponerse de acuerdo sobre las cosas y su orden total, es posible que desee considerar Paxos. Es complicado, pero a nadie se le ha ocurrido una solución más fácil para el consenso distribuido.

 3
Author: Nick Johnson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-12-24 02:22:12

Me gusta este algoritmo:

  • Cada nodo calcula el id de nodo más bajo conocido y envía un voto por liderazgo a este nodo
  • Si un nodo recibe suficientes votos y el nodo también votó por sí mismo, entonces asume el papel de líder y comienza a publicar el estado del clúster.

Y en el enlace de abajo tienen algunos muchos algoritmo de elección master-node en clúster: https://www.elastic.co/blog/found-leader-election-in-general#the-zen-way

También puede ver Balsa-algoritmo: https://raft.github.io

 2
Author: Ivan Zhirkov,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-11-06 15:56:45