Назад | Перейти на главную страницу

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

Мне нужно перенастроить prod env для обеспечения горячего аварийного переключения для веб-приложения, управляемого базой данных, написанного на Perl, которое в настоящее время работает на сервере HTTPD Apache в ОС Linux.

Приложение не предназначено для работы в кластере. Таким образом, если 2 экземпляра этого приложения подключены к одной базе данных и доступны пользователям через NLB, это приведет к катастрофе (логически поврежденной базе данных).

Я хотел бы настроить разные учетные данные db для двух экземпляров приложения, помещенных под Apache mod_proxy NLB, установленного на третьем компьютере. Обычно экземпляр 2 отключается, а экземпляр 1 обрабатывает всю нагрузку. Когда что-то пойдет не так с экземпляром 1, мне понадобится сценарий для отправки команды выключения экземпляру 1, подключения к базе данных и отключения учетных данных базы данных экземпляра 1, перезапуска сервера базы данных и, наконец, запуска экземпляра 2. Если что-то пойдет не так в этой цепочке событий, я был бы рад, если бы приложение оставалось недоступным для пользователей.

Проблема в том, что я не знаю простого способа настроить этот сценарий горячего аварийного переключения. Я был бы счастлив приклеить сценарий оболочки к mod_proxy, но не знаю, возможно ли это.

Можно ли это сделать без настройки дополнительной системы мониторинга, которая бы обнаружила проблему и инициировала необходимые действия?

Зачем пытаться воссоздать колесо? Существует множество отличных отказоустойчивых решений с проверенными показателями стабильности. Например, используйте Pacemaker для управления запуском / остановкой ваших сервисов и Heartbeat для определения состояния ваших серверов.

Если все, что вы пытаетесь защитить, - это сбой одного из ваших интерфейсных серверов Apache, вы можете вместо этого использовать балансировщик нагрузки, такой как haproxy. Haproxy может быть настроен на использование только одного сервера в качестве основного, что является резервным вариантом для одного веб-сервера. Вот так:

listen externalwww 10.0.1.186:80
        bind 10.0.1.186:443
        mode    tcp
        option  persist
        option  httpchk
        default-server  inter 5000
        server  external 33.44.55.66 check port 80 inter 15000 rise 10
        server  internal 10.0.1.49 check port 80 backup