Forum Discussion

Ichnafi's avatar
Ichnafi
Icon for Cirrostratus rankCirrostratus
Feb 28, 2019

Loadbalancing a 2-stage proxy environment - persistence problems

Hello fellow F5-experts,

My situation:

I try to loadbalance Web-Proxy traffic. In genenal it seems to work, but we've run into some problems relating to websites with weird session handling. I sketched up the environment in the following Image

A clients uses VS-A as it's HTTP proxy. This VS loadbalances to two of our own proxies in Pool A. Those are not transparent, so outgoing traffic toward their upstream proxy (VS-B) will have the Pool A node's IP as source address. The Proxies use the HTTP: Connect method.

VS-B on the other hand, has a Pool B attached with a lot (as in really a lot) other proxy servers, that are not under our control (but are trustworthy, and have to be used. No way around it).

VS-A:

  • Type Standard
  • HTTP-Profile: http-transparent (to be able to use LB method Fastest (node))
  • Source Address Translation: none
  • Default Persistence Profile: source_addr

Pool A:

  • LB Method: Fastest (node)

VS-A:

  • Type Standard
  • HTTP-Profile: http-transparent (to be able to use LB method Fastest (node))
  • Source Address Translation: SNAT
  • Default Persistence Profile: none

Pool B:

  • LB Method: Fastest (node)
Problem:

On some websites, people complain about loosing their sessions. I tracked it down to the VS-B, which can not persist connections to a website to the same node in Pool B. Since the VS-B does not see the original client IP, but only the 2 proxy IP's I have no idea how to establish a propper persistence. For a very important website, i wrote an iRule that "hard-binds" to a single Node in Pool B, based on the HTTP:URI.

My question:

Is my config any viable? Or what should I change? I read a lot of article here, but I never had the feeling, that those met my situation with the "2-stage" proxy environment. I was thinking about adding a http header with the original client IP by an iRule in VS-A so I have something to make a persistence decision in VS-B, but I'm not sure how to do that. I also often read about applying the OneConnect profile combined with proxy loadbalancing, but I don't think I really understood the reason and/or benefit, nor do I know where to apply it in this environment.

I hope I made it some kind of clear what I try to accomplish and where the problems are, since English is not my mother language and I'm a but rusted using it.

Any help or hint is very much appreciated.

Thanks in advance,

ichnafi

EDIT:(28th Feb)

I just found out, that the desired website can be acquired from the HTTP::host header even by Vs-B. So would it be possible to establish a persinstence for the combination client IP and HTTP::host header?

EDIT2: Possible Solution found (1st Mar)

I currently endet up with an iRule creating a universal persistence based on the http::host header. the iRule is then bound to a universal Persistense-Profile. The iRule looks lilke this:

when HTTP_REQUEST { 
    persist uie [HTTP::host]
}

I'm thinking of maybe creating a custom header that contains a combination of client_ip and http:host value to get an even more definite persistence, but not quite sure about that. What do you guys think?

12 Replies

  • For all cache servers best option is destination persistence (Sticky perssitence).

     

    Please test in your environment and let us know the status.

     

    Destination address affinity persistence You can optimize your server array with destination address affinity persistence. Destination address affinity persistence, also known as sticky persistence, directs requests for a certain destination IP address to the same server, regardless of which client made the request. This type of persistence provides the most benefits when load balancing caching servers. A caching server intercepts web requests and returns a cached web page if it is available. In order to improve the efficiency of the cache on these servers, it is necessary to send similar requests to the same server repeatedly. You can use the destination address affinity persistence type to cache a given web page on one server instead of on every server in an array. This saves the other servers from having to duplicate the web page in their cache, wasting memory.

     

    • Ichnafi's avatar
      Ichnafi
      Icon for Cirrostratus rankCirrostratus

      Thank you very much for you answer!

       

      Using destination address as persitence profile was also my 1st (..ok, lets be honest 3rd) go to. But it did not seem to work.

       

      When I tcpdump the traffic from VS-B towards the Pool B members, source address is the node in pPoll A BUT destination address is a Pool B node and not the actual websites IP the user wants to open. The requested web address is "embedded" in the HTTP Connect string sent by the proxy in Pool A.

       

      Maybe I should have written that in my question in the first place.

       

      Sorry.

       

    • RaghavendraSY's avatar
      RaghavendraSY
      Icon for Altostratus rankAltostratus

      Ok. You configured Sticky persistence for both virtual servers?

       

    • Ichnafi's avatar
      Ichnafi
      Icon for Cirrostratus rankCirrostratus

      VS-A has source_addr persistence, because here VS-A sees the real client IPs and can persist based on that info.

       

      VS-B has none (only a hard wired via iRule for a certain website). Source_addr would is useless, because the VS-B only sees the two IPs of our proxies. If I choose source_addr, the traffic would only use 2 of the nodes in pool B. I want to use as many nodes in pool B as possible and persist on those connections based upon the real client IP. I thought of inserting a X-Forwared-For header in VS-A, so VS-B has something to base persistense on, but I really don't know how.

       

      Btw. the proxies in Pool B seem to strip headers like "X-Forwared-For". So the header is not available in the HTTP_RESPONSE.

       

  • For all cache servers best option is destination persistence (Sticky perssitence).

     

    Please test in your environment and let us know the status.

     

    Destination address affinity persistence You can optimize your server array with destination address affinity persistence. Destination address affinity persistence, also known as sticky persistence, directs requests for a certain destination IP address to the same server, regardless of which client made the request. This type of persistence provides the most benefits when load balancing caching servers. A caching server intercepts web requests and returns a cached web page if it is available. In order to improve the efficiency of the cache on these servers, it is necessary to send similar requests to the same server repeatedly. You can use the destination address affinity persistence type to cache a given web page on one server instead of on every server in an array. This saves the other servers from having to duplicate the web page in their cache, wasting memory.

     

    • Ichnafi's avatar
      Ichnafi
      Icon for Cirrostratus rankCirrostratus

      Thank you very much for you answer!

       

      Using destination address as persitence profile was also my 1st (..ok, lets be honest 3rd) go to. But it did not seem to work.

       

      When I tcpdump the traffic from VS-B towards the Pool B members, source address is the node in pPoll A BUT destination address is a Pool B node and not the actual websites IP the user wants to open. The requested web address is "embedded" in the HTTP Connect string sent by the proxy in Pool A.

       

      Maybe I should have written that in my question in the first place.

       

      Sorry.

       

    • Ichnafi's avatar
      Ichnafi
      Icon for Cirrostratus rankCirrostratus

      VS-A has source_addr persistence, because here VS-A sees the real client IPs and can persist based on that info.

       

      VS-B has none (only a hard wired via iRule for a certain website). Source_addr would is useless, because the VS-B only sees the two IPs of our proxies. If I choose source_addr, the traffic would only use 2 of the nodes in pool B. I want to use as many nodes in pool B as possible and persist on those connections based upon the real client IP. I thought of inserting a X-Forwared-For header in VS-A, so VS-B has something to base persistense on, but I really don't know how.

       

      Btw. the proxies in Pool B seem to strip headers like "X-Forwared-For". So the header is not available in the HTTP_RESPONSE.