Forum Discussion

jkstraw_44238's avatar
jkstraw_44238
Icon for Nimbostratus rankNimbostratus
Oct 09, 2007

redirect to maint. page

Hello,

I have read a number of posts on how this can be done based on a pool being down but I think my situation/requirement may be unique.

We are running a JBoss/Tomcat webapp where there are multiple customers on the same domain (virtual server) - only differentiated by their unique URI.

To accomplish the load balancing we implemented an irule that looks like this:


when HTTP_REQUEST {  
set http_request_time [clock clicks -milliseconds]
set request_log_line "[HTTP::request_num] - [IP::remote_addr] - [HTTP::method] - [HTTP::version] - [HTTP::host] - \
\"[HTTP::uri]\" - \"[HTTP::header value Referer]\" - \"[HTTP::header User-Agent]\" - \"[HTTP::cookie value JSESSIONID]\" - \
[SSL::cipher name] - [SSL::cipher version] - [SSL::cipher bits]"
switch -glob [string tolower [HTTP::uri]] {    
               "/test01*" {
                        use pool cluster01
               }
               "/test02*" {
                        use pool cluster02
                }
        "/test03*" {
use pool cluster01
}
"/test04*" {
use pool cluster02
}
                "/test05*" {
                        use pool cluster01
                }
"/*" {                
                        set resp_url "http://www.somedomain.com"
                        TCP::respond "HTTP/1.1 302 Found\r\nLocation: $resp_url\r\nConnection: close\r\nContent-Length: 0\r\n\r\n"
                        TCP::close
}
}
}
when HTTP_RESPONSE {
set http_response_time [clock clicks -milliseconds]
   log local0. "$request_log_line - [HTTP::status] - [HTTP::payload length] - [expr $http_response_time - \
$http_request_time] -  pool [LB::server pool] - node [LB::server addr]"
}

Part of our ongoing procedures is to patch existing clients to new versions of our software - to do this we undeploy the webapp, patch it and then redeploy the webapp.

I am trying to find a way to have the LTM automatically redirect traffic to a maintenance page when the webapp becomes unavailable (ie. has been undeployed by our patching script).

The posts I have read in the forum so far have a dependency on a pool or pool member health check report as being down - thus triggering the redirect portion of the rule. However in our case all pool members are still available, as is the backend application server - the webapp simply is not deployed.

I had thought about having the redirect trigger on certain HTTP response codes (eg. 404) but I don't think this is feasible because certain parts of the app throw the 404 out as part of normal operating functions.

Does anyone have any ideas on how I could accomplish this functionality?

5 Replies

  • We use Tomcat as well, I use the following irule for when we do deploy's.

    
    when CLIENT_ACCEPTED {
     set myretry 0
    }
    when HTTP_REQUEST {
     set myrequest [HTTP::request]
    }
    when HTTP_RESPONSE {
     if { [HTTP::status] == 503 }{
      if {($myretry < 3) } {
       log "got a 500... retrying, myretry == $myretry The request was $myrequest"
       incr myretry
       HTTP::retry $myrequest  
      }
      else { 
       log "Going to maint because all servers are serving 503's, myretry == $myretry"
       HTTP::redirect http://maint.my.com/
      }
     }
    }
    when LB_FAILED {
     set mypool [LB::server]
     log "$mypool seems to be having a problem..., going to the maint page myretry == $myretry"
     log "$myrequest"
     if { [active_members $mypool] < 1 } {
      log "Going to maint because all servers are down"
      HTTP::redirect http://maint.my.com/
     }
    }
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    If the web app is "not deployed", I'm going to go out on a limb & assume that the webserver is not serving the expected content (hence the reference to 404's while in that state).

     

     

    If that's the case, all you'd need to do would be to configure an HTTP monitor against the webservers that requests a specific page and looks for a specific string on that page. The optimal monitor would request a page that runs a dynamic query against the app, which will result in the expected string NOT being returned when the app is un-deployed, thus the affected pool members would be marked DOWN and no traffic would be LB to them.

     

     

    Then you'd also configure a fallback host in the HTTP profile. The value of the Fallback host field would be the fully qualified URL of the maintenance page to which you want to redirect users when all the servers are marked DOWN by this monitor.

     

     

    (No iRule required. Simpler is usually better.)

     

     

    HTH

     

    /deb
  • We do this as well, some small script that hits the db and if okay then creates some string.

     

     

    The problem with this is that the f5 monitors will take some time to fail the server (16 seconds by default), the irule will do this immediately.
  • LB::server returns too much.

     

     

    I have found that I needed to use

     

     

    set mypool [getfield [LB::server] " " 1]
  • Is there a functional/buggy reason why [getfield [LB::server] " " 1] is used instead of [LB::server pool]?