Usando Erlang, ¿cómo debo distribuir la carga entre un clúster?

Question

Estaba viendo los módulos esclavo/piscina y parece similar a lo que I quiero, pero también parece que tengo un único punto de falla en mi aplicación (si el nodo maestro se cae).

El cliente tiene una lista de puertas de enlace (por el bien de repliegue - todos lo hacen la misma cosa), que acepte conexiones, y uno se elige entre al azar por el cliente. Cuando el cliente se conecta todos los nodos son examinados para ver cuál tiene la menor carga y luego la IP del servidor menos cargado se reenvía al cliente. El cliente entonces se conecta a este servidor y todo se ejecuta allí.

En resumen, quiero que todos los nodos actúen como ambas puertas de enlace y para procesar realmente las solicitudes del cliente . El equilibrio de carga solo se realiza cuando el cliente se conecta inicialmente, todos los paquetes reales y se procesa en el nodo "inicio" del cliente.

¿Cómo voy a hacer esto?

Answer 1

No sé si todavía hay módulos implementados, pero lo que puedo decir es que el balance de carga está sobrevalorado. Lo que sí puedo argumentar es que la mejor opción es la asignación aleatoria de puestos de trabajo, a menos que se sepa mucha más información de cómo vendrá la carga en el futuro y en la mayoría de los casos, realmente no. Lo que escribió:

Cuando el cliente se conecta, se examinan todos los nodos para ver cuál tiene la menor carga y luego se reenvía la dirección IP del servidor con menos carga al cliente.

¿Cómo se sabe que todos los nodos menos cargados no serán cargados más alto en el próximo ms? ¿Cómo sabes que todos esos nodos de alta carga que no incluirás en la lista no dejarán de cargar solo en el próximo ms? Realmente no puedes saberlo a menos que tengas un caso muy raro.

Simplemente mida (o calcule) el rendimiento de su nodo y configure la probabilidad del nodo que se elija dependerá de ello. Elija el nodo al azar independientemente de la carga actual. Use esto como un acercamiento inicial. Cuando lo configura, puede intentar inventar algún algoritmo más sofisticado. Apuesto a que será un trabajo muy difícil superar este enfoque inicial. Confía en mí, muy duro.

Editar: Para ser más claro en un detalle sutil, sostengo firmemente que no se puede predecir la carga futura de carga actual e histórico, sino que debe utilizar el conocimiento acerca de las tareas duraciones probabilidad y la descomposición actual de la vida de la tarea. Este trabajo es tan difícil de lograr.

Answer 2

El propósito de un árbol de supervisión es administrar los procesos, no necesariamente reenviar solicitudes. No hay ninguna razón por la que no pueda usar un código diferente para enviar solicitudes directamente a los miembros de la lista de procesos disponibles. Consulte las funciones pool: get_nodes o pool: get_node() para obtener una forma de obtener esas listas.

Puede dejar que el módulo de grupo maneje la administración de los procesos (reiniciar, supervisar y eliminar el procesamiento) y usar algún otro módulo para redirigir las solicitudes al grupo de procesos. Aunque tal vez estabas buscando piscinas distribuidas? Será difícil alejarse del proceso maestro en erlang sin ir a nodos distribuidos. Todo el sistema en ejecución es más o menos un gran árbol de supervisión.

Answer 3

Hace poco recordé el módulo pg que le permite configurar grupos de procesos. los mensajes enviados al grupo van a cada proceso en el grupo.Puede que te lleve en parte hacia lo que quieres. Tendría que escribir el código para decidir qué proceso maneja la solicitud de real, pero obtendría un grupo sin un maestro que lo utilizara.