Forum Discussion

Craig_Hammer_10's avatar
Craig_Hammer_10
Icon for Nimbostratus rankNimbostratus
May 03, 2005

Need suggestions on selection of alternate pool

I have a multi-tier application that has somewhat regular traffic spikes. The web servers can handle anything I throw at them, but the 2nd-tier application runs out of horsepower.

 

 

I want to track / test something and based on the result, send additional traffic to another pool, but maintain (persist) all the sessions that had gone to the original pool.

 

 

I can insert a cookie, or insert the ssl header (this app is ssl proxied by the BigIP), so I don't really have a problem with the persistance part, but I can not figure out how to send connection X+1 to a different pool.

 

 

Has anyone done something similar?

4 Replies

  • drteeth_127330's avatar
    drteeth_127330
    Historic F5 Account
    Let me make sure I understand. If a new connection has a persistence entry, then you want to do session persistence. However, you might want to send new connections to a different pool. Correct?

     

     

    Write a load-balancing rule to choose the pool accordingly. Add a persistence profile to the virtual for the persistence mode that you want to use. Be sure to enable persistence across pools on the profile. I think the across pools option was tripping you up. Without it, we would create a new peristence entry if the load-balancing rule were to select a different pool for a connection that already had a persistence entry.
  • If you have hard limits on the number of connections each server can support, it is better to define these on the node definition. Use the Connection Limit setting. I try to use the iRules only when a standard feature can't do the job.
  • drteeth_127330's avatar
    drteeth_127330
    Historic F5 Account
    citizen_elah is correct. The connection limits only apply to the NEW connections that do not have a session persistence entry.

     

     

    Using a different metric other than the number of connections is tricky because it's tough to inject metrics into the data-plane for LB decisions. You might be able to do this with dynamic ratio load-balancing. That is, you should be able to set the node ratio to zero if its max load is exceeded. If that is the case, the node won't be selected for new connections, but persistent connections will continue to use it. Note that this is different than marking the node down. You can direct traffic to a sorry page using either an LB_FAILED rule or an HTTP fallback host.