Коллеги, всем привет!

Подайте, пожалуйста, идею. Есть кластер из заранее известного списка нод. Ноды выполняют очень долгоживущие задачи (фактически неограниченные по времени). Общий пул задач постоянно меняется: появляются новые задачи, а старые в какой-то момент отменяются. У каждой задачи есть уникальный ключ, который определяется параметрами задачи.

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

условия и ограничения:
1) минимизировать число переназначений задач при failover
2) исключить возможность выполнения нескольких задач с одним и тем же ключом на разных нодах
3) кластер должен нормально себя вести при штатном запуске и останове (когда включаются или выключаются все ноды). Не должно начинаться беспорядочное распределение задач туда-сюда

Какие технологии можно использовать для решения данной задачи с минимальными трудозатратами? Спасибо

Переместите в Java, пожалста :)

Модератор: Тема перенесена из форума "Работа".

Leonid KudryavtsevНе ясно, что автор подразумевает под словом "задача (фактически неограниченные по времени)"

Очередь подойдет, если "задача" это задача. Т.е. нечто, что отрабатывает за конечное время и возрашает результат

Если "задача" это некоторый демон/сервисная служба, то очередь вряд ли подойдет. Я в таких случаях делал свою службу "диспетчер", которая отслеживала работоспособность служб и перезапускала их при необходимости. Правда, получалась единая точка отказа. Если падал диспетчер, то система приходила в неработоспособное состояние.

Неограниченные по времени - подразумеваю, что у задач нет детерминированного "конца" :) Они завершаются по событию извне.

Leonid KudryavtsevВ принципе, это базавая задача любого кластера
Т.ч. любой кластерный софт, толжен уметь ее решать "из коробки"

Тот же Oracle WebLogic Server, кластера поддерживает.

У нас обычные java приложения в контейнерах, сервера приложений не пользуем.

HettОбычная очередь c подтверждением.
Берем из очереди задачу, обрабатываем, по окончанию шлем подтверждение.
https://docs.oracle.com/cd/E19798-01/821-1841/bncfw/index.html
Очередь должна быть одна, естественно. Можно взять AMQ, kafka и т.п. Все ноды подключаются к mq серверу и берут задания.
Один из рассматриваемых вариантов - Rabbit MQ с плагином для шардинга сообщений по очередям. Основной недостаток (помимо необходимости разворачивать инфраструктуру, админить брокер и т.п.) - это то, что упавшая нода не сможет вернуть незавершенные задачи обратно в очередь.

fixxerОформляете задачи в виде спрингбут приложений, запускаете на кубернетесе.
Задачи очень "легковесные", их много (порядок - несколько тысяч на ноду), плюс регулярно появляются новые задачи и завершаются текущие.

Cheblin https://akka.io/] AKKA
Хотелось бы чистое java решение. Но почитаю, спасибо.

Герой дня Marathon+Mesos решают задачу :
Спасибо, почитаю. На первый взгляд выглядит сложновато (опять же, с т.з. развертывания софта и простоты встраивания в существующую концепцию написания приложений).

Petro123Leonid KudryavtsevС точки зрения извне и программирования, кластер выглядить как один Application сервер, компьютеры и ресурсы внутри кластера - проблема кластерного софта.

На то он и кластер.
+1
Думаю автору не надо писать свой кластерСофт, а изучить сущестаующие.
Ни в коем случае не собираюсь писать свой велосипед, т.к. примерно представляю себе объем работы, хотя поползновения такие со стороны руководства есть.

CheblinAKKA и так....в этом смысле чище не бывает. В AKKA предоставлена возможность писать и на простейшей JAVA , но получаться будет как обычно.. многоэтажно и многословно.
Разобрался сегодня... cluster + cluster-sharding = то, что доктор прописал. Подходит под задачу идеально. Спасибо!