Насколько масштабируем распределен Эрланг?

Question

Часть A:

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

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

Часть B:

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

Answer 1

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

узел = машина.

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

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

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

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

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

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

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

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