Кластеризация Tomcat

В этой статье я покажу вам, как использовать Apache / Tomcat для настройки балансировщика нагрузки. Я знаю, что это было сделано миллионы раз раньше, но я буду использовать эту настройку в моей следующей статье (тизер, тизер), поэтому, по крайней мере, я буду где-то документировать ее.

Apache Tomcat является эталонным JSP / контейнером с момента его создания. Несмотря на отсутствие полной поддержки JEE, он, безусловно, имеет свою привлекательность. Причины использования полнофункционального коммерческого сервера приложений JEE не всегда технические. Поскольку легковесные фреймворки, такие как Spring, стали мейнстримом, нет ничего необычного в том, чтобы использовать Tomcat в производственной среде. Некоторые компании сделали это еще до этого.

Размышляя о производстве, обычно думают о надежности и масштабируемости. К счастью, оба могут быть достигнуты с Apache / Tomcat через настройку кластера балансировки нагрузки. Надежность, таким образом, решается таким образом, что в случае сбоя Tomcat следующие запросы могут быть направлены на работающий Tomcat. Запросы отправляются каждому Tomcat в соответствии с заранее определенной стратегией. Если необходимо, можно добавить больше Tomcat по своему желанию для масштабирования.

В следующем примере я настрою простейшую из возможных топологий кластеризации: интерфейс Apache, который балансирует 2 экземпляра Tomcat на одной физической машине.

Настройте Apache

Первый шаг — настроить Apache для пересылки ваших запросов в Tomcat. Для этого есть 2 варианта (я исключил предварительно поставленное веб-приложение балансировки нагрузки):

• используйте mod_jk , классический модуль Apache / Tomcat
• используйте mod_proxy , другой модуль Apache

Я не системный инженер, поэтому я не могу определиться с фактами, использовать ли одно или другое : я буду использовать mod_jk, так как я уже использовал его раньше.

• Загрузите mod_jk, адаптированный к вашим версиям Apache и Tomcat.
• Поместите его в папку «modules» вашей установки Apache
• Обновите конфигурацию httpd.conf, чтобы загрузить ее с Apache

  LoadModule jk_module modules/mod_jk-1.2.28-httpd-2.2.3.so

• Настройте Apache. Поместите эти директивы в httpd.conf:

  JkWorkersFile	conf/worker.properties
  JkShmFile	logs/mod_jk.shm
  JkLogLevel	info
  JkLogFile logs/mod_jk.log
  JkMount		/servlets-examples/* lb

Этот пример конфигурации минимален, но нуждается в некоторых комментариях:

Поскольку mod_jk можно использовать в некластеризованных установках, может быть любой JkMount, каждый из которых пересылает своему собственному работнику (см. Ниже). В нашем случае это означает, что любой запрос, начинающийся с / servlets-examples / (необходим завершающий слеш), будет перенаправлен работнику ‘lb’.

Настроить работников

Рабочие — это маршруты назначения, как их видит Apache. На них ссылается уникальная метка в httpd.conf и параметризуется под той же меткой в ​​файле worker.properties.
Мои работники.свойства следующие:

worker.list=lb

worker.worker1.port=8010
worker.worker1.host=localhost
worker.worker1.type=ajp13

worker.worker2.port=8011
worker.worker2.host=localhost
worker.worker2.type=ajp13

worker.lb.type=lb
worker.lb.balance_workers=worker1,worker2

В этом файле я определяю 3 рабочих: lb, worker1 и worker2. Работник ‘lb’ является работником балансировки нагрузки: он виртуален и уравновешивает последние два. Оба настроены так, чтобы указывать на настоящий экземпляр Tomcat.

Теперь, имея в виду конфигурацию Apache, мы видим, что запросы, начинающиеся с / servlets-examples /, будут обрабатываться рабочим балансировщика нагрузки, который, в свою очередь, перенаправляет случайному рабочему.

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

Настройте экземпляры Tomcat

Последний шаг состоит из настройки экземпляров Tomcat. Для этого я бесстыдно скопировал все установки Tomcat (я на Windows). При редактировании server.xml экземпляров Tomcat стоит упомянуть три момента:

• Тег Engine имеет атрибут jvmRoute. Это значение должно совпадать с именем работника, используемым в httpd.conf и worker.properties. В противном случае сессии будут воссозданы для каждого запроса.
• Проверьте наличие дублированных номеров портов, если все экземпляры Tomcat находятся на одном компьютере. Например, используйте инкрементное правило для настройки каждого потока на другом порту.
• Убедитесь, что атрибут tcpListenPort получателя уникален для всех экземпляров Tomcat

Используй это!

С предыдущей настройкой теперь можно запустить Tomcat и Apache, затем перейти к веб-приложению с сервлетами-примерами, а точнее — к странице Session. Посмотрите там на Tomcat 5.5 и там для Tomcat 6. сервлетов пример страницы страница отображает связанный идентификатор сеанса:

ID de Session: 324DAD12976045D197435033A67C025D.worker2
Crée le: Tue Feb 23 23:15:13 CET 2010
Dernier accès: Tue Feb 23 23:31:47 CET 2010

Обратите внимание, что в моем экземпляре Tomcat имя работника является частью идентификатора сеанса.

Если все прошло хорошо, должны произойти две интересные вещи: во-первых, при обновлении страницы идентификатор сессии не должен меняться из-за зависания сессии (по умолчанию включено). Еще больше, если я выключу экземпляр Tomcat, связанный с рабочим (второй в моем случае), и если я попытаюсь обновить страницу, я все равно смогу получить доступ к своему приложению, но в новом сеансе.

Таким образом, я теряю всю информацию, которую хранил в ходе сеанса! В моей следующей статье я изучу, как можно попытаться исправить это.

Чтобы идти дальше:

• Инструкции по кластеризации / репликации сеансов
• Конфигурирование Apache : директивы mod_jk
• Рабочие HowTo

С  http://blog.frankel.ch