<div dir="ltr"><div><div><h3 class="gmail-iw"><span class="gmail-gD" name="Reinis Rozitis">Reinis Rozitis said:<br></span></h3><span style="color:rgb(255,0,0)">The problem with this (if it matters) is that there is no (pre)defined 
value of the cookie BACKEND which would specifically route particular 
client to particular backend - I mean for example if you use values 
'backend1', 'backend2', 'backend3' the hashed keys might (or not) aswell
 all point to the same backend server.</span><br><br>================================<br><br></div>I'm not as concerned with what server its routed to as much as I am concerned with the client session "sticking" to the server it was routed to. And I really do not know enough about how to use cookie based hashing. In order to have cookie bashed hashing would the cookie need to be common among all pages at the target URL in order to stick the session to a particular server for the duration of that session? (And, I assume cookie bashed hashing is not like ip hash in that you are only stuck to a particular server for the duration of that browser session?) <br><br></div>Also, what is the logic behind "round-robin" or is that the same as ip_hash? For instance, If I have a client at 192.168.100.10 that's assigned to backend 3, then, 100 more clients come along on the same subnet, they will all land on backend 3. Next client 192.168.200.10 comes along, what determines whether it lands on backend1 or backend2? Or, is there a chance it could also land on backend3?<br><div><br><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 27, 2016 at 5:01 PM, Reinis Rozitis <span dir="ltr"><<a href="mailto:r@roze.lv" target="_blank">r@roze.lv</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Took a look at the link, but I have no idea what that would look like in my upstream stanza. Can you provide an example of what that would look like if I had 3 different backend servers and wanted to ensure that my hash was based on a cookie, or based on just a hash that provided a different backend server per session?<br>
</blockquote>
<br>
<br></span>
With the vanilla nginx it would be something like (and for example let's say your cookie name is BACKEND):<br>
<br>
upstream backend {<br>
       hash $cookie_BACKEND;<span class=""><br>
       server backend1:80;<br>
       server backend2:80;<br>
       server backend3:80;<br>
}<br>
<br>
<br></span>
The problem with this (if it matters) is that there is no (pre)defined value of the cookie BACKEND which would specifically route particular client to particular backend - I mean for example if you use values 'backend1', 'backend2', 'backend3' the hashed keys might (or not) aswell all point to the same backend server.<br>
So unless you find 3 values which for sure point to different backends the load/users might not be evenly distributed (in general it is the same as with ip_hash if the end-users don't have very distinct IPs or for example are in the same subnet all the users will land on the same backend (as per documentation - "The first three octets of the client IPv4 address are used as a hashing key.")). It shouldn't be too hard though.<br>
<br>
Of course if the values differ (for each user a different cookie) in longer run the requests will be somewhat evenly distributed.<br>
<br>
As a module you can try this <a href="https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/overview" rel="noreferrer" target="_blank">https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/overview</a> but as it was mentioned in previous mail by Robert the quality might vary and if you want a better controlable user distribution Lua could be also an option.<br>
<br>
<br>
p.s. In case of the bare nginx the first request is "problematic" since there won't be any cookie so it will always land on one backend and later if the cookie gets generated by backend application the user might get "moved" to a different backend server. (eg thatš why it is better to use a hash key like ip / url or browser agent header which is known to nginx immediately)<div class="HOEnZb"><div class="h5"><br>
<br>
rr<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></div></div></blockquote></div><br></div>