Используя Erlang, как мне распределить нагрузку по кластеру?

Question

Я смотрел на модули slave / pool и похоже на то, что я хочу, но также кажется, что у меня есть единственная точка отказа в моем приложение (если главный узел выходит из строя).

У клиента есть список шлюзов (ради отступления - все делают то же самое), которые принимают соединения, и один выбирается из случайно клиентом. Когда клиент соединяется, все узлы исследуется, чтобы увидеть, какая из них имеет наименьшую нагрузку, а затем IP-адрес наименее загруженный сервер пересылается обратно клиенту. Клиент тогда подключается к этому серверу и там все выполняется.

Итак, я хочу, чтобы все узлы действовали как шлюзы и фактически обрабатывать запросы клиентов. Балансировка нагрузки выполняется только тогда, когда клиент изначально подключается - все актуальные пакеты и обрабатываются на "домашний" узел клиента.

Как бы я это сделал?

Answer 1

Я не знаю, реализованы ли эти модули, но что я могу сказать, баланс нагрузки переоценен. Что я могу утверждать, так это то, что случайное размещение рабочих мест является лучшим выбором, если вы не знаете гораздо больше информации о том, как будет загружаться в будущем, а в большинстве случаев вы действительно не знаете. Что вы написали:

Когда клиент подключается, все узлы проверяются на предмет наименьшей нагрузки, а затем IP-адрес наименее загруженного сервера пересылается обратно клиенту.

Откуда вы знаете, что все эти наименее загруженные узлы не будут загружены с максимальной загрузкой только в следующие мс? Откуда вы знаете, что все эти высоконагруженные узлы, которые вы не включите в список, не сбросят нагрузку только в следующие мс? Вы действительно не можете знать это, если у вас нет очень редкого случая.

Просто измерьте (или вычислите) производительность вашего узла и установите вероятность выбора узла в зависимости от этого. Выберите узел случайно, независимо от текущей нагрузки. Используйте это в качестве начального подхода. Когда вы установите его, вы можете попытаться создать более сложный алгоритм. Могу поспорить, что это будет очень тяжелая работа, чтобы победить этот первоначальный подход. Поверь мне, очень тяжело.

Редактировать : Чтобы быть более понятным в одной тонкой детали, я настоятельно утверждаю, что вы не можете предсказать будущую нагрузку из текущей и исторической нагрузки, но вы должны использовать знания о вероятности длительности задач и текущей декомпозиции задач продолжительность жизни. Эту работу очень трудно достичь.

Answer 2

Целью дерева контроля является управление процессами, которые не обязательно должны пересылать запросы. Нет причин, по которым вы не могли бы использовать другой код для отправки запросов непосредственно членам списка доступных процессов. Посмотрите функции pool: get_nodes или pool: get_node () для одного способа получения этих списков.

Вы можете разрешить модулю пула управлять процессами (перезапуск, мониторинг и обработка уничтожения) и использовать какой-то другой модуль для прозрачного перенаправления запросов в пул процессов. Может быть, вы искали распределенные пулы, хотя? Будет трудно уйти от мастер-процесса в эрланге без перехода к распределенным узлам. Вся работающая система представляет собой одно большое дерево наблюдения.

Answer 3

Я недавно вспомнил модуль pg, который позволяет вам настраивать группы процессов. сообщения, отправленные в группу, поступают в каждый процесс в группе. Это может привести вас к тому, что вы хотите. вам нужно написать код, чтобы решить, какой процесс будет обрабатывать запрос в реальном времени, но вы получите пул без мастера, использующего его.