Приоритизация узлов Erlang

Question

Предполагая, что у меня есть кластер из n Erlang узлов, некоторые из которых могут быть в моей локальной сети, а другие могут быть подключены через WAN (то есть через Интернет), какие подходящие механизмы для обслуживания) различная доступность/поведение полосы пропускания (например, вызванная латентность) и b) узлы с различной вычислительной мощностью (или даже ограничения памяти, если на то пошло)?

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

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

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

(в том же смысле, можно было бы, вероятно, хотите, чтобы приоритеты локально работает узлы над тех, кто работает на других машинах)

Это было бы означало, мы надеемся, оптимизировать внутреннюю отправку работу, так что конкретные узлы обработки конкретных заданий.

Answer 1

Мы сделали что-то подобное этому, только на нашей внутренней LAN/WAN (например, в WAN, например, в Сан-Франциско в Лондон).Проблема сводились к комбинации этих факторов:

1. накладным расходам просто сделать удаленный вызов над локальным (внутренним) вызовом
2. задержка в сети к узлу (в зависимости от запроса/результата полезная нагрузка)
3. производительность удаленного узла
4. электронн мощность, необходимая для выполнения функции
5. ли пакетирование вызовов обеспечивает улучшение производительности, если был установлен совместно «статические» данные.

Для 1. мы предполагали, не над головой (это было незначительным по сравнению с другими)

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

для 3. мы измерили его на узле, и они были транслировать эту информацию (это изменяется в зависимости от нагрузки текущего активного на узле)

для 4 и 5. мы работали его эмпирически для данной партии

Затем звонящий решил получить минимальное решение для партии вызовов (в нашем случае ценой целой группы производных) и отпустил их на узлы партиями.

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

Answer 2

Проблема, о которой вы говорите, была решена различными способами в контексте грид-вычислений (например, см. Condor). Чтобы более подробно обсудить это, я думаю, необходима дополнительная информация (однородность решаемых задач, степень контроля над узлами (т. Е. Есть ли непредвиденная внешняя нагрузка и т. Д.?)).

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

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