F5 BIG_IP persistência iRules aplicados, mas não afetando o membro selecionado

Question

Eu tenho um servidor virtual. Eu tenho 2 iRules (veja abaixo) atribuídos a ele como recursos.

No log do servidor, parece que as regras estão em execução e selecionam o membro correto

do pool depois de persistir a sessão (até onde posso dizer com base nas minhas mensagens de log), mas as solicitações são direcionadas para algum outro lugar.

Veja como as duas regras se parecem:

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>"
  }
}

De acordo com as mensagens de log das regras, os membros do balanceador adequados são selecionados.

Nota: as duas regras não podem entrar em conflito, elas estão procurando por coisas diferentes no caminho. Essas duas coisas nunca aparecem no mesmo caminho.

Notas sobre o servidor: * O método de balanceamento de carga padrão é RR. * Não há perfil de persistência atribuído ao servidor virtual.

Gostaria de saber se isso deve ser adequado para ativar a persistência ou, como alternativa, preciso combinar as duas regras e criar um perfil de persistência com elas para o servidor virtual?

Ou há algo mais que eu perdi?

Edit: como se vê, eu perdi alguma coisa. Conexões keep-alive interferir com as regras, assim como este caso de suporte sugerido, eu ' ve modificou um pouco as regras:

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>"
  }
}

    

Answer 1

Então, quando você está vendo as entradas de log, está vendo as informações esperadas, mas o tráfego ainda está chegando em algum outro lugar? Onde está acabando? Além disso, por que duas entradas de persistência para a mesma sessão? Isso pode confundir o sistema.

Você não deve precisar de um perfil de persistência atribuído ao Virtual, o iRule deve substituí-lo de qualquer maneira, se você tiver persistência configurada lá. Como são suas entradas de log? Além disso, você já postou no DevCentral? Mais pessoas com experiência em F5 podem vê-lo lá. - link

Já tentou alterar os nomes das variáveis? Você está usando "sessionID" como o nome da variável nos dois casos. Variáveis dentro de iRules são baseadas em sessão, o que significa que, durante a duração da sua sessão com o sistema, as variáveis permanecem fixas na memória. Se você tiver as duas iRules em execução, estará sobrescrevendo o mesmo nome de variável com dados para a solicitação e a resposta, o que poderia fazer com que sua lógica verificasse se o sessionID está vazio. Ou seja, se o sessionID for definido a pedido, mas não a resposta, mas a resposta executar a verificação de código para ver se está vazia ... não vai falhar da maneira que você deseja. Nomes de variáveis diferentes são boas.

Fora isso, sua sintaxe está correta e, a menos que o problema esteja causando confusão, parece que o problema não é com as próprias iRules, mas com a maneira como a persistência está interagindo com as solicitações.

Colin

    

Answer 2

Nessa situação, na primeira solicitação HTTP, você nunca registrará a entrada de persistência correta com base na iRules acima. O motivo para isso é que a persistência é definida em outro evento mais tarde, porque o F5 ainda não decidiu qual membro do conjunto será carregado. Como essa decisão não foi tomada, é impossível criar a entrada de persistência ainda. Isso significa que durante a vida de todo o evento HTTP_REQUEST, você nunca poderá recuperar o valor de persistência. Você só pode fazer isso após o evento HTTP_REQUEST ter sido concluído e o próximo evento ser disparado. É por isso que estava funcionando, mesmo que você não estivesse vendo os dados de depuração esperados. Em vez disso, tente verificar em LB_SELECTED. Você verá que a entrada foi criada nesse evento.