<div dir="ltr">> In my case, the number of hosts will change over time, and I can’t update the nginx config.  So I thought it would make sense to use a hostname that resolves to many IPs.  This would be a scalable solutioin<br><br>In that case, it makes sense to use a templating tool to dynamically populate the contents of the upstream{} block. Hook it in with your service discovery/registration system.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 3, 2020 at 12:59 PM Ian Morris Nieves <<a href="mailto:imnieves@gmail.com">imnieves@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Maxim,<br>
<br>
Thank you for your response.<br>
OK, I understand what you have said.<br>
<br>
This seems slightly strange to me.  We both understand the purpose/point of hashing (consistent or not consistent).  Why does it then make sense to fall-back to round robin?<br>
<br>
In my case, the number of hosts will change over time, and I can’t update the nginx config.  So I thought it would make sense to use a hostname that resolves to many IPs.  This would be a scalable solutioin.<br>
<br>
I would think that the more correct solution would be to hash the IP addresses that all the names resolve to…. not the names themselves.<br>
<br>
I must be missing/mis-understanding something.  Does the current implementation/solution make sense to you?<br>
<br>
Best,<br>
Ian<br>
<br>
> <br>
> Message: 2<br>
> Date: Mon, 3 Feb 2020 16:05:38 +0300<br>
> From: Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>><br>
> To: <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
> Subject: Re: upstream hash consistent seems to depend on order of DNS<br>
>       entries<br>
> Message-ID: <<a href="mailto:20200203130538.GR12894@mdounin.ru" target="_blank">20200203130538.GR12894@mdounin.ru</a>><br>
> Content-Type: text/plain; charset=utf-8<br>
> <br>
> Hello!<br>
> <br>
> On Sat, Feb 01, 2020 at 11:48:00AM -0800, Ian Morris Nieves wrote:<br>
> <br>
>> Here is the setup:<br>
>> - I am running nginx in a single docker container and it has an <br>
>> upstream to a docker service which is composed of 3 docker <br>
>> containers (which happens to be php-fpm)<br>
>> - the service is configured to _not_ expose a single virtual ip <br>
>> address (vip), instead the service exposes the ip addresses of <br>
>> all 3 containers through docker?s built-in DNS.  When this DNS <br>
>> is asked for the IP address of the service it will respond with <br>
>> a list of 3 IP address but the list will rotate in round-robin <br>
>> fashion each time a lookup is performed.  Thus the first IP in <br>
>> the list will not be the same for any 2 consecutive lookups.<br>
>> <br>
>> My first question is:<br>
>> Is it the correct behavior that consistent hashing depends on <br>
>> the order of IP addresses in the DNS query response?  I can <br>
>> imagine arguments either way, and it is possible that this <br>
>> critical detail is outside the scope of consistent hashing.  I <br>
>> will also forward this question to the author of Ketama.<br>
> <br>
> Consistent hashing uses the _name_ as written in the <br>
> configuration, not the IP addresses the name resolves to.<br>
> <br>
> If a name resolves to multiple IP addresses, these addresses are <br>
> considered equal and requests are distributed between them using <br>
> round-robin balancing.<br>
> <br>
> That is, to balance multiple servers (containers) using consistent <br>
> hashing, you have to configure an upstream block with multiple <br>
> "server" directives in it.<br>
> <br>
> -- <br>
> Maxim Dounin<br>
> <a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
> <br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a></blockquote></div>