Using redirection for load balancing - your thouhts?

AdamM

I wanted to know to know your thoughts on the following simple method of load balancing between two or more web servers.

let's say I have the first server mapped to www.mydomain.com (lets call this WWWserver).

And then I have a second server, with a mirrored webapp at web.mydomain.com (WEBserver).

Both servers run the same webapp. I want roughly half of the traffic to go to each of them. In order to acess the content of the site, users must login.

My thought is the following:

1) at first I don't care which server the user goes to first, but more likely WWWserver.

2) a landing page is show to the user

3) when the user clicks to login, it will randomly (or perhaps a hash on the ip) either keep on the same server, or redirect to the login page of the other server.

4) the user continues on his way, not really knowing or caring that he has been bounced to another server with a slightly different sub-domain name. The user will then stay on the same server for the remainder of the session because all the web navigations are relative links,

I think this method might be simple because it does not require running an additional balancer in front of the two servers. Do you think people will mind if they find themselves on web.mydomain.com instead of www.mydomain.com?

theroyalstudent

@AdamM said:
I think this method might be simple because it does not require running an additional balancer in front of the two servers. Do you think people will mind if they find themselves on web.mydomain.com instead of www.mydomain.com?

It's fine if you're making a web app, then you can just change the URL with JavaScript to indicate the change, and also make requests to the other machine.

Otherwise, I would get curious and try to switch back cause as a user, I do not know what just happened.

AdamM

@theroyalstudent

Javascript would work, but I was thinking doing it on the server with a serverside http temporary redirect, it would only happen once, and only at time when the login button is pressed.

theroyalstudent

@AdamM said:
it would only happen once, and only at time when the login button is pressed.

That would be fine.

AdamM

I think technical people might notice the change of the sub domain, but our app is not for technical people, I doubt they would notice or care

hostnoob

I doubt most users would care. Some may be curious though.

Set a cookie with either web. or www. so you know which one to redirect to. sessions/redirects won't work if the user is logged into one server and manually navigates to the other

AdamM

@hostnoob

true, if the user manually navigates, they would have to log back in. But, I think most people would just follow the links in the page.

I dont think WWW can read a cookie from WEB, even if it has the same main domainname, correct?

AdamM

@hostnoob

true, if the user manually navigates, they would have to log back in. But, I think most people would just follow the links in the page.

I dont think WWW can read a cookie from WEB, even if it has the same main domainname, correct?

perennate

AdamM said: I dont think WWW can read a cookie from WEB, even if it has the same main domainname, correct?

It depends on how the cookie is set, if the cookie is set for main domain name in Set-Cookie header then it will be able to read, otherwise no. See e.g. this.

Have you considered using DNS for load balancing? For example, DNS server can return a small random subset of records on each query. You will have to deal with occasional cases where web browser reloads the DNS and gets different server, but if your web app can handle that then you don't have subdomain issue.

Edit: actually I guess it sounds like your app can't deal with that. I'm not sure then.

Jonchun

@perennate said:
Edit: actually I guess it sounds like your app can't deal with that. I'm not sure then.

To be honest, the setup he's proposing is just as clunky and awkward as just having DNS point to 2 IPs and hoping for the best in terms of dynamic content and cookies. Lol

AdamM

@hostnoob

true, if the user manually navigates, they would have to log back in. But, I think most people would just follow the links in the page.

I dont think WWW can read a cookie from WEB, even if it has the same main domainname, correct?

hostnoob

@AdamM said:
hostnoob

true, if the user manually navigates, they would have to log back in. But, I think most people would just follow the links in the page.

I dont think WWW can read a cookie from WEB, even if it has the same main domainname, correct?

http://stackoverflow.com/questions/3089199/can-subdomain-example-com-set-a-cookie-that-can-be-read-by-example-com

AdamM

@hostnoob

That works

Ikoula

Hi,

A round robin would be easier to set up dont you think ? (i guess it is what @Jonchun thought about).

Jacob

This would work but not ideal.

