Интересные задачи, для которых есть несколько решений.Ниже приведены только мои предложения, которые, надеюсь, позволят вам лучше сделать выбор в отношении написания вашей программы.
Поскольку я понимаю вашу программу, вам нужен один главный узел, с которого вы запускаете свое приложение.Это запустит виртуальную машину Erlang на узлах в кластере.Модуль pool использует для этого модуль slave, для которого требуется ssh-связь на основе ключей в обоих направлениях.Также необходимо, чтобы у вас работали соответствующие днс.
Недостаток slave заключается в том, что, если мастер умирает, то же самое делают и рабы.Это сделано специально, поскольку, вероятно, оно идеально подходит к исходному сценарию использования, однако в вашем случае это может быть глупо (вы можете собирать данные, даже если мастер не работает, например)
Что касаетсяПриложения OTP, каждый узел может запускать одно и то же приложение.В своем коде вы можете определить роль узлов в кластере, используя конфигурацию или обнаружение.
Я бы предложил запустить виртуальную машину Erlang с использованием некоторого средства ОС или daemontools или подобного.Каждая виртуальная машина запускает одно и то же приложение, где один запускается как ведущий, а остальные - как ведомые.Это имеет недостаток, заключающийся в том, что труднее «автоматически» запускать программное обеспечение на компьютерах, входящих в кластер, как вы могли бы сделать с slave, однако это также намного более надежно.
В каждом приложении, которое вы могли быиметь подходящее дерево контроля, основанное на роли узла.Удаление межузлового контроля и нереста значительно упрощает систему.
Я бы также посоветовал всем узлам подтолкнуть к мастеру.Таким образом, мастеру на самом деле не нужно заботиться о том, что происходит в подчиненном устройстве, он может даже игнорировать тот факт, что узел не работает.Это также позволяет добавлять новые узлы без каких-либо изменений в мастер.Файл cookie может использоваться в качестве аутентификации.Несколько мастеров или «рекордеров» также были бы относительно простыми.
Однако «ведомые» узлы должны будут следить за тем, чтобы мастер вышел из строя и вышел из строя, и предпринять соответствующие действия, такие как сохранение данных мониторинга, чтобы они моглиотправьте его позже, когда мастер вернется.