<div dir="ltr"><div>Hi Maxim,</div><div><br></div><div>Thanks for your reply.</div><div><br></div><div>That makes sense to me, except for the fact that "hash" (without "consistent") doesn't seem to be doing round-robin load balancing.</div><div><br></div><div>Is there a reason that regular "hash" keeps returning a consistent IP? I could understand if both directives resulted in the behaviour you described, but it seems strange that only one would.</div><div><br></div><div>Thanks<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 10 Feb 2021 at 17:41, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</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">Hello!<br>
<br>
On Wed, Feb 10, 2021 at 04:21:20PM +0200, Ari Croock wrote:<br>
<br>
> Hi all,<br>
> <br>
> Not sure if this belongs on the devel mailing list, I thought I would try<br>
> to post here first.<br>
> <br>
> <br>
> *Summary*<br>
> The "hash" and "hash ... consistent" upstream directives behave differently<br>
> when an upstream hostname resolves to multiple IP addresses.<br>
> <br>
> <br>
> *My Use-case:*<br>
> <br>
> I am using nginx as a reverse proxy for load balancing inside a<br>
> docker-compose network.<br>
> In docker-compose, you can setup a service with multiple replicas and with<br>
> a common hostname. A DNS lookup returns the IP addresses for each replica<br>
> (e.g. if I have containers "dash_1" and "dash_2", "dash" could resolve to<br>
> the IP addresses for both).<br>
> <br>
> The application we are hosting requires sticky sessions. We have<br>
> implemented this using the "hash ... consistent" upstream directive.<br>
> So an example upstream could look like:<br>
> upstream test_upstream {<br>
> hash $token consistent;<br>
> server dashboard_test:3838;<br>
> }<br>
> where "$token" is the unique token for hashing.<br>
> Note that "dashboard_test" can resolve to multiple IP addresses as<br>
> explained above.<br>
> <br>
> As I understand it, when nginx starts up it will do a DNS lookup for<br>
> "dashboard_test" which resolves to multiple IP addresses, effectively<br>
> resulting in an upstream group with multiple "servers".<br>
> <br>
> <br>
> *My Problem:*<br>
> <br>
> It seems that the "hash" and "hash consistent" directives behave<br>
> differently.<br>
> <br>
> I had a quick look at the source (ngx_http_upstream_hash_module.c) and it<br>
> looks like the "regular" hash method determines an actual IP address from<br>
> the hash, but the "chash" *only determines the entry in the upstream group*.<br>
> <br>
> Empirically, this does seem to be the case. With the "hash" directive nginx<br>
> always proxies to the same upstream server. With the "hash consistent"<br>
> directive I get a different upstream server on every request.<br>
> <br>
> Can anyone comment on whether this is intended behaviour? From my point of<br>
> view this seems to be a bug. But I can imagine that changing this behaviour<br>
> might break someone else's use case.<br>
<br>
It is intended behaviour.  Consistent hashing depends on the name <br>
server name written in the configuration to identify servers (and <br>
distribute requests).  Servers with the same name are effectively <br>
identical, even if IP address of the server changes.  If the name <br>
resolves to multiple addresses, these addresses are used in <br>
round-robin.<br>
<br>
That is, your configuration with just one server in the upstream <br>
block is effectively identical to round-robin configuration.  If <br>
you want consistent hashing to work, you have to list your backend <br>
servers in the upstream block by using separate "server" <br>
directives.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><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><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="color:rgb(102,102,102);font-family:Arial,sans-serif">Ari Croock | Isazi | Software Engineer | BSc (Eng) - Electrical</span></div><div><p style="margin:0px"><font color="#666666"><span style="font-family:Wingdings" lang="EN-ZA"><span style="font-family:Arial,sans-serif">38 Homestead Road, Rivonia, Johannesburg, South Africa, 2128 |</span>(</span><span style="font-family:"Tms Rmn",serif" lang="EN-ZA">:</span><span style="font-family:Arial,sans-serif" lang="EN-ZA"> +27 11 027 6996 </span></font></p><p style="margin:0px"><span style="font-family:Arial,sans-serif" lang="EN-ZA"><font color="#666666"><span style="font-family:Wingdings" lang="EN-ZA">*</span><span style="font-family:"Tms Rmn",serif" lang="EN-ZA">:  </span><span style="font-family:Arial,Helvetica,sans-serif" lang="EN-ZA"><font face="Arial, sans-serif"><a href="mailto:acroock@isazi.ai" target="_blank">acroock@isazi.ai</a> | </font></span><a href="http://www.isazi.ai/" style="font-family:Arial" target="_blank">www.isazi.ai</a><span style="font-family:Arial"> </span></font></span></p></div><div><div><span style="color:rgb(102,102,102);font-family:Arial,sans-serif"><img src="https://drive.google.com/uc?id=1Hqvt6vw0LDuLmQErdARvBc9H_oxfgZzV&export=download" width="200" height="53"></span></div></div></div></div>