Forum Discussion

jdekrnl_118963's avatar
jdekrnl_118963
Icon for Nimbostratus rankNimbostratus
Aug 06, 2013

Rewrites to different virtual servers

I was wondering if any of you may have any suggestions on how to solve a desgin problem. The attached picture may give an idea of our current set up. I am new to F5, so I apologize if this is a trivial question.

 

We have two application servers (node1, node2), each with two instances of the same web application (two ports). For various reasons they cannot be included in a single pool. Our strategy was to create two separate pools (pool1, pool2) and virtual servers (VS01, VS02) per port, as well as a frontend virtual server (VS00) that distributes requests via a round robin iRule using http redirect.

 

For the most part the design works fine. Client1 sends request to "", which resolves to VS00, gets redirected to VS01 and the address bar in the browser reflects the redirect showing "http://10.1.11.81:8081/login.jsp". Client2 sends in a new request to "", gets redirected to VS02, and its address bar shows "http://10.1.11.81:8082/login.jsp", and so forth.

 

My question is what needs to be changed so that the address showing in the browser displays "" instead of host name. I gather that all traffic will have to go through VS00 (instead of simpling redirecting requests). If we decide to use ProxyPass to accomplish this, what suggestions can you offer to implement the round robin function? Could it be done with simple http redirects instead to eliminate complexity?

 

Any suggestions will be greatly appreciated.

 

config
design

10 Replies

Sort By
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Aug 06, 2013

    Can you elaborate on why "they cannot be included in a single pool"? Also, how are you deciding which virtual to redirect a new user to?

     

    You could, technically, use VIP targeting inside your "round robin iRule", using client side cookies (as an example) to track persistence. This would allow you to simply forward the request to the internal VIP without redirecting the client.

     

  • jdekrnl_118963's avatar
    jdekrnl_118963
    Icon for Nimbostratus rankNimbostratus
    Aug 06, 2013
    The limitation is due to stability and manageability (also scalability). Right now, the iRule is doing a simple round robin between the virtual servers. Thanks.
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Aug 06, 2013
    The limitation is due to stability and manageability (also scalability)

     

     

    Perhaps a ratio-based LB method and/or more aggressive monitoring would be a better option?

     

     

    Otherwise, there are at least two options:

     

     

    1. iRule-based round robin to separate pools - using the "pool" command

     

     

    2. iRule-based round robin to separate VIPs (VIP targeting) - using the "virtual" command

     

     

    In both case above you need to decide in your iRule 1) where you're sending a user, 2) what you're basing persistence on (a client side cookie), and 3) where you're going to store this persistence information (a session table probably). If you let us see your iRule we should be able to help make the modifications.

     

  • jdekrnl_118963's avatar
    jdekrnl_118963
    Icon for Nimbostratus rankNimbostratus
    Aug 06, 2013
    Yes, we are using cookie as persistence type. I was under the impression that you could only use the pool command within the same virtual server.

     

     

    Here is the simple iRule that currently does the round robin redirectd:

     

     

    when RULE_INIT {

     

    set ::lb_counter 1

     

    }

     

    when HTTP_REQUEST {

     

    if { $::lb_counter == 1 } {

     

    HTTP::redirect http://10.1.10.11:8081

     

    set ::lb_counter 2

     

    return

     

    } elseif { $::lb_counter == 2 } {

     

    HTTP::redirect http://10.1.10.12:8082

     

    set ::lb_counter 1

     

    }

     

    }
  • jdekrnl_118963's avatar
    jdekrnl_118963
    Icon for Nimbostratus rankNimbostratus
    Aug 06, 2013
    Just replaced the http redirects with virtual commands and it works fine now. Thanks!!

     

     

    when RULE_INIT {

     

    set ::lb_counter 1

     

    }

     

    when HTTP_REQUEST {

     

    if { $::lb_counter == 1 } {

     

    virtual VS01

     

    set ::lb_counter 2

     

    return

     

    } elseif { $::lb_counter == 2 } {

     

    virtual VS02

     

    set ::lb_counter 1

     

    }

     

    }
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Aug 06, 2013
    This is a crude example, but I think close to what you're trying to accomplish: 

    
when RULE_INIT {
set ::lb_counter 1
}
when HTTP_REQUEST {
if { not ( [HTTP::header Cookie] contains "BIGipServer" ) } {
if { $::lb_counter == 1 } {
pool port-8081-pool
log local0. "sending to port-8081-pool"
set ::lb_counter 2
return
} elseif { $::lb_counter == 2 } {
pool port-8082-pool
log local0. "sending to port-8082-pool"
set ::lb_counter 1
}
}
}

    Create two pools (example: "port-8081-pool" and "port-8082-pool") and apply the built-in cookie persistence profile to the the VS00 virtual server. On first request the client will not present a BIG-IP persistence cookie and get round robin load balanced to one of the pools. LTM will then inject that pool's persistence information into the first response to the client. Subsequent requests will contain the "BIGipServer" cookie and bypass the round robin function in favor the of the cookie's persistence information.

    You could do something similar with VIP targeting, but you'd need to handle persistence a little more manually. The real benefit of VIP targeting is that each internal VIP could have its own unique configurations and iRules.

  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Aug 07, 2013
    just a small comment.

     

     

    set ::lb_counter 1 you may change this to static global variable (i.e. static::lb_counter). it will make the irule cmp compatible.

     

     

    when changing static global variable value, the change will apply to local tmm only. since we assume traffic is distributed to all tmm equally, load balancing should still be considered round robin.

     

     

    just my 2 cents.