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

• позволяет распределить нагрузку
• облегчает перезапуск/обновление версий
• повышает надёжности системы в целом

При этом конфигурация несколько усложняется:

• Необходимо использовать Apache HTTP server (или любой другой, для которого написан модуль поддержки протокола AJP)
• Часть файлов и база данных должны использоваться совместно всеми серверами кластера. Поэтому, необходимо использование сетевой файловой системы (nfs/samba)

Процесс настройки:

Настройка Apache Tomcat с Apache HTTP Server.

Процесс достаточно подробно описан в документации к tomcat, необходимо лишь обратить внимание на следующее:

• Каждый хост имеет уникальное имя, которое задаётся в конфигурации Tomcat (etc/server.xml, атрибут jvmRoute и тэга Engine), и оно же задаётся в конфигурации mod_jk (для jk1 совпадает с именем worker, для jk2 задаётся атрибутом tomcatID у [channel]
• Серверы кластера уведомляют друг друга по протоколу HTTP. Поэтому, Tomcat должен быть настроен на приём как AJP запросов от Apache, так и обычных HTTP запросов (рекомендуется использовать порт 8080. Номер порта задаётся атрибутом rport в конфигурации).

Общие файлы.

Каталог с установленным arp.site может быть целиком экспортирован на другие серверы (т.е. для одного по пути /opt/arp.site он находится локально, для остальных он монтируется по тому же пути). В случае использования windows и samba, удобно открыть доступ к инсталляции одной из машин и подключать её как сетевой диск. Файлы, зависящие от хоста, расположены следующим образом:

• Логи: ARPSITE_HOME/logs/<хост>/...
• Кэш (прогенеренные страницы): ARPSITE_HOME/cache/<хост>/...

При этом, если логи имеет смысл хранить на одном сервере, то кеш лучше хранить локально. В случае с linux достаточно вместо каталога cache сделать символическую ссылку куда-нибудь на /var/cache/tomcat. Для samba аналогичного решения нет, т.е. кеш будет хранится на сетевом диске.

Перезапуск системы и обновление версий

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

Повышение надёжности

Все стандартные компоненты системы, которым необходим самостоятельный доступ в Internet (возможность исходящих соединений), работают на главном (master) сервере, у которого установлен соответствующий флаг в конфигурации.

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