Up the pool

Автор оригинала: Guy Wiener
  • Перевод
Я программист. Поэтому, меня всегда потрясают вещи, которые «просто работают». Это чувство у меня было и когда я знакомился с Erlang Pool. Настройка требует некоторого внимания, но после, механизм оказывается «оскорбительно» простым.

Для запуска Erlang пула Вам необходимо следующее:
  • Набор компьютеров с одинаковым Erlang окружением, один из которых будет главным
  • Все компьютеры должны иметь код, который будет запущен
  • Файл с хостами Erlang на главном компьютере (обычно ~/.hosts.erlang)
  • Все компьютеры должны иметь одинаковые Erlang-cookie (обычно ~/.erlang.cookie)
  • Главный компьютер должен иметь RSH или SSH no-password-required доступ ко всем остальным компьютерам
  • Оболочка Erlang на главном компьютере должна быть именованной, т.к. она создает ноду

Вот и все. Как только все готово, запустите на главном компьютере оболочку и выполните:

pool:start(Name).

И вот! Вы имеете свой собственный Ad-hoc, load-balancing, распределенный пул компьютеров. Вам не нужна запускать ноды на остальных компьютерах: Erlang сделает это за Вас. Следующая команда на главной ноде запустит процесс с функцией и аргументами на наименее загруженной ноде:

pool:pspawn(Mod, Func, Args).

Я назвал это «оскорбительно простым» потому, что это и есть оскорбление все раздутых, коммерческих, дорогих BPEL-for-Web-Services-on-J2EE (or .NET) серверов приложений и т.д. Мы слишком привыкли к «графическим редакторам, которые генерируют XML, который генерирует код, который запаковывается с манифестом и отправляется на специальный сервер». Когда кто-либо появляетcя и говорит «Эй, оболочка и plain-text конфиг это все тебе нужно», это немного шокирует.

Keep It Simple, Stupid.

Комментарии 13

    +2
    >Keep It Simple, Stupid.
    Интересно, сколько тысяч уровней абстракции спряталось за этими двумя строчками?
    >Для запуска Erlang пула Вам необходимо следующее
    Ничем вобщемто не отличается от других распределенных технологий, кроме того, что все «искаропки».
      +2
      > Ничем вобщемто не отличается от других распределенных технологий, кроме того, что все «искаропки».

      Вообще-то в этом и есть главное и основное отличие
      +1
      Интересно, когда сюда набегут фанаты С++ с их шаблонной магией и БЫСТРОДЕЙСТВИЕМ!?
        +1
        Похоже набежали...))
          +4
          Да, у них начинается батхерт, когда любое действие можно сделать быстрее, чем за два десятка строк и тридцать шаблонов из буста.
        +4
        «Все компьютеры должны иметь код, который будет запущен»
        Необязательно. erl_boot_server крайне прост в настройке и решает эту проблему в корне. Заодно избавляет от задач синхронизации бинарей на нодах.
          +3
          Модули еще можно подгружать на всех нодах сразу коммандой nl(Mod), где Mod — имя модуля.
            0
            Разумеется, существуют способы синхронизации кода между нодами, в том числе «из коробки». В списке указаны скорее не необходимые действия, а условия.
              +2
              > Я программист. Поэтому, меня всегда потрясают вещи, которые «просто работают».

              > это и есть оскорбление все раздутых, коммерческих, дорогих BPEL-for-Web-Services-on-J2EE (or .NET) серверов приложений и т.д.

              К великому сожалению, нынче вещи, которые «просто работают» не продать :(
              • НЛО прилетело и опубликовало эту надпись здесь
                0
                круто! можно использовать Erlang + Linux + ODBC + Oracle, нужно будет как-нибудь вспомнить и попробывать, спасибо за статью
                  0
                  В большинстве случаев просто брать какую-либо технологию и применять её из-за того, что она клевая, ничем хорошим не заканчивается. Для каждого класса задач есть свои эффективные инструменты, и чтобы их выбрать нужно провести хороший анализ.
                  0
                  А если к примеру есть задача принимать на этот кластер подключения, как можно обеспечить распределение запросов по нодам? Хорошо бы учесть текущее состояние ноды — может она ушла в даун, а мы пытаемся к ней коннектиться?
                  Кстати, что будет происходить при падении ноды? Как другие процессы об этом узнают? Например, если есть два слинкованных процесса на разных нодах?
                  Есть какое-нибудь «аффинити»? Например, запустить процесс, с которым будешь интенсивно общаться, на локальной ноде?

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое