Well, this is roughly the same! Depends on people, environment, products, etc… I may use both of them in this article, but be aware that both of them point to the IP that is being used to get connected on the service whose being load balanced.
Load Balancing & Stickiness
Load Balancing is the ability to spread requests among a server pool that delivers the same service. By definition, it means that any request can be sent to any server in the pool. Some applications require stickiness between a client and a server: it means all the requests from a client must be sent to the same server. Otherwise, the application session may be broken and that may have a negative impact on the client.
Source IP Stickiness
We may have many ways to stick a user to a server, which has already been discussed on this blog (Read load balancing, affinity, persistence, sticky sessions: what you need to know) (and many other articles may follow).
That said, sometimes, the only information we can “rely” on to perform stickiness is the client (or source) IP address.
Note this is not optimal because:
many clients can be “hidden” behind a single IP address (Firewall, proxy, etc…)
a client can change its IP address during the session
a client can use multiple IP addresses
performing source IP affinity
There are two ways of performing source IP affinity:
Using a dedicated load-balancing algorithm: a hash on the source IP
Using a stick table in memory (and a roundrobin load-balancing algorithm)
Actually, the main purpose of this article was to introduce both methods which are quite often misunderstood and to show the pros and cons of each, so people can make the right decision when configuring their Load-Balancer.
Source IP Hash Load Balancing Algorithm
This algorithm is deterministic. It means that if no elements are involved in the hash computation, then the result will be the same. 2 equipment are able to apply the same hash, hence load-balance the same way, making load-balancer failover transparent.
A hash function is applied to the source IP address of the incoming request. The hash must take into account the number of servers and each server’s weight.
The following events can make the hash change and so may redirect traffic differently over time:
a server in the pool goes down
a server in the pool goes up
a server weight change
The main issue with the source IP hash load balancing algorithm is that each change can redirect EVERYBODY to a different server!!!
That’s why, some good load-balancers have implemented a consistent hashing method that ensures that if a server fails, for example, only the client connected to this server is redirected.
The counterpart of consistent hashing is that it doesn’t provide a perfect hash, and so, in a farm of 4 servers, some may receive more clients than others.
Note that when a failed server comes back, its “stuck” users (determined by the hash) will be redirected to it.
There is no overhead in terms of CPU or memory when using such an algorithm.
Configuration example in HAProxy or in the ALOHA Load-Balancer:
balance source
hash-type consistentSource IP Persistence Using a Stick-Table
A table in memory is created by the Load-balancer to store the source IP address and the affected server from the pool. We can rely on any non-deterministic load-balancing algorithm, such as roundrobin or leastconn (it usually depends on the type of application you’re load-balancing).
Once a client is stuck to a server, he’s stuck until the entry in the table expires or the server fails. There is an overhead in memory to store stickiness information. In HAProxy, the overhead is pretty low: 40MB for 1.000.000 IPv4 addresses. One main advantage of using a stick table is that when a failed server comes back, no existing sessions will be redirected to it. Only new incoming IPs can reach it. So no impact on users. It is also possible to synchronize tables in memory between multiple HAProxy or ALOHA Load-Balancers, making a load balancer failover transparent.
Configuration example in HAProxy or in the ALOHA Load-Balancer:
stick-table type ip size 1m expire 1h
stick on src
