Disclaimer: I'm completely new to load balancing and have minimal experience with nginx.

I'm going to be launching a website in a couple months and I want to make sure it stays up and responsive. I believe load balancing is the solution to this.

However, I think I can kill two birds with one stone. My target audience is going to be spread out across North America and maybe UK, so what I want to do is buy two or three servers, spread them out geographically, and then load balance them.

I don't want to do simple round-robin based balancing; I think it would be more beneficial for users to be directed to the server they're closest to for faster response times unless it's down or it's under very heavy load.

I see there's something called an ip_hash directive, but it sounds like this only ensures the user gets sent to the same server, but not necessarily the closest server. Is there a way to do what I want?

  • Have you considered simply using CDN instead of load balancing over geographic locations? – Drew Khoury Feb 16 '14 at 4:07
  • @DrewKhoury: Briefly. I don't think it will help me. Most of my traffic will be repeat visitors, and most of my content is dynamic. This means any static content (images,css,js) can be cached for long periods of time, rarely needing to hit my server (CDN is of little benefit), and the rest of it I can't put on a CDN anyway. Uptime is a much more important than the speed bit. – mpen Feb 16 '14 at 23:58

Adding multiple servers to an upstream block allows load balancing across multiple servers, but typically where the servers are located at the same location.

When a user accesses your website, they look up the IP address of the domain name of your website. An IP address corresponds to a single location on the internet, so necessarily, the gateway server is located in a single location. That means that if the servers are not located in the same location, it will actually be counterproductive, since all website data transfers will go through the gateway server, which is running nginx.

To load balance geographically, you need multiple domains or sub-domains. Each domain/subdomain corresponds to a geographic region (although one geographic region can have multiple domains). You update the A records of the domain/subdomains to point to the correct server, and configure them normally.

Lastly, you can setup a redirection based on the IP address to the appropriate subdomain to get the closest server.

Note that if you are doing it by country, it will get a reasonable close, but not necessarily the closest server.

You will probably be running nginx on each server, with configuration differing based on the IP address blocks it handles.

Users will be able to see that they have been redirected to a different site (domain/subdomain) to handle their request. This is what google.com does, depending on where you access it, it will redirect to a country-specific TLD.

Note this is not a simple configuration. If you want a failsafe in case a server falls, you will have to have multiple servers in each location. You will also have many servers with slightly different configurations which you will have to manage. It may also not necessarily be easiest to setup geographic redirection in nginx, but you can do the redirection in the application server instead.

  • That makes sense. Hadn't considered they would all need to hit the same balancer. It shouldn't be too hard to forward them off to different subdomains, but I guess still need to figure out a way to monitor if they're alive or dead. – mpen Feb 17 '14 at 0:06
  • Is it possible to setup a top level domain to do a 302 redirect to the appropriate geographical domain based on location of request? – chovy Jan 17 '16 at 1:22

if you need to monitor the status of real servers, you would be like to use keepalived. The keepalived could test the page that you set and would have a change of server alived for service after one down.

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .