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

Question

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

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

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

Как мне это сделать?

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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