Tomcat активный пассивный переход на другой ресурс

Я пытаюсь сделать свое приложение высокодоступным, используя метод активный/пассивный. В настоящее время я развертываю приложение на сервере Tomcat, который может быть размещен на платформе Windows или Linux.

Итак, теперь я развертываю его на двух серверах Tomcat. Каждый сервер работает на отдельной машине. Я настраиваю Tomcats на один и тот же кластер с помощью конфигурации Tomcat, которая дает мне репликацию сеанса (сохранение в БД). Я использую какой-то веб-сервер/балансировщик нагрузки для перенаправления запросов (еще не решил).

Проблема в том, что приложение не может работать одновременно на обоих Tomcats, так как в настоящее время оно поддерживает состояние (и делать его без состояния слишком дорого). На самом деле мне нужно, чтобы одновременно работал только один Tomcat. Или, по крайней мере, на Tomcat будет запущено только одно приложение.

Подводя итог, мне нужно программное обеспечение, которое может:

  1. Определить недопустимое состояние приложения с помощью HTTP-запроса (либо компьютер/Tomcat не работает, либо приложение не отвечает по другим причинам);
  2. Запустите экземпляр или приложение Tomcat на Tomcat, когда другое приложение определено как недействительное;
  3. Остановите экземпляр Tomcat или приложение на Tomcat, если оно определено как недопустимое.
  4. Поддержка платформ Linux и Windows...

Этот продукт может быть библиотекой, которая используется на нашей JVM, это могут быть отдельные процессы мониторинга, которые находятся на машинах Tomcats и взаимодействуют друг с другом и с Tomcats, он может использовать нашу БД. Он может использовать веб-сервер...

Я искал готовые продукты, которые это делают (Pacemaker/CoroSync/keepalived) , все не поддерживающие винду (насколько я понимаю).


tomcat failovercluster
person yair    schedule 23.01.2013    source источник
comment
посмотрите мой ответ на stackoverflow.com/questions/11465714/tomcat-webapp-failover - может решить вашу проблему   -  person Erich Eichinger    schedule 07.02.2013
comment
Возможно, это хороший повод взглянуть на кластерный сервер приложений, где узлы знают друг друга. Glassfish 3.1.2 может быть полезен вам в версии с открытым исходным кодом.   -  person Thorbjørn Ravn Andersen    schedule 04.08.2013
comment
@ ThorbjørnRavnAndersen, надеюсь, вы не читали мой собственный ответ здесь :) (там много слов). В любом случае, интересно узнать, что Glassfish поддерживает кластеризацию, но замена наших серверов неприемлема. Спасибо.   -  person yair    schedule 04.08.2013
comment
Я сделал. Много работы, чтобы заставить Tomcat делать то, для чего он не был предназначен.   -  person Thorbjørn Ravn Andersen    schedule 04.08.2013
comment
@ThorbjørnRavnAndersen и я плакали. Однако, если бы наши сервисы не имели состояния, мы бы просто сделали все это активным-активным и заснули счастливыми.   -  person yair    schedule 04.08.2013

Ответы (1)


arrow_upward
0
arrow_downward

В итоге я сделал следующее:

Оба Tomcat всегда запущены. Приложение также запускается на обоих Tomcats.

Специальное synchronization service было написано от руки. Эта служба является частью приложения и запускается вместе с запуском приложения. Он отвечает за определение узла, который в данный момент активен и какой из них должен быть активным.

Мое приложение использовало контекст Spring для управления жизненным циклом моих сервисов. Я разделил его на два разных контекста: контекст wrapper Spring и контекст child Spring.

Контекст wrapper запускался вместе с запуском приложения, всегда был доступен и работал на обоих Tomcat. Служба синхронизации была настроена как bean-компонент в контексте wrapper.

Контекст child фактически включал все сервисы, которые мое приложение предоставляло внешним клиентам. Это контекст, который я определил запускать, только когда текущий узел активен, и останавливать, когда он становится пассивным.

Как контекст child включался/выключался при активном/пассивном режиме?

Этот контекст не запускался автоматически при запуске приложения. Когда synchronization service пришел к выводу, что текущий узел должен стать активным, возникло событие, которое вызвало запуск контекста child, что сделало все службы доступными на этом узле. И наоборот: когда synchronization service пришел к выводу, что текущий узел должен стать пассивным, возникло соответствующее событие, которое привело к отключению контекста child, сделав все службы недоступными на этом узле.

Еще одной важной функцией, которая была добавлена, была interceptor для входящих запросов. Входящий запрос, попадающий на один из Tomcats, фактически означает, что балансировщик нагрузки/веб-сервер решил, что целевой узел является доступным в данный момент или предпочтительным узлом. В таком случае, даже если целевой узел был пассивным, теперь он должен стать активным. Таким образом, intercepror вызовет то же событие, что и synchronization service, снова запустив контекст child и сервисы, доступные на этом узле (а synchronization serivce на обоих Tomcat идентифицирует коммутатор, и ранее активный узел будет пассивирован).

person yair    schedule 29.07.2013