What are the limitations of ip_hash ?
mark at ScheduleWorld.com
Wed Dec 31 19:13:43 MSK 2008
Grzegorz Nosek wrote:
> On śro, gru 31, 2008 at 02:58:30 -0500, Mark Swanson wrote:
>> 1. IP 126.96.36.199 -> ip_hash -> server A
>> 2. IP 188.8.131.52 -> ip_hash -> server B
>> 3. IP 184.108.40.206 -> ip_hash -> server A
>> so far so good. 220.127.116.11 always goes to server A just like the docs
>> state. Until ...
>> 4. IP 18.104.22.168 -> ip_hash -> server B
>> This should never happen if I understand ip_hash correctly, yet this it
>> seems to happen about 10% of the time (not useful to anyone needing
>> sticky sessions).
> If I understand the source correctly, this happens when one of your
> backends is down (as determined by Nginx). The IP address is then
> rehashed and the connection retried until it succeeds or you run out of
>> Btw, modulo? If you have the source handy would you mind posting the
>> code for this? I was really hoping the class C address would be used as
>> a key into a hash table and the value was the previously used server ID.
> The two functions starting from here:
>> I was also really hoping this hash table would be preserved after
>> sending a HUP signal to nginx.
> There's no hash table in ip_hash, there's a hash _function_ which maps
> incoming IP to a server id. It isn't remembered anywhere. But the
> backend up/down status and failure count is indeed reset upon SIGHUP
> Best regards,
> Grzegorz Nosek
Ok, thank you for the info.
More information about the nginx