Автор Тема: Семафор для скрипта по сети  (Прочитано 2085 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн airdwarf

  • Постоялец
  • ***
  • Сообщений: 371
  • Рейтинг: 7
  • Пол: Мужской
    • Просмотр профиля
  • Откуда: Чесслово, нашел, гражданин начальник!
Семафор для скрипта по сети
« : 20 апреля 2020, 11:33:41 »
Картина, уважабэ, следующая:


Есть некий скрипт, работающий локально, назовем его мастер-экземпляром.
Он запускает другой скрипт (слэйв) одновременно на N удаленных хостов, произвольным образом, под произвольной учеткой. ОС произвольная.
Этот другой скрипт последовательно выполняет локальные действия А и Бэ.
Мастер видит факт завершения слэйва и статус возврата.


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

Файл на общем SMB-ресурсе не предлагать: ACL на этот ресурс видится слишком объемным объектом контроля для решаемой задачи.
Клиент-сервер под это мне писать лень, да и не дело это для скрипта.
Невыполнение Бэ после выполнения А является аварийной ситуацией, поэтому делить слэйв на два скрипта не хочется.
На всех хостах есть http-сервер, обеспечивающий работу бизнес-приложения, но хочется, чтобы описанная конструкция работала независимо от него.

А у вас есть идеи, или может быть, чем Г-тс не шутит, работающее решение?
Кто чувствует несвободу воли, тот душевнобольной; кто отрицает ее, тот глуп. Один я умный в белом пальто стою красивый.
Вы тут серьёзно отстали от жизни. Админство, саппорт - это уже вчерашний день. Сейчас рулят микросервисная архитектура и continuous integration. Ну еще SAAS, конечно.

Онлайн klarkin

  • Начинающий
  • *
  • Сообщений: 39
  • Рейтинг: 1
  • Пол: Мужской
    • Просмотр профиля
  • Откуда: Из маминой...
Семафор для скрипта по сети
« Ответ #1 : 04 мая 2020, 00:34:05 »
Файл на общем SMB-ресурсе не предлагать: ACL на этот ресурс видится слишком объемным объектом контроля для решаемой задачи.
Клиент-сервер под это мне писать лень, да и не дело это для скрипта.
В этом условии исключается и ёлка и рыбка.

Я бы, при этих вводных данных, сделал семафор через занесение/чтение данных в таблице БД.
Полагаю, минимум 1 СУБД, в инфраструктуре уже есть.
"Мы похвалили её за принципиальность. Побольше бы таких." ©

Оффлайн airdwarf

  • Постоялец
  • ***
  • Сообщений: 371
  • Рейтинг: 7
  • Пол: Мужской
    • Просмотр профиля
  • Откуда: Чесслово, нашел, гражданин начальник!
Семафор для скрипта по сети
« Ответ #2 : 11 мая 2020, 07:57:56 »
klarkin, это ты умный или я тупой?  ???
Кто чувствует несвободу воли, тот душевнобольной; кто отрицает ее, тот глуп. Один я умный в белом пальто стою красивый.
Вы тут серьёзно отстали от жизни. Админство, саппорт - это уже вчерашний день. Сейчас рулят микросервисная архитектура и continuous integration. Ну еще SAAS, конечно.

Оффлайн ds0m

  • Ветеран
  • *****
  • Сообщений: 1299
  • Рейтинг: 22
  • Пол: Мужской
    • ds0m.spb@gmail.com
    • Просмотр профиля
  • Откуда: DC
Семафор для скрипта по сети
« Ответ #3 : 13 мая 2020, 20:44:04 »
klarkin, это ты умный или я тупой? 
Так вот хз.
Ну нормальный жи есть вариант. Не можешь писать в файл, писай в базу.
<root> помимо принципа "работает - не трогай", есть ещё один важный принцип - "бритва Оккама" - "не приумножай сущность сверх необходимости"
А спонсор этого поста - прививка от бешенства. Прививка от бешенства - не твоя, вот ты и бесишься.

Оффлайн Dr.Night

  • Старожил
  • ****
  • Сообщений: 996
  • Рейтинг: 22
  • Пол: Мужской
    • mikhail.penkov
    • Просмотр профиля
  • Откуда: ( ω )
Семафор для скрипта по сети
« Ответ #4 : 19 мая 2020, 02:14:24 »
Безопасность важна или нет?
Если считаем, что хосты доверенные и злоумышленник не может получить доступ к скрипту и поломать логику, то просто захардкодить в слейве учетку к шаре или учетку к БД. К шаре - проще и быстрее. По безопасности без разницы.

Если потенциально защищаемся от взлома и имеем риск наличия злоумышленника на одном из хостов, то все сильно сложнее. Доверять исходящим сигналам от хоста со слейвом не можем, т.е. централизованный семафор отменяется и мы должны будем научить мастер скрипт получать информацию от слейва.
Причем от слейва напрямую, а не через промежуточную сущность, например файл на http-сервере.
Как вариант, все таки, разбить слейв на две части и работать со статусами возврата.
There are ten kinds of people in the world - those who understand binary and those who don't