http redirect load balacing based on pool member health with session persistence

What do you mean by "The app itself isn't capable of being load balanced"? Isn't that what the solution will be doing? Look into using CARP hash persistence if you want the user to always go to the same server unless it is offline. ">https://support.f5.com/kb/en-us/solutions/public/11000/300/sol11362.html" target="_blank">">https://support.f5.com/kb/en-us/solutions/public/11000/300/sol11362.html.

I'm familiar with CARP, i can use this, although it would still need to be done within the irule.

A little bit more information on the app. The F5 will not be able to terminate the http session and route traffic to the appropriate pool member as in a traditional load balanced sense. The F5 will have a listening VIP, and issue an http redirect to the user for one of the pool members directly. After the redirect is issued, the user will talk directly to the target server for the duration of his session. When a new session starts, they will hit the VIP again, and if the same target server is online will be routed back to it (using CARP persistence).

My thought is the persistence would have to be built into the irule as the logic to issue an http redirect is performed there.

I like the idea of a datagroup for this. Based on the returned name of the LB:server name or even addr i can use the correct value redirect. I attempted to dump out the LB::server name but continue to get null values within HTTP_REQUEST so i have nothing to compare them to in the data group.

when HTTP_REQUEST {
        log local0. "LB Server name: [LB::server name]"
        log local0. "LB Server addr: [LB::server addr]"
        HTTP::redirect [class lookup [LB::server name] "test.data.group"]
}

I will get log entries like: Dec 8 16:03:29 devicename info tmm[11799]: Rule /Common/irule : LB Server name: /Common/poolname 0 Dec 8 16:03:29 devicename info tmm[11799]: Rule /Common/irule : LB Server addr: Dec 8 16:03:29 devicename info tmm[11799]: Rule /Common/irule : LB Server name: /Common/poolname 0 Dec 8 16:03:29 devicename info tmm[11799]: Rule /Common/irule : LB Server addr:

I think this is because the decision to use a specific pool member hasn't been made yet. I started looking at performing the same function within HTTP_REQUEST_SEND event using the client side context.

    when HTTP_REQUEST_SEND {
clientside {
        log local0. "LB Server name: [LB::server name]"
        log local0. "LB Server addr: [LB::server addr]"
    HTTP::redirect [class lookup [LB::server name] "test.data.group"]
}
}

This resulted in me being able to dump the values of LB::server name and addr, but not able to execute the redirect. Logs are:

Dec 8 16:04:42 devicename info tmm2[11799]: Rule /irule : LB Server name: /Common/poolname 1.1.1.1 80 Dec 8 16:04:42 devicename info tmm2[11799]: Rule /Common/irule : LB Server addr: 1.1.1.1 Dec 8 16:04:42 devicename err tmm2[11799]: 01220001:3: TCL error: /Common/irule - Illegal argument. Can't execute in the current context. (line 1) invoked from within "HTTP::redirect [class lookup [LB::server name] "test.data.group"]"

Try using the following. I should have used this even in my original post.

when LB_SELECTED {
    log local0. "LB Server name: [LB::server name]"
    log local0. "LB Server addr: [LB::server addr]"
    HTTP::redirect [class lookup [LB::server name] "test.data.group"]
}

compile error :(

01070151:3: Rule [/Common/irule] error: /Common/irule:4: error: [command is not valid in current event context (LB_SELECTED)][HTTP::redirect [class lookup [LB::server name] "test.data.group"]]

as you know, server is not yet picked up in HTTP_REQUEST. anyway, you can force it using LB::select (in HTTP_REQUEST), parse server address from the return string and then use it in HTTP::redirect.

LB::select

excellent thanks for the help nitass and Brad. I was able to utilize LB::select to make the lb decision early and compare against my data group for the correct redirect.

Code i'm using is as follows:

  when HTTP_REQUEST {
   check if serverside connection had previously been established
  if { [LB::server addr] eq "" }{
     if no serverside connection had previously been established, force one
     so the irule has the info required to use in the match against the data
     group
    eval [LB::select]
  }
 log local0. "Source Client IP: [IP::client_addr]"
 log local0. "LB Server name: [LB::server name]"
 log local0. "LB Server addr selected: [LB::server addr]"
 perform the data group class lookup matching the selected server address to issue the 
 appropriate HTTP redirect
  HTTP::redirect [class lookup [LB::server addr] "data.group.name"]
}