session persistance with IP hash

[Brian Pugh]

Reinis Rozitis said:
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.

================================

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?)

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?




On Wed, Jul 27, 2016 at 5:01 PM, Reinis Rozitis <r at roze.lv> wrote:

> 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?
>>
>
>
> With the vanilla nginx it would be something like (and for example let's
> say your cookie name is BACKEND):
>
> upstream backend {
>        hash $cookie_BACKEND;
>        server backend1:80;
>        server backend2:80;
>        server backend3:80;
> }
>
>
> 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.
> 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.
>
> Of course if the values differ (for each user a different cookie) in
> longer run the requests will be somewhat evenly distributed.
>
> As a module you can try this
> https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/overview 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.
>
>
> 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)
>
>
> rr
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160727/a81683a1/attachment.html>