Continuing from our previous lesson where we created a basic round robin load balancer in this video
we'll see how to load balance based on different criteria the first being what's refer to sticky sessions
meaning a request is bound to a user's IP address and always when possible proxy to the same server.
This allows us to maintain user sessions for things like log in state etc..
I'll start with 3 HP Service again.
And before we start this load balancer we can implement sticky sessions by simply adding an option to
this upstream.
Say IP hash.
So create and maintain a memory of IP addresses and proxy requests accordingly.
Save that and start in Genex with that load balance head at conf file.
I'll run the Y loop again curling the load balance every second and this time despite having three servers
in upstream.
We only get reverse proxy to that first P P server.
We do however still maintain that same redundancy where when one server goes down.
We get switched to the next available server being server 2 in this case.
Start over one back up.
And we get moved back to server one again so that sticky sessions or I'd be hashing.
Very useful for load balancing website or services that rely heavily on server sessions or sition state.
The next variant of load balancing is to distribute requests based on active connections or load.
So instead of simply picking the next turn in the Upstream queue engine X will proxy request to the
one with the least number of active connections.
Demonstrate this.
I'll create a new BHB server file to run with server 1.
Call it slow dot patch.
Be open that file and all this needs to do is delay its response.
So keeping that connection open for a while so we can see engine X load balancing to the remaining two
servers.
Do this so add a simple sleep function meaning just wait 20 seconds and then eCard a response.
Sleepy server.
Finally done.
Start server one back up.
With that slowed up HP file.
Run the Kur loop to the load balancer.
That very first request goes to server 1 and we can see the delayed response start a second Kur loop.
And we get the same.
This of course being as our IP is being proxy to the same server each time so to implement load balancing
based on the least number of connections.
Then we can change this IP hashed out rechter have to least underscore common or least connect it.
Reload the configuration and start that first loop.
We get stuck on server one again.
But when we run the second Kur loop we only see responses from server 2 and server 3 as engine Xist
now cleverly avoiding server one due to that active connection.
At which point our first request finishes and we get a couple server two and three responses before
being back to server one.