Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Nov 04, 2011

OneConnect and Persistence for HTTP App

We've got an HTTP web service which is getting really uneven load distribution, to the point of causing outage on some of the pool members. The clients of the web service do not support Cookies (they do not honor the Set-Cookie header), so we have been resigned to using Source Address. The problem is that much of the load is coming from multiple applications on a single source address, and I need to come up with a way to more evenly distribute the load with the LTM. So my thought is to use OneConnect. Since the documentation seems to be written for a different use case, I can't quite get a handle on how it works exactly so I'm not sure if it would resolve the issue or not.

 

 

When I apply a OneConnect profile to an HTTP VS, *my understanding* of the doc is that the LTM makes load-balancing decisions on a "per-request" basis. If that's true, what I can't figure out is how the LTM keep track of which pool member any particular request was sent to - what in the request does the LTM keep track of, and where is it stored?
config
design

18 Replies

Sort By
Show More
  • Chris_Miller's avatar
    Chris_Miller
    Icon for Altostratus rankAltostratus
    Nov 13, 2011
    Posted By smp on 11/10/2011 05:51 AM

     

    So without OneConnect, the LTM sets the cookie on the first L7 response, only looks at the cookie value in the next L7 request, and then ignores the persistence cookie for subsequent L7 requests? And with OneConnect, the persistence cookie value is evaluated in each L7 request?

     

    The best way to put it is to say that OneConnect ensures that every L7 request is evaluated. The same can't be guaranteed without it.
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Nov 28, 2011
    Just to stick my nose in here, "OneConnect ensures that every L7 request is evaluated" is a pretty bad way to think about OneConnect.

     

     

    There are two different issues, which admittedly behave differently, which OneConnect is involved in that are not obvious.

     

     

    First is persistence. As you correctly state, without OneConnect, you're load-balancing connections, not requests, so the persistence cookie will only be evaluated once per connection. With OneConnect, you're load-balancing requests, so each request will will have its persistence cookie evaluated. See sol7964 for more on this.

     

     

    Second is selecting a pool via iRules. With OneConnect, the default pool from the profile is started with for each request (again, since OneConnect load-balances requests, not connections). Without OneConnect, it isn't: the pool is only changed via iRule command. So if you have some giant switch statement or block of if {} tests, and you *don't* have a default clause which uses the pool command to explicitly choose the default pool, then OneConnect can cause a change in behavior.

     

     

    But with or without OneConnect, every L7 request is always evaluated. iRule events will fire, HTTP profile settings will take effect, etc.