1. воркер, обновляющий список живых хостов 2. воркер, ходящий по списку живых хостов и убеждающийся, что всё запущено

@kb (это я как предложение альтернативной к "ивенты/хуенты/подписки" модели)

@kb убеждаться в запущенности каждый раз -- не дёшево, учитывая, что надо довольно быстро подхватывать живой хост в работу. Что-то типа реактивного должно быть на нижнем уровне, с реакцией на разные события внешнего мира и на требования пользователя.

1. клади задания в zookeeper/etcd ёпт

В гомогенной среде, наверное, раз уж надо выполнять какой-то код на узлах, проще всего будет сделать агент-watchdog, который следит за работой нужного демона и одновременно каждые n секунд пингует сервер. Пинги идут — узел в работе, пинги пропали — вычёркиваем. В гетерогенной среде, для универсальности, его надо будет держать на сервере, и проверять он будет список узлов с той же частотой. > таймауты тут сработали бы надёжно, но и без них часто ясно, что ответа не будет Вот как по отсутствию обмена данными с удалённой стороной может быть «ясно», пока его продолжительность не превысит некую заданную велиину? Это и есть «таймаут».

@ceyt > агент-watchdog, который следит за работой нужного демона уже есть! > Это и есть «таймаут». да, таймауты есть, в том числе по пингам. Я их считаю как бы "данными свыше" (но и на запросы их тоже вешать надо). Я тут скорее думаю про то, как записать логику относительно высокоуровнево. В виде каких-то декларативных правил, что ли. Почему императивное не подходит: рассмотрим первый пример. Процедура запуска процесса будет "взять множество хостов, выделить живые, запустить всё на живых", и должна быть реакция на появление хоста: "если ожил хост из того множества, и кластер должен быть запущен (согласно директивам пользователя), то надо запустить на нём процесс".

@polecat пруф или в мейлбокс

@polecat так надо.

хуле ты там жаваскрипт изобретаешь