/* Self Promo

We (AboveClouds) now have virtual load balancing (vLoad) - based on HAProxy.

Self Promo */

vfuse

Multiple A records would probably be much better (maybe with a dns provider that has health monitoring so it will remove the a record that's down).

Why not for example setup 1 nginx server and have 2 or more app servers behind it?

NickL

That sounds like an extremely band aid setup, which will probably create a lot of problems for you.

Have you considered nginx front to load balance your 2 back end servers via reverse proxy?

doghouch

@Jonchun said:
To be honest, the setup he's proposing is just as clunky and awkward as just having DNS point to 2 IPs and hoping for the best in terms of dynamic content and cookies. Lol

shut up pointing to 2 IPS is 10000% better than a load balancing appliance /sarcasm

luissousa

I do think it would mess up with your site rank on Google, they don't actually enjoy double content

impossiblystupid

@AdamM said:
Do you think people will mind if they find themselves on web.mydomain.com instead of www.mydomain.com?

This used to be a fairly common way to do load balancing, with the more common convention being to name the servers www2, www3, and so on. If you pay attention to URLs, you'll still see it being done for more than a few sites.

What it mainly boils down to is how you're going to segment your network, and how much of that you want to expose to your users. It's not uncommon to have an international organization bounce you around based on your location or language settings (e.g., Craigslist and Wikipedia).

vfuse

@impossiblystupid said:

Would only be acceptable if the content is different, for example a different language, not for load balancing.

AdamM

@vfuse Would only be acceptable if the content is different

Is this due to SEO or user experience. On the initial login, we can use the user's ip to consistently redirect to the same server (more or less). Does not seem to hurt user experience too much.

msg7086

One thing you need to take care is to not bring users to redirect back and forth (with an incorrect configuration etc), and that could lead to an indirect infinite loop.

hostnoob

@Ikoula said:
Hi,

A round robin would be easier to set up dont you think ? (i guess it is what Jonchun thought about).

Wouldn't work, since the user might get redirected to Server A, log in, and then on the next page load get redirected to Server B, which wouldn't have their login session or any session info stored

vfuse

@AdamM said:
vfuse Would only be acceptable if the content is different

Is this due to SEO or user experience. On the initial login, we can use the user's ip to consistently redirect to the same server (more or less). Does not seem to hurt user experience too much.

Overall it would just cause a lot of confusion with all the different addresses out there. Just imagine if you would have to scale past 5 servers.

hostnoob said: Wouldn't work, since the user might get redirected to Server A, log in, and then on the next page load get redirected to Server B, which wouldn't have their login session or any session info stored

You can keep the sessions on both servers in sync with memcached for example.

lewekleonek

@AdamM:
I think you overthinking this solution a bit.
I would go with a simple reverse proxy load balancer; you can do it with any current/decent web server.

Apache may be an overkill in this case, so let's go with the nginx config tailored to your example:

http {
    upstream myapp1 {
        server web1.mydomain.com;
        server web2.mydomain.com;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://myapp1;
        }
    }
}

Reference: nginx load balancing

This way your external host name will always be www.mydomain.com
nginx has a very small footprint and it is perfect for serving as load balancer without you having to worry about resources.
If you use the latest nginx release 1.9.* you can do a lot of clever things with load balance weight adjusting and health checking.
Let me know if you need any help figuring it out.

Remember the back-end server host names do not matter; for all you know you could use IP addresses which is not good because in this case you are tied to IP #s; it is the front-end domain name that counts.

AdamM

@lewekleonek

You are making too much sense

You are right, this is the proper solution. I have never setup a proxy before, so I guess I was trying to find a solution within my current bag of tricks. Time to learn something new! (I know nginx is an old had, but new for me).

lewekleonek

@AdamM said:
lewekleonek

You are making too much sense

You are right, this is the proper solution. I have never setup a proxy before, so I guess I was trying to find a solution within my current bag of tricks. Time to learn something new! (I know nginx is an old had, but new for me).

You can use Apache too if you feel more comfortable with it. It just has by default much larger system footprint. [Here] (https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension) is a good guide.