2009-12-09 2 views
0

Если два сервера настроены между балансировщиком нагрузки и кластером weblogic, будут ли два сервера Apache поддерживать липкость сеанса?Плагин Weblogic Apache и липкость сеанса

Скажем, например, балансировщик нагрузки пересылает первый запрос на 1-й апач и, в свою очередь, 1-й апах переходит в 1-й управляемый экземпляр WL. Даже если второй запрос от одного и того же пользователя перенаправляется балансировщиком нагрузки на второй apache, второй apache сможет перенаправить его в 1-й экземпляр WLManaged, который обслуживал первый запрос, а не второй экземпляр WLManaged, который не знает информацию о сеансе.

В чем должно быть идеальное поведение плагина weblogic apache? Уловка: я не хочу включить репликацию сеанса в кластере серверов wl.

ответ

7

Согласно разделу «Failover, Cookies, and HTTP Sessions» в HTTP-сервер Apache Plug-In:

Когда запрос содержит информацию о сеансе связи, хранящейся в куки или в данных POST или закодированную в URL, сессия Идентификатор содержит ссылку на конкретный экземпляр сервера, в котором первоначально был установлен сеанс (называемый основным сервером), и ссылка на дополнительный сервер, на котором реплицируется исходный сеанс (называемый вторичным сервером). Запрос, содержащий куки-файл, пытается подключиться к основному серверу. Если эта попытка не удалась, запрос перенаправляется на вторичный сервер. Если оба первичных и вторичных сервера терпят неудачу, сеанс потерян, и подключаемый модуль пытается установить новое соединение с другим сервером в списке динамических кластеров. См. Figure 3-1 Connection Failover.

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

Рисунок 3-1 отказоустойчивого соединения

alt text http://download.oracle.com/docs/cd/E13222_01/wls/docs100/plugins/wwimages/failover.gif

Другими словами, да, оба сервера Apache будет иметь возможность направить входящий запрос на "право", например, как WebLogic идентификатор сеанса содержит всю необходимую для этого информацию. Обратите внимание, что нет реальной необходимости подтверждать это с помощью тестирования, но это было бы очень легко.

UPDATE: Ответ на следующий комментарий от OP

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

Я понял, что вы используете два шрифта apache, и я не уверен, что этот документ относится к конфигурации только с одним сервером Apache. Как объяснено, идентификатор сеанса содержит ссылку на первичный сервер (и на вторичный сервер), поэтому оба apache должны иметь возможность справиться с этим. По крайней мере, это мое понимание. На самом деле, я работал с аналогичной конфигурацией в прошлом, но не могу вспомнить, работали ли они так, как мне кажется, или если балансировщик нагрузки настроен так, чтобы обрабатывать липкость (т. Е. Перенаправить на заданный сервер Apache). Сейчас у меня есть немного сомнений ...

Могла ли ваша конфигурация плагина (как для сервера Apache, если они отличаются)? Не могли бы вы также подтвердить, что все работает как ожидалось, когда работает только один сервер Apache (и проверяйте это с помощью обоих apache, если их конфигурация отличается, что не должно быть так)?

1

Когда у вас есть два экземпляра Apache с балансиром нагрузки TCP спереди, диаграмма состояния больше не применима, поскольку экземпляры Apache не делят свои состояния. Я предполагаю, что плагин WebLogic поддерживает состояние с направленным отображением [IPAddress + Port -> JVMID]. Если он получает файл cookie с JVMID, он еще не знает (например, он еще не отправил запрос на этот сервер), он не знает, к какому IPAdress + порту он относится, поэтому он не сможет повторите использование этого JVMID, и он переназначит новые первичные/вторичные, которые будут идентичны для двух экземпляров (возможно, поменялись местами), и которые могут отличаться, если существует более двух экземпляров. Я не подтвердил это, выполнив определенные тесты, но на бумаге он, кажется, не работает во всех случаях.

0

Диаграмма выше верна для 2 серверов Apache, подключенных к одному кластеру WL. Информация о сессии cookie содержит сведения о том, к чему подключается WLS, и плагин будет уважать это. Если основной (сервер, который он первоначально подключил) к серверу WL не доступен, запрос будет отправлен на вторичный сервер (обозначенный таким образом во время первого запроса на основе правил, определенных при выборе «Preferred Replication Group») , Этот вторичный сервер поддерживает то же состояние сеанса, что и основной сервер WLS, и должен иметь возможность обрабатывать запрос.

Если репликация сеанса не настроена (по-моему, это отключено по умолчанию), то сеанс не будет скопирован на другой сервер, а если исходный/первичный WL-сервер опустится, вы потеряете сеанс.

0

Ответ НЕТ. Поскольку у вас есть 2 веб-сервера Apache, вам необходимо внедрить липкость как на уровне оборудования, так и на уровне программного обеспечения, чтобы достичь ваших требований.

У вас уже есть липкий сеанс, реализованный в плагине Weblogic для уровня Apache, но вам также нужна липкость на основе исходного IP-адреса на уровне аппаратного loadbalancer. Это позволит вашему аппарату loadbalancer отправлять последующий запрос от одного и того же пользователя на тот же самый веб-сервер.

1

Ответ да. У нас есть запись об этом в нашем блоге http://blog.c2b2.co.uk/2012/10/basic-clustering-with-weblogic-12c-and.html, в котором содержатся пошаговые инструкции по настройке перебора сеансов веб-сеанса в кластере.

По сути, cookie jsessionid кодирует первичный и вторичный сервер веб-журнала. Mod-wl анализирует файл cookie и направляет запрос на основной сервер. В вашем случае Управляемый сервер 1. Если он отключен, он автоматически направит запрос на сервер резервного копирования Управляемый сервер 2.

Смежные вопросы