Как лучше всего запустить gen_server на всех узлах в кластере Erlang?

Я создаю инструмент мониторинга на Erlang . При запуске в кластере он должен запускать набор функций сбора данных на всех узлах и записывать эти данные с помощью RRD на одном узле «записывающего».

В текущей версии на главном узле запущен супервизор ( rolf_node_sup ), который пытается запустить 2-й супервизор на каждом узле в кластере ( rolf_service_sup ). Затем каждый из супервизоров на узле должен запустить и контролировать группу процессов, которые отправляют сообщения обратно на gen_server на главном узле ( rolf_recorder ).

Это работает только локально. Ни на одном удаленном узле не запускается супервизор. Я использую следующий код , чтобы попытаться загрузить супервизор на узле из узла записи:

rpc:call(Node, supervisor, start_child, [{global, rolf_node_sup}, [Services]])

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

• Запуск процессов на удаленных узлах
• как: Распределенное дерево супервизора

Каков наиболее однозначный способ реализации моего требования иметь контролируемый код, работающий на всех узлах кластера?

• Распределенное приложение предлагается в качестве альтернативы распределенному дереву супервизора. Это не подходит для моего варианта использования. Они обеспечивают переключение между узлами, но поддерживают выполнение кода на наборе узлов.
• Модуль pool представляет интерес. Однако он обеспечивает выполнение задания на узле, который в настоящее время наименее загружен, а не на всех узлах.
• В качестве альтернативы, я мог бы создать набор контролируемых «прокси-процессов» (по одному на узел) на главном сервере, которые используют proc_lib: spawn_link для запуска супервизора на каждом узле. Если что-то пойдет не так на узле, процесс прокси должен умереть, а затем его супервизор перезапустит. что, в свою очередь, должно перезапустить удаленные процессы. Здесь может быть очень полезен подчиненный модуль.
• Или, может быть, я слишком усложняю. Непосредственное наблюдение за узлами - плохая идея, вместо этого, возможно, мне следует спроектировать приложение для сбора данных более слабосвязанным способом. Создайте кластер, запустив приложение на нескольких узлах, скажите одному из них быть ведущим, оставьте все как есть!

Некоторые требования:

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