Быстрое обнаружение удаленного завершения процесса - PullRequest
1 голос
/ 01 марта 2011

У меня есть распределенное приложение, в котором ресурсы заблокированы для исключительного использования задачами. Каждая задача выполняется в своем собственном процессе. Я хотел бы автоматически разблокировать ресурсы, если завершается процесс задачи или умирает сервер, на котором он работает (например, сбой питания).

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

После некоторого поиска в Google я выдвинул несколько идей, но у меня нет прямого опыта ни с одной из них ...

  • Используйте функции консультативной блокировки, встроенные в mySQL (get_lock) или postgres (pg_advisory_lock). Это автоматически снимет блокировки, если соединение с базой данных будет закрыто, что произойдет при выходе из процесса или сбое сервера.

  • Используйте выделенный менеджер распределенных блокировок, такой как ZooKeeper. Это бы сработало, но кажется, что мне нужно больше.

  • Установите TCP-соединение между процессом задачи и процессом удаленного мониторинга с включенной опцией keepalive TCP / сокета. Это кажется выполнимым, но я бы предпочел опираться на то, что позаботится о деталях сети низкого уровня для меня.

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

Спасибо за любые отзывы!

1 Ответ

0 голосов
/ 16 марта 2011

Возможно, вы захотите прочитать в разделе «ϕ накопительные детекторы отказов». Я обнаружил, что это наиболее общий и теоретически обоснованный подход к детекторам отказов. Это никогда не вопрос «обнаружения сбоев за считанные секунды», а всегда компромисс между тем, насколько быстро и насколько надежно обнаружение сбоев. Зная, как собирать и обрабатывать статистику отказов, которые были правильно или ошибочно обнаружены в прошлом, вы можете оценить вероятность сбоя как функцию времени, в течение которого вы ожидали ответа от удаленного сервера.

TCP keep-alive здесь бесполезен - его "пинг" слишком грубый, по умолчанию 2 часа.

...