<div dir="ltr">Hello,<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 27, 2016 at 1:21 PM, Brian Pugh <span dir="ltr"><<a href="mailto:project722@gmail.com" target="_blank">project722@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Running nginx free version 1.10.1-1.el6.ngx.x86_64 on RHEL 6.7. In my conf I am using <div><br></div><div><div>http {</div><div>    upstream backend {</div><div>        # Use ip hash for session persistance</div><div>        <b>ip_hash;</b></div><div>        server backend1:80;</div><div>        server backend2:80;</div><div>        server backend3:80;</div><div><br></div><div>}</div></div><div><br></div><div>My understanding is that the ip_hash directive is responsible for session persistence. My questions are:</div><div><br></div><div>1) How long does it last? For example, if I connect and my ip hash tells nginx to connect to backend3, will my source IP be forever tied to backend 3?</div></div></blockquote><div><br></div><div>Yes, sorta. Hashing does not really provide "persistence" in the manner you're thinking of. An upstream block using hashing will provide a backend for a given client based on a deterministic hashing algorithm (something roughly like crc32 of the key, modulo the number of elements in the upstream group, then accounting for weights). Hash-based balancing is designed to always provide the same value of a given key, provided that the weights and status of all backend nodes does not change. If the weights are changed during runtime, or a node is unreachable, then the hash will return a different value (and once the node is reachable again, the previous value will be returned subsequent requests).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>2) Is there another way to acheive session persistence other than ip hash and other than purchasing plus edition?</div></div></blockquote><div><br></div><div>There are some third-party modules available, but the quality and stability of those isn't guaranteed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>3) Is there an ip hash "cache" or something I can clean out periodically to force the source IP to get a new hash and therefore a chance to connect to a different server? </div></div></blockquote><div><br></div><div>No, see above. Hashing algorithms are deterministic, given the same number and weight distribution of backend nodes, you will _always_ get the same result. That's the point ;) There's no "cache" or pre-determined result for a given client IP - the upstream is re-calculated with the hashing algorithm on every request. If Nginx cannot connect to the upstream node that its hashing algorithm first selects, it will move on to subsequent nodes in the backend.</div><div><br></div><div>If you want very fine-grained/custom/arbitrary load balancing algorithms, you can write your own in Lua using the ngx+lua module and the balancer_by_lua directive (<a href="https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/balancer.md">https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/balancer.md</a>). This is not available from vanilla open source Nginx, but it is available as part of the OpenResty project.</div><div><br></div><div>Do also note that in addition to ip_hash method there is a generic hash method that can take arbitrary keys to generate the hash. This can include Nginx variables, such as $uri, header values, etc.</div></div><br></div></div>