session persistance with IP hash

[Brian Pugh]

Yesterday once I got the traffic going to the backend servers from nginx I
noticed that I was pinned to "backend3", which is last in the order. And
since I am the one setting this up I am the only user. So I changed up my
order just to see the effects of calculating a new hash. Instead of:

upstream backend {
backend1
backend2
backend3
}

I listed them in the order:

upstream backend {
backend2
backend3
backend1
}

then restarted nginx. At that point my traffic was pinned to backend1. This
seems a bit odd to me in that it seems to be always choosing the last
server in the order. Any thoughts on what might be happening and why it did
not pin me to backend1 the first time and backend2 the second time?

On Wed, Jul 27, 2016 at 8:44 PM, Robert Paprocki <
rpaprocki at fearnothingproductions.net> wrote:

>
>> 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?
>>
>
> Assuming you're using a cookie to track the session, the cookie shouldn't
> change depending on what URI the user is accessing.
>
>
>> (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?)
>>
>
> Depends on how long the cookie lives on the browser. If the cookie never
> changes and doesn't expire when the browser closes, the backend wouldn't
> change (again, assuming nothing changed about the backend servers).
>
> It doesn't matter what is used to build the hash key - cookie, ip,
> whatever. As long as that value doesn't change, and nothing changes about
> your backends, the client will hit the same backend every time. Guaranteed.
>
>
>> 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?
>>
>
> Round robin means that each backend will be used in turn, regardless of
> the client. For example, if you have 3 backends:
>
> request 1 -> backend1
> request 2 -> backend2
> request 3 -> backend3
> request 4 -> backend1
> request 5 -> backend2
>
> This goes on forever, regardless of the client IP. (Of course, this is
> relative if you are using server weights - see the example at
> http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream for
> a round robin example with weights). If you want session persistence, then
> round robin balancing is not for you.
>
> _______________________________________________
> 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/20160728/18e31b51/attachment.html>