Насколько масштабируемо распределяется Erlang?

У Erlang много историй успеха о запуске параллельных агентов, например. миллионы одновременных чатов Facebook. Это миллионы агентов, но, конечно, это не миллионы процессоров по сети. У меня возникли проблемы с поиском показателей того, насколько хорошо Erlang масштабируется, когда масштабирование является "горизонтальным" по LAN/WAN.

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

Я понимаю (как новичок в Erlang, а это значит, что я могу быть абсолютно неправ), что узлы Erlang пытаются подключиться друг к другу и быть в курсе друг друга, в результате чего сеть соединений точка-точка N ^ 2. Предполагая, что часть A будет работать не только с N = 10K, может ли Erlang быть легко сконфигурирован (с использованием готовой конфигурации или тривиального шаблона, не записывая полную реализацию алгоритмов группировки/маршрутизации) на узлы кластера в управляемые групп и маршрутных системных сообщений через иерархию кластера/группы?

Ответы

Ответ 1

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

node= машина.

Чтобы начать, я могу сказать, что 30-60 узлов, которые вы выходите из коробки (установка ватин OTP), с любым пользовательским приложением, написанным поверх этого (в Erlang). Доказательство: ejabberd.

~ 100-150 возможно с оптимизированным пользовательским приложением. Я имею в виду, это должен быть хороший код, написанный с информацией о GC, характеристикой типов данных, передачей сообщений и т.д.

над +150 все в порядке, но когда мы говорим о таких цифрах, как 300, 500, потребуется оптимизация и настройка уровня TCP. Кроме того, наше приложение должно быть известно о стоимости, например. синхронизирует вызовы через кластер.

Другая вещь - уровень БД. Mnesia (встроенная) благодаря своим функциям не будет эффективна более чем 20 узлов (мой опыт - я могу ошибаться). Решение: просто используйте что-то еще: DB динамо, отдельный кластер MySQL, HBase и т.д.

Наиболее распространенным методом увеличения затрат на создание высококачественного приложения и масштабируемости являются федерации кластеров ~ 20-50 узлов. Таким образом, внутренне это эффективная сетка из ~ 50 erlang-узлов и ее соединение через любой подходящий протокол с N еще 50 кластерами узлов. Подводя итог, такая система является объединением кластеров N erlang.

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

Существует множество вариантов конфигурации, например. которые не соединяют все узлы друг с другом. Это может быть полезно, однако в ~ 50 кластерах erlang служебные данные не являются существенными. Также вы можете создать граф узлов erlang, используя "скрытое" соединение, которое не присоединяется к этой полной сетке, но также не может использовать соединение со всеми узлами.

Самая большая проблема, которую я вижу в таких системах, проектирует ее как систему без мастерства. Если вам это не нужно, все должно быть в порядке.