Существующее соединение на Apache и mod_proxy_balancer не перестает работать на втором узле JBoss

У меня есть ферма Jboss, балансировка нагрузки по Apache HTTP + mod_proxy_balancer и mod_proxy_ajp со следующей конфигурацией:

<VirtualHost *:80>

    ServerName web-gui-acceptance.myorg.com
    ServerAlias web-gui-acceptance


    ProxyRequests Off
    ProxyPass /web-gui balancer://jbosscluster/web-gui stickysession=JSESSIONID nofailover=On
    ProxyPassReverse /web-gui http://srvlnx01.myorg.com:8080/web-gui
    ProxyPassReverse /web-gui http://srvlnx02.myorg.com:8080/web-gui

    <Proxy *>
      AuthType Kerberos
      [...]
    </Proxy>

    <Proxy balancer://jbosscluster>
        BalancerMember ajp://srvlnx01.myorg.com:8009 route=SRVLNX01_node1
        BalancerMember ajp://srvlnx01.myorg.com:8009 route=SRVLNX02_node1
        ProxySet lbmethod=byrequests
    </Proxy>

</VirtualHost>

Когда происходит сбой первого узла JBoss (виртуальная машина хоста не работает), мои существующие соединения не перестают работать на втором узле... Первый маршрут сохраняется (в таблице / .shm?), И это дает мне 503 ошибки.

Может кто-нибудь сказать мне, что я пропустил?

Источник

1 ответ

Решение

Возможно, я нашел обходной путь, который также связан с развертыванием / отменой развертывания: http://www.jboss.org/mod_cluster

преимущества

Модуль mod_cluster имеет следующие преимущества по сравнению с другими балансировщиками нагрузки на основе httpd:

Динамическая конфигурация работников httpd

Традиционные балансировщики нагрузки на основе httpd требуют явной настройки рабочих, доступных для прокси. В mod_cluster основная часть конфигурации прокси находится на серверах приложений. Набор прокси-серверов, с которыми сервер приложений будет связываться, определяется либо статическим списком, либо с помощью динамического обнаружения с помощью механизма рекламы. Сервер приложений передает события жизненного цикла (например, запуск / выключение сервера) прокси, что позволяет им автоматически автоматически настраиваться. Примечательно, что постепенное отключение сервера не приведет к ответу отработки отказа прокси-сервером, как в случае традиционных балансировщиков нагрузки на основе httpd.

Расчет коэффициента нагрузки на стороне сервера

В отличие от традиционных балансировщиков нагрузки на основе httpd, mod_cluster использует коэффициенты балансировки нагрузки, рассчитанные и предоставляемые серверами приложений, а не вычисляя их в прокси. Следовательно, mod_cluster предлагает более надежный и точный набор показателей нагрузки, чем доступен через прокси. (см. Load Metrics для более подробной информации)

Тонкое управление жизненным циклом веб-приложения

Традиционные балансировщики нагрузки на основе httpd не особенно хорошо справляются с развертыванием веб-приложений. С точки зрения прокси-сервера запросы к неразвернутому веб-приложению неотличимы от запроса на несуществующий ресурс и приведут к 404 ошибкам. В mod_cluster каждый сервер перенаправляет любые события жизненного цикла контекста веб-приложения (например, развертывание / отмена развертывания веб-приложения) на прокси-сервер, информируя его о необходимости запуска / остановки запросов маршрутизации для данного контекста на этот сервер.

AJP не является обязательным

В отличие от mod_jk, mod_cluster не требует AJP. Соединения httpd с узлами сервера приложений могут использовать HTTP, HTTPS или AJP. Оригинальные концепции описаны в вики.

Я надеюсь, что это поможет.

Источник
Другие вопросы по тегам