Forum Discussion

Bret_McGinnis_1's avatar
Bret_McGinnis_1
Icon for Nimbostratus rankNimbostratus
Jan 09, 2006

Action On Service Down vs LB::reselect

Hi,

 

 

I would like to know the advantages/disadvantage and when I should use "Action On Service Down" vs LB::reselect. Things like:

 

 

- Performance diferences

 

- Does "Action On Service Down" have loop control?

 

- Should they be used together or are they generally mutualy exclusive

 

 

I am running 9.1 (expecting to upgrade to 9.1.1 soon). Not expecting to upgrade to 9.2 until 9.2.3

 

 

 

Regards,

 

 

Bret

 

 

4 Replies

  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Action on Service Down mainly effects existing connections to the server going down. You have three options - do nothing, send a reset to the client, rebind the connection to another server.

     

     

    LB::reselect can be used when the initial connection to a server does not connect (EG: in the LB_FAILED event). This allows you to override the destination of the incoming connection upon a failure - not reselecting will result in a reset to the client.

     

     

    So, these two methods apply to different situations and aren't mutually exclusion.

     

     

    HTH.
  • What occurs after the LB::reselect in the LB_FAILED event? Does it just reselect a server, or does it retrigger any of the prior events? I am trying to account for clients who don't allow cookies with this rule (I am using cookie insert persistence on the virtual as well)

    
    when HTTP_RESPONSE {
      if { [HTTP::cookie exists "JSESSIONID"] } {
        set trimID [lindex [split  [HTTP::cookie "JSESSIONID"] "!" ] 0 ]
        if { [session lookup uie $trimID] equals "" } {
          session add uie $trimID [IP::server_addr] 1800
          log "added server entry [session lookup uie $trimID] for jsessionID $trimID "
        } else {
          log "existing server entry [session lookup uie $trimID] for jsessionID $trimID"
        }
      }
    }
    when HTTP_REQUEST {
      if { [active_members MyPool] == 0 } {
        HTTP::redirect "http://[HTTP::header "X-Forwarded-Host"]/unavailable/unavailable.html"
      }
      if { [HTTP::header exists "X-Forwarded-Host"] } {
        HTTP::header replace "Host" [HTTP::header "X-Forwarded-Host"]
      }
      if { not [HTTP::cookie exists "MyCookie"] } {
        if {  [findstr [HTTP::uri] "jsessionid" 11 "!"]  != "" } {
          pool MyPool member [session lookup uie [findstr [HTTP::uri] "jsessionid" 11 "!"] ]
          log "jsessionID [findstr [HTTP::uri] "jsessionid" 11 "!"] sent to [session lookup uie [findstr [HTTP::uri] "jsessionid" 11 "!"] ]"
        } else {
          if { [HTTP::cookie exists "JSESSIONID"] } {
            log "used Cookie Insert, value is [HTTP::cookie "MyCookie"]"
          }
        }
      }
    }
    when LB_FAILED {
      LB::reselect pool MyPool
      LB::reselect
      log "server reselected due to failure!"
    }

    I am getting this error after the server fails:

    Jul 10 11:24:20 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected due to failure!

    Jul 10 11:24:20 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected due to failure!

    Jul 10 11:24:20 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected due to failure!

    Jul 10 11:24:20 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected due to failure!

    Jul 10 11:24:20 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected due to failure!

    Jul 10 11:24:23 tmm tmm[11686]: 01220002: repeated 56300 times

    My problem is that the pool member is set by the value in the session table, and the LB::reselect doesn't seem to reselect anything other than the failed instance. I have 16 members in the pool, all up except the instance we failed for testing. Any ideas?
  • I added some additional logging to confirm the same server is being selected, even though there are 15 other servers that could be tried:

     

     

     

    Jul 10 12:08:01 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected 10.28.199.183

     

    Jul 10 12:08:02 tmm tmm[11686]: 01220002: repeated 2 times

     

    Jul 10 12:08:03 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : jsessionID GylyPWny1tJKRwp1jlvvd3Kp5DH CYThCcJS2Y2JrlNhrMtB6GcJG sent to 10.28.199.183

     

    Jul 10 12:08:03 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected 10.28.199.183

     

    Jul 10 12:08:03 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : jsessionID GylyPWny1tJKRwp1jlvvd3Kp5DH CYThCcJS2Y2JrlNhrMtB6GcJG sent to 10.28.199.183

     

    Jul 10 12:08:03 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected 10.28.199.183

     

    Jul 10 12:08:06 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : jsessionID GylyPWny1tJKRwp1jlvvd3Kp5DH CYThCcJS2Y2JrlNhrMtB6GcJG sent to 10.28.199.183

     

    Jul 10 12:08:06 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected 10.28.199.183

     

    Jul 10 12:08:07 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected 10.28.199.183

     

    Jul 10 12:08:07 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected 10.28.199.183

     

    Jul 10 12:08:07 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected 10.28.199.183

     

    Jul 10 12:08:07 tmm tmm[11686]: 01220002:6: Rule intres_prod-rule : server reselected 10.28.199.183

     

    Jul 10 12:08:08 tmm tmm[11686]: 01220002: repeated 47 times

     

     

     

    I would imagine the above HTTP_REQUEST events are client retries, not events retriggered by the LB::reselect, correct? How do I get it to reselect another server?

     

     

    Also, I though once a node was marked down anything in the session table associated to that node was flushed?