У меня есть виртуальный сервер. У меня есть 2 iRule (см. Ниже), назначенных ему в качестве ресурсов.
Из журнала сервера похоже, что правила работают, и они выбирают правильный член
из пула после сохранения сеанса (насколько я могу судить на основе сообщений журнала), но запросы в конечном итоге направляются куда-то еще.
Вот как выглядят оба правила:
when HTTP_RESPONSE {
set sessionId [HTTP::header X-SessionId]
if {$sessionId ne ""} {
persist add uie $sessionId 3600
log local0.debug "Session persisted: <$sessionId> to <[persist lookup uie $sessionId]>"
}
}
when HTTP_REQUEST {
set sessionId [findstr [HTTP::path] "/session/" 9 /]
if {$sessionId ne ""} {
persist uie $sessionId
set persistValue [persist lookup uie $sessionId]
log local0.debug "Found persistence key <$sessionId> : <$persistValue>"
}
}
В соответствии с сообщениями журнала из правил выбираются соответствующие элементы балансировщика.
Примечание: эти два правила не могут конфликтовать, они ищут разные вещи на своем пути. Эти две вещи никогда не появляются на одном и том же пути.
Примечания о сервере: * Метод балансировки нагрузки по умолчанию - RR. * Виртуальному серверу не назначен профиль сохраняемости.
Мне интересно, должно ли этого быть достаточно для включения сохраняемости или, альтернативно, мне нужно объединить 2 правила и создать с ними профиль сохраняемости для виртуального сервера?
Или я что-то еще пропустил?
Изменить: как оказалось, я что-то упустил. Активные соединения нарушают правила, так как этот предложен случай поддержки, я немного изменил правила:
when HTTP_REQUEST {
set sessionId [findstr [HTTP::path] "/session/" 9 /]
if {$sessionId ne ""} {
# added this line:
LB::detach
persist uie $sessionId
set persistValue [persist lookup uie $sessionId]
log local0.debug "Found persistence key <$sessionId> : <$persistValue>"
}
}
Итак, когда вы просматриваете записи журнала, вы видите ожидаемую информацию, но трафик все еще попадает в другое место? Где это в итоге? Кроме того, почему две записи о постоянстве для одного сеанса? Это может сбивать с толку систему.
Вам не нужен профиль постоянства, назначенный виртуальному серверу, iRule все равно должен его переопределить, если у вас там настроено постоянство. Как выглядят ваши записи в журнале? Кроме того, вы уже писали на DevCentral? Там его могут увидеть больше людей с опытом F5. - http://devcentral.f5.com
Вы пробовали изменить имена переменных? В обоих случаях в качестве имени переменной используется «sessionID». Переменные в iRules основаны на сеансах, что означает, что в течение всего сеанса с системой переменные остаются закрепленными в памяти. Если у вас выполняются оба этих iRule, вы перезаписываете одно и то же имя переменной данными как для запроса, так и для ответа, что может сделать вашу логическую проверку, чтобы увидеть, пустой ли идентификатор сеанса, бесполезным. Это означает, что если идентификатор сеанса устанавливается по запросу, но не по ответу, но в ответе выполняется проверка кода, чтобы увидеть, является ли он пустым ... он не потерпит неудачу так, как вы этого хотите. Разные имена переменных - это хорошо.
Тем не менее, в остальном ваш синтаксис правильный, и, если эта проблема не вызывает путаницу, похоже, проблема не в самих iRules, а в том, как постоянство взаимодействует с запросами.
Колин
В этой ситуации при самом первом HTTP-запросе вы никогда не будете регистрировать правильную запись о постоянстве на основе вышеуказанных iRules. Причина этого заключается в том, что сохранение устанавливается в другом событии позже, поскольку F5 еще не решил, для какого члена пула этот запрос будет балансировать нагрузку. Поскольку это решение еще не принято, создать запись о постоянстве пока невозможно. Это означает, что в течение всего события HTTP_REQUEST вы никогда не сможете получить значение сохраняемости. Вы можете сделать это только ПОСЛЕ завершения события HTTP_REQUEST и возникновения следующего события. Вот почему он работал, даже если вы не видели ожидаемых данных отладки. Вместо этого попробуйте проверить это в LB_SELECTED. Вы увидите, что запись была создана в этом случае.