5

With this configuration:

upstream some_upstream {
  server some-elb.us-east-1.elb.amazonaws.com:80;
}

If some-elb.us-east-1.elb.amazonaws.com maps to 2 IP addresses, how will nginx distribute requests among them? Round-robin? (Say for version 1.1.19, in case the behavior changed at some point.)

Also, I read here that nginx caches DNS results on startup. If you use a variable, it will refresh them, but only if you have configured a DNS resolver. So if I haven't configured a DNS resolver, then what happens if one of the IPs for some-elb.us-east-1.elb.amazonaws.com changes? Will nginx continue to send traffic to the same set of IPs it found at startup?

sandinymyjoints
  • 153
  • 1
  • 6

1 Answers1

8

Please note that nginx 1.1.19 is a development version that went out 3+ years ago. As a good sysadmin, nothing of this kind should go live in your business. Let's focus on your actual question now.


As explained by the documentation :

A domain name that resolves to several IP addresses defines multiple servers at once.

By default, requests are distributed between the servers using a weighted round-robin balancing method.


For the resolver part : yes nginx will issue domain name lookups for server entries on startup then cache any result until you restart it if you use static domain names in your configuration.

Your link points towards a post about reverse proxying and particularly the handling of domain names in the proxy_pass directive. This is a different case where you need to use variables in the directive value to force nginx to update its DNS cache : using the resolver directive for this particular case isn't sufficient.

Now, getting back to the server directive. Using the resolver directive and adding the resolve parameter will allow monitoring DNS records change and auto-reloading the new server list:

resolve
   monitors changes of the IP addresses that correspond to a domain name of 
   the server, and automatically modifies the upstream configuration without 
   the need of restarting nginx (1.5.12).

   In order for this parameter to work, the resolver directive must be
   specified in the http block.
Community
  • 1
Xavier Lucas
  • 13,095
  • 2
  • 44
  • 50
  • Thanks for the response. We are using `proxy_pass http://some_upstream$request_uri;` which is why I linked to that article. My overall goal is to make sure that `some_upstream` regularly re-resolves DNS for `server` because AWS sometimes changes the IPs for its ELBs. Seems like without doing that, then when an IP changes, nginx will continue to send traffic to the outdated IP. It seems like starting with 1.5.12, nginx will handle this with the `resolve` paramter and `resolver` directive that you mention. – sandinymyjoints Jun 24 '15 at 00:12
  • Though tbh, it's still not clear to me whether `proxy_pass` will work with this setup using `resolve` and `resolver` -- that is, whether `proxy_pass some_upstream` will use the updated IPs when `server` is re-resolved, or continue to use the IPs in the cache from when nginx started (thus requiring the solution mentioned in the link about using a variable to force re-resolution). Do you know which the answer to this? – sandinymyjoints Jun 24 '15 at 00:20
  • 1
    @sandinymyjoints The answer is : the post about `proxy_pass` is not relevant in your case since your `proxy_pass` directive is not directly using a domain name but an upstream block name. So this is going to work given you use `proxy_pass some_upstream;` in your location blocks. – Xavier Lucas Jun 24 '15 at 10:52