Forum Discussion

Jason_22051's avatar
Jason_22051
Icon for Nimbostratus rankNimbostratus
Jul 16, 2014

"balance" issues with oneconnect

Hi I have a BigIP 3600 running TMOS 9.4.5. My setup is like this:

 

One Virtual server, standard tcp with an HTTP profile (modified only to add a fallback url) A oneconnect profile added to the virtual with the source mask changed to 255.255.255.255. Everything else is default A Universal persistence profile attached to an IRule with the following:

 

when HTTP_REQUEST { if { [HTTP::cookie exists "__appname"] } { persist uie [HTTP::cookie "__appname"] } } when HTTP_RESPONSE { if { [HTTP::cookie exists "__appname"] } { persist add uie [HTTP::cookie "__appname"] } }

 

A pool with 3 servers, using ratio member with each server having a ratio of 1 (round robin essentially)

 

The scenario: We keep 2 of the 3 servers in the pool at all times (the other is forced offline as a hot spare). During a release or issue with one of the other 2 servers, we will bring the third server online. During normal operation, servers A and B get ~5500 connections (because the default on oneconnect is 10K).

 

The problem: When we bring server C in and take server A out, we expect to see the BigIP balance the connections between B and C "evenly" (within an acceptable margin). What we actually see if server B gets 11K+ connections and server C hovers around 50.

 

Anyone know why this is and what, if anything can be done to force the balance. If you need more information, please let me know.

 

TIA

 

2 Replies

  • shaggy's avatar
    shaggy
    Icon for Nimbostratus rankNimbostratus

    Persistence will almost always result in uneven load distribution among pool members. If user sessions are long-lived, then they will continue to persist to servers A and B even if server C has a much lower connection count. What is the timeout of the universal persistence profile assigned to the virtual server, what is the average/normal user-session duration, and how long does C hover around 50 connections?

     

  • Shaggy,

     

    Thanks for your response. I realize that persistence will result in uneven distribution. However I don't think the problem here is actually persistence. I think it's oneconnect. Basically the problem as I see it is that oneconnect isn't running against server C. The connections aren't being kept open like they are on A and B