Эрлангские кластеры

Я пытаюсь реализовать кластер, используя Erlang как клей, который держит его все вместе. Мне нравится идея, что он создает полностью связанный граф узлов, но, читая разные статьи в Интернете, кажется, что это не очень хорошо масштабируется (имеет максимум 50-100 узлов). Разве разработчики OTP навязывают это ограничение целенаправленно? Я знаю, что вы можете настроить узлы на наличие явных соединений, а также скрытые узлы и т.д. Но похоже, что настройка по умолчанию по умолчанию не очень масштабируема.

Итак, на вопросы:

  • Если у вас было 5 узлов (A, B, C, D, E), у всех были явные соединения, такие, что A-B-C-D-E. Разрешает ли Erlang/OTP A говорить напрямую с E или должен передавать сообщения от B до D, чтобы добраться до E, и, следовательно, причина для полностью связанного графика? Опять же, это имеет смысл, но оно плохо масштабируется из того, что я видел.

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

  • При взгляде на супервизоров и работников все примеры, которые я видел, применяют к процессам на одном node. Может ли он применяться к кластеру узлов, чтобы помочь реализовать отказоустойчивость?

  • Могут ли узлы быть частью нескольких кластеров?

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

ОТВЕТЫ

Ответ 1

  • Да, вы можете отправлять сообщения в процесс на любом удаленном node в кластере, например, используя его идентификатор процесса (pid). Это называется прозрачностью местоположения. И да, он хорошо масштабируется (см. Riak, CouchDB, RabbitMQ и т.д.).

  • Обратите внимание, что один node может запускать сотни тысяч процессов. Erlang оказался очень масштабируемым и был построен для отказоустойчивости. Существуют и другие подходы к созданию большего объема, например. SOA-подход CloudI (см. Комментарии). Вы также можете создавать кластеры, которые используют скрытые узлы, если вам действительно нужно.

  • На уровне node вы можете использовать другой подход, например, создавать идентичные узлы, которые легко заменить, если они не выполняются, а работа выполняется поверх остальных узлов. Посмотрите, как Riak справляется с этим (посмотрите riak_core и проверьте сообщение в блоге Представляем Riak Core).

  • Узлы могут покидать и вводить кластер, но не могут одновременно быть частью нескольких кластеров. Подключенные узлы совместно используют один куки файл кластера, который используется для идентификации подключенных узлов. Вы можете установить файл cookie во время работы виртуальной машины (см. Distributed Erlang).

Прочтите http://learnyousomeerlang.com/ для большей пользы.

Ответ 2

Протокол распространения - это обеспечение надежности, а не масштабируемости. Что вы хотите сделать, так это группировать кластер в более мелкие области, а затем использовать соединения, которые не являются дистрибутивом в Erlang, но, скажем, в сеансах TCP. Вы можете запускать 5 групп по 10 машин каждый. Это означает, что 10 машин имеют бесшовное распределение Pid: вы можете вызвать pid на другой машине. Но распространение в другую группу означает, что вы не можете без проблем обращаться к такой группе.

Обычно вам требуется какое-то "отражение маршрута", как в BGP.

Ответ 3

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

2) Вы можете создать не полностью подключенный график узлов erlang. Документация трудно найти и возникает с проблемами - вы отключите систему global, которая обрабатывает глобальные имена в кластере, поэтому вы должны делать все локально зарегистрированными именами или локально зарегистрированными именами на удаленных узлах. Или просто используйте Pids, так как они тоже работают. Чтобы запустить erlang node, используйте erl ... -connect_all false .... Надеюсь, вы знаете, что делаете, поскольку я не мог себе этого доверять.

Также выясняется, что не полностью связанный граф узлов erlang является текущей темой исследования. Проект RELEASE в настоящее время работает именно над этим и разработал концепцию S-групп, которые по существу являются полностью связанными группами. Однако узлы могут быть членами более чем одной S-группы, а узлы в отдельных s-группах не обязательно должны быть полностью подключены, но могут устанавливать необходимые им соединения по требованию для прямой связи node -to-node, Стоит найти их презентации, потому что исследование действительно интересно.

Еще одна вещь, заслуживающая внимания, заключается в том, что несколько человек обнаружили, что вы можете получить до 150-200 узлов в полностью подключенном кластере. У вас действительно есть прецедент для большего количества узлов? Разумеется, 150-200 невероятно толстых компьютеров будут делать большинство вещей, которые вы могли бы бросить на них, если у вас не будет смешной проект.

3) Если вы не можете запускать процессы на другом node с помощью gen_server:start_link/3,4, вы можете очень легко вызвать серверы на чужом node. Похоже, что они упустили возможность запускать серверы на иностранных узлах, но, вероятно, для этого есть веская причина - например, нелепое количество ошибок.

4) Попробуйте искать скрытые узлы и иметь не полностью подключенный кластер. Они должны позволить вам группировать узлы по своему усмотрению.

TL; DR: Масштабирование затруднено, отпустите покупки.

Ответ 4

Уже есть хорошие ответы, поэтому я стараюсь быть простым.

1) Нет, если A и E не подключены напрямую, A не может разговаривать с E. Протокол распространения работает по прямому TCP-соединению - без включения маршрутизации.

2) Я думаю, что древовидная структура достаточно хороша - компромиссы всегда существуют.

3) Нет "супервизора для узлов", но erlang:monitor_node - ваш друг.

4) Да. A node может разговаривать с узлами из разных "кластеров". В локальном node используйте erlang:set_cookie(OtherNode, OtherCookie) для доступа к удаленному node с другим файлом cookie.

Ответ 5

1) да. они разговаривают друг с другом

2) 3) и 4) Вообще говоря, при построении масштабируемой и отказоустойчивой системы вы хотели бы или, более того, разделить рабочую нагрузку на разные "регионы" или "кластеры". Модель Supervisor/Worker предусматривает, таким образом, топологию. Что вам нужно, так это несколько процессов, координирующих работу между кластерами и всеми рабочими в одном кластере, будут говорить друг с другом о балансе внутри группы.

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

Итак, в заключение,

2) используйте древовидную топологию для ваших руководителей. пусть работники явно соединяются друг с другом и разговаривают в своем собственном домене с руководителями.

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

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