Назад | Перейти на главную страницу

F5 BIG_IP постоянство iRules применено, но не влияет на выбранный член

У меня есть виртуальный сервер. У меня есть 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. Вы увидите, что запись была создана в этом случае.