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

Question

Estaba mirando los módulos de esclavos/piscinas y parece similar a lo que quiero, pero también parece que tengo un solo punto de falla en mi aplicación (si el nodo maestro cae).

El cliente tiene una lista de puertas de enlace (en aras de Fallback, todos hacen lo mismo) que aceptan conexiones, y una es elegida entre al azar por el cliente.Cuando el cliente conecta todos los nodos se examinan para ver cuál tiene la menor carga y luego la IP del servidor menos cargado se reenvía al cliente.Luego, el cliente se conecta a este servidor y todo se ejecuta allí.

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

¿Cómo haría esto?

Answer 1

No sé si todavía hay implementados estos módulos, pero lo que puedo decir es que el equilibrio de carga está sobrevalorado. Lo que puedo argumentar es que la colocación aleatoria de trabajos es la mejor opción a menos que conozca mucha más información sobre cómo llegará la carga en el futuro y, en la mayoría de los casos, realmente no lo sabe. Lo que escribiste:

  

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

¿Cómo sabe que todos los nodos menos cargados no serán los más cargados solo en los próximos ms? ¿Cómo sabe que todos esos nodos altamente cargados que no incluirá en la lista no dejarán caer la carga solo en los próximos ms? Realmente no puede saberlo a menos que tenga un caso muy raro.

Simplemente mida (o calcule) el rendimiento de su nodo y establezca la probabilidad de que el nodo sea elegido, depende de ello. Elija el nodo al azar, independientemente de la carga actual. Use esto como enfoque inicial. Cuando lo configura, puede intentar crear un algoritmo más sofisticado. Apuesto a que será 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 puede predecir la carga futura de la carga actual e histórica, pero debe usar el conocimiento sobre la probabilidad de duración de las tareas y la descomposición actual de La vida de la tarea. Este trabajo es muy 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. Vea las funciones pool: get_nodes o pool: get_node () para obtener una forma de obtener esas listas.

Puede permitir que el módulo del grupo se encargue de la gestión de los procesos (reinicio, supervisión y finalización del procesamiento) y utilizar algún otro módulo para redirigir de forma transparente las solicitudes al grupo de procesos. ¿Tal vez estabas buscando piscinas distribuidas? Será difícil alejarse del proceso maestro en erlang sin ir a los nodos distribuidos. Todo el sistema en ejecución es prácticamente un gran árbol de supervisión.

Answer 3

Recientemente recordé el módulo pg que le permite configurar grupos de procesos. Los mensajes enviados al grupo van a todos los procesos del grupo. Podría llevarte a medio camino hacia lo que quieres. tendría que escribir el código para decidir qué proceso maneja la solicitud real, pero obtendría un grupo sin un maestro que lo use.