уже много лет мы используем сервер Apache с плагином Mod_wl для балансировки сеансов с несколькими внутренними веб-серверами Weblogic.
Теперь, через некоторое время, мы также начали использовать тот же Apache для обратного прокси для других внутренних приложений. Итак, мне теперь интересно, почему мы даже используем mod_wl, а не только сервер Apache, его собственный mod_proxy и mod_proxy_balancer для балансировки наших собственных внутренних веб-серверов Weblogic?
Есть ли польза от этого проприетарного плагина? Или несколько лет назад этого было не так просто добиться с помощью Apache Config? Я попробовал настроить без плагина Mod_wl для некоторого тестирования, и, похоже, он работает нормально только для липкости сеанса, кажется, мне пришлось добавить новый файл cookie через Apache, поскольку он не работает с нашим существующим J2SESSIONID, установленным Weblogics для некоторых причина.
Итак, следующие
Header add Set-Cookie "J2ROUTE=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Proxy balancer://backends>
BalancerMember http://localhost:9001 route=1
BalancerMember http://localhost:9002 route=2
ProxySet stickysession=J2ROUTE
</Proxy>
выглядит так же, как и эта предыдущая конфигурация, с использованием mod_wl:
SetHandler weblogic-handler
WebLogicCluster localhost:9001,localhost:9002
WLCookieName J2SESSIONID
Это, конечно, упрощенный пример конфигурации. Вы так не уверены, что продолжаете использовать проприетарный плагин, пока он работает, не смените ли команду-победительницу? Или перейдите к более открытому решению Apache.
Плагин weblogic «общается» с серверным кластером и обновляет список доступных серверных модулей для любого члена кластерных отчетов, например, у вас может быть несколько новых членов кластера, вообще не касаясь конфигурации, связанной с apache.
Oracle также рекламирует WLSRequest как более гибкий или менее сложный способ указать определенное местоположение обратных прокси-серверов для Weblogic, чем метод "SetHandler".
Сказав это, mod_wl является сторонним производителем, и до сих пор у него были доказанные проблемы с событием mpm, например, когда вы выпускаете изящный, он наверняка зависнет в конечном стиле изящного завершения, пока вы не выполните настоящий перезапуск, вы можете Также не используйте maxconnectionsperchild, иначе вы потеряете потомков из-за той же привязанности (я думаю, что разработчики httpd работают над этим в версии 2.4.33, которая скоро будет выпущена).
Итак, я бы просмотрел документы оракула и протестировал оба варианта, но в последнее время я также склоняюсь к выбору не третьей стороной, то есть к использованию mod_proxy.
Буду рад, если вы ответите после попытки.