Forum Discussion

Matt_Breedlove_'s avatar
Matt_Breedlove_
Icon for Nimbostratus rankNimbostratus
Jun 04, 2009

LTM to LTM transparent proxy (triangulation)

We have a situation where we want to use 3 physically separate (but same datacenter) LTM clusters (but with no http redirects (301,302) whatsoever to serve 2 distinct websites using a single website hostname

 

Definitions:

 

LTM 'A' = pair of bigip (active/standby - fault tolerant )

 

LTM 'B' = different pair of bigip (active/standby - fault tolerant )

 

LTM 'C' = yet a another pair of bigip (active/standby - fault tolerant )

 

So client would make connection to LTM 'A' using immutable www.website.com.

 

LTM 'A' would look for presence of cookie (controller by actual web servers) and transparently proxy/forward/triangulate that connection (without http redirect) to either LTM 'B' (b.website.com) or LTM 'C' (c.website.com)

 

depending on which the cookie indicated

 

p

 

However, from the client's perspective they should interact only with www.website.com the entire time, regardless of which backend LTM they are actually using.

 

And the client should never be redirected, but always talking to LTM A using initial TCP session.

 

Now I know this is cinch with 1 LTM and a few local pools with the ProxyPass iRule, but that doesn't work for us because we need to diversify our load among the physically separate LTM clusters. All 3 LTM clusters are in same datacenter

 

So one superheavy used site is on 1 LTM (b.website.com), other superheavy used site is on other LTM (c.website.com), and the third LTM acts as traffic/tcp session director and a single point of contact for the clients

 

So we want LTM A to transparently proxy connections to both LTM B and LTM C.

 

Only LTM B and LTM C would actually have real servers (serving the actual unique website content)

 

If LTM B went down, then LTM C's website would still work.(via LTM A)

 

If LTM C went down, then LTM B's website would still work (via LTM A).

 

Additionally, client can choose to connect directly to "b.website.com" and/or "c.website.com" and they will get that website (effectively bypassing LTM 'A')

 

By design, LTM A would be mission critical for both websites to be accessible via www.website.com

 

Reason for this all is we are not able to change the hostname that the client is requesting and we are not allowed to do any http redirects.

 

Additionally, we want to diversify risk/load across all 6 of the loadbalancers (2 in each LTM cluster)

 

Any thoughts on the approach for this would be appreciated

 

Thanks

 

Matt
config
design
  • Ian_Smith's avatar
    Ian_Smith
    Ret. Employee
    Jun 11, 2009
    enable passive cookie persistence on all the LTM http virtual servers or in your iRules.

     

  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    Jun 12, 2009
    I may be missing something, but why not use GTM here? As it stands it sounds like you'll essentially shift most all of the risk up to the A pair of LTMs, which may be contrary to your goals. If you're looking to distribute traffic across the pairs, GTM is a killer tool that will solve this problem easily. You'd create a www.website.com "wide IP" that would actually distribute users to all three pairs of LTM, and you can apply persistence, monitoring (at layer 7, real handy), rules, etc...

     

     

    Would this work for you?

     

     

    -Matt
  • dennypayne's avatar
    dennypayne
    Icon for Employee rankEmployee
    Jun 15, 2009
    I agree with Matt that GTM is the ideal solution here for the reasons he described.

     

     

    However, you could potentially configure LTM A to have the virtual for www.website.com pointing to a pool with 2 members that are the virtual servers on LTM B and C respectively. Then the connections would be farmed out to B and C based on whatever lb algorithm is defined on that pool. LTM A doesn't "know" that those aren't physical hosts.

     

     

    The downside is that you will have to SNAT on LTM A. Otherwise, when the packets are sent through to the real servers behind B and C, they will be sent in response directly back to the client, bypassing LTM A on the return, and the clients will drop them. So you will lose visibility to the original client source IP on the nodes, which may or may not be a big deal for you, depending on whether they are currently logged and/or used for Webtrends (or similar).

     

     

    Denny