0

Let's say the client requests a page www.example.com/index.html. The DNS translates this into 203.0.113.15/index.html.

Then this server, working as a load balancer (let's say Apache with mod_proxy_balancer), redirects the request to another IP (not in the same local network) 198.51.100.5.

This is the idea:

client ==> example.com ==> DNS ==> 203.0.113.15 (Load Balancer) => 198.51.100.5 (destination server)

Once the link has been established between client and destination, how to avoid that further communication between client and destination 198.51.100.5 will go through the middle server 203.0.113.15?

To be more precise: is it possible, that once the load balancer server (203.0.113.15) has allowed the client and the destination server 198.51.100.5 to "meet"/to "know each other", then:

  • further communication between them (upload/download, potentially megabytes or gigabytes!) does not transit via 203.0.113.15 anymore (in order to save bandwitdh for the load balancer)
  • all of this with example.com still being displayed in his browser

How to configure this in mod_proxy_balancer?

  • @krisFR "Such a request means (to me) a more deeper design problem at source that shoud be adressed first." Not really, it's a quite valid use case. Wikimedia does this for example, see the answer I've linked to. – gf_ Oct 5 '17 at 23:31
1

Regarding the connection server -> client: This is possible with, and of the main features of, the Linux Virtual Server Project, which

is a highly scalable and highly available server built on a cluster of real servers, with the load balancer running on the Linux operating system. The architecture of the server cluster is fully transparent to end users, and the users interact as if it were a single high-performance virtual server.

I've described this in more details in this answer.

1

No it is not possible as by definition the request occurs within a session and that session is bound to a TCP stream which is itself bound to an IP address. What you are asking for is to change the IP address of the binding which would break the connection.

But that's a hard "no" only because of how you framed your question, as what you are asking for shows a poor understanding of how web browsing works at a network level.

There are many ways to achieve similar effects. Direct server return allows the server to return results without passing the results through the load balancer. This has tremendous efficiency for web servers as only the inbound traffic needs to pass the load balancer. Outbound traffic can be sent directly. Since web traffic generally has small requests generating large results this model allows a relatively smaller load balancer handle relatively larger web sites.

Most load balancers work at high layers of the network stack processing high level HTTP streams. This is not a requirement however so you could pick a lower level load balancer that works at layer 2 or layer 3 to balance traffic across IPs which multiple servers can handle directly. In this model every server is effectively it's own load balancer so there is no middle-man dedicated load balancer processing traffic at all.

There is no particular reason to hold only a single session. You may logon to one load balanced server and pass the client a page that loads content or redirects to another server (or group of load balanced servers). In particular if you use IFrames properly the content of different frames can appear as if it came from a single server. Similarly you might use multiple systems that are optimized for multiple roles. Very commonly this is setup as a content distribution network in which a smaller number of servers handle dynamic content while typically a larger number of distributed servers handle static content.

There are a wide range of solutions to this problem. In general you would want to research options for scaling out web farms. But your question is flawed as the load balancer server will never allow the client and the destination server to "meet"/to "know each other". From the perspective of the client there is only one server and the client will never know anything about the infrastructure behind the load balancer.

1

It sounds like you want the LB to keep track of a set of servers and REDIRECT clients to ones that are responding.

As I might do so that my users around the world who normally use my New York server will get sent to the backup server in Melbourne Australia when NYC is offline.

But not all their traffic would have to go through the LB.

That's a great idea! I don't think you can do it with the mod_proxy_balancer module. What you'd need is an option to send the clients a 302 REDIRECT as the "balancing action".

You asked about this over two years ago and I'm guessing you're not still looking for an answer. You sparked my curiosity, though, so would you mind letting us all know what you did?

If you are still looking for an answer, I'd be happy to talk more about what you need and come up with some ideas.

Thanks! Mike

  • Yes, I'm still looking for a solution, I haven't found any "easy to deploy" solution yet :) – Basj Dec 19 '19 at 19:32
  • 1
    I think you must first decide what you want to implement. A load balancer will do what it has to do. What you need is a simple javascript page in the first web server that redirects (by 3XXX html code) to the final server. Seems that you don't want a load balancer. – Carlos Garcia Dec 21 '19 at 8:36
  • Its be nice if we could send the clients a redirection with a timer of some sort. Or a cookie that's good for one "session" at the server we send them to? That way they have to come back to us on future. Carlos suggested a script, I'm thinking that might be a good way forward. Your first server, the "LB" could tailor them to the client and session and coordinate with the backed server. – Mike Diehn Dec 21 '19 at 15:41
  • Check out this use of haproxy: serverfault.com/questions/783013/… – Mike Diehn Dec 21 '19 at 15:49
0

Something like Brocade's VTM could re-write the URLs in the response to point towards the selected host yes, not sure what else could though.

0

Based on your example, I think you're looking to do this on http/https, so my answer will be based on that. Seems to me that you're looking for sticky sessions on the load balancer. This can be done with ease. Although it would happen at L7, not L4(where we generally see a load balancer).

This is the theory for the approach we use at my firm (and also how AWS creates sticky sessions on their managed load balancers).

  1. When a request comes in, check if it has your unique cookie for session. Can be something like routeid.
  2. If the cookie doesn't exist, add the cookie with the value as the name of your backend route.
  3. If the cookie already exists, use that cookie to determine where to send your request.

In an autoscaling system, you'll also need to handle the cases where the backend no longer exists. An example of the configuration for apache is available here:

http://docs.motechproject.org/en/latest/deployment/sticky_session_apache.html#method-2-using-additional-session-cookie

0

Direct Routing is propably what you are asking for.

In this constellation the load-balancer just initiates the first session, while the answer is done directly by the real server to the client.

A http-Request would go this way: Client (get)->LVS-DR (get, rewrites MAC-adress of the TCP-packet)->Real-Server(processes the get-requests and sends the answer)->Client (gets the answer from the real server)

This works with http, but with https this is seen as "man in the middle attack".

At least when using lvs. Perhaps this is the pointer into the right direction for you.

  • Can you expand on what this Direct Routing is? Otherwise this is a link only answer in its essence. – Konrad Gajewski Dec 21 '19 at 22:38
  • @KonradGajewski I already outlined this in my second sentence. I added a get/answer example in the next line. – Nils Jan 14 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.