In this lesson we'll see how engine X makes it easy to configure a simple yet robust load balancer.
Now first off let's understand what exactly a load balancer is.
In short a load balances should achieve two main objectives.
One the ability to distribute requests to multiple servers thus reducing the load on those individual
servers and secondly to provide redundancy meaning when one or more of our load balanced servers fail
for whichever reason the load balance in each.
To recognize that and redirect requests to any of the remaining available servers.
When I say distribute or redirect of course I mean proxy.
So again using engine X as a reverse proxy and in doing so keeping the load balancing itself as transparent
as possible.
Taking this into account the first requirement for us to test this then is going to be having multiple
servers to load balance using away in jinich server or load balancer.
Do this.
Are you some BHP servers again and this time I'll simply have them each return and identifying plain
text message so I'll create these response files.
Echo P HP server 1 being our first pitch to server right there to a file called a swan.
No need for an extension here.
Page P server doesn't care about the input file type.
Another call server to s to server 3 file name.
S 3.
I list the contents of this directory where we see those files and when we check the contents of this
one we see that string BHP serve one.
So start the first pitch B server here.
P S Flag local host and this time or have a listen on port.
Ten thousand and one only to have it matched the server name.
Were returning I'll create another terminal window and start the second server.
Or.
Ten thousand two this time.
Worth the is to file.
And finally our third server on port.
Ten thousand three with this three.
Test the first one.
Works second serve on board ten thousand two works and the third.
The HP server 3 so that works right we now have three servers running and we can easily identify which
one have been proxy to by those responses.
Of course in a real world example these servers would much more likely be serving the exact same data
given the same requests but will have to distinguish them in order to test our load balancer.
I'll start fresh by creating a new engine configuration file called this one load balancer dot com.
Open that new file in the editor and start with an event block.
H T T B.
Listening on 8 8 8 8 again.
And a root location block.
There's load balancers simply accepting everything and prok seeing it in before setting up our load
balancing worth with 3 HP servers.
Let's test this with one of them.
I'll use that first one so local host port 10000 and 1.
Save and start.
Engine X with the absolute path to that load balancer configuration file.
Carlo engine X server.
And we get the response from BHP serve a one as I expect it right now to monitor the load balancing
I'm going to issue these cold commands to the engineer server using a simple while loop on the command
line bearse will just allow us to monitor subsequent requests without having to run them individually
say while sleep or zero point five or half a second do kearl HTC be local host a date a date.
Done.
So basically we are creating a loop which sleeps for half a second on every iteration and then performs
the call command on our engine X load balancer.
Feel free to run these manually or in any other way you prefer.
This is just a quick way using what we have.
Yeah I'll run that and we get that page piece server one response every half a second as we only proxy's
to that first server at the moment.
Let's implement the actual load balancing now.
First we have to create what's called an upstream.
This is a context or block in engine X that group several servers with the ability to add some options
to the Upstream.
Think of it as a named collection of servers that share somewhere the commonality.
In most cases being that they serve the same content.
This gets defined in our HTP context by saying upstream give it a name.
I'll call this one patch P underscore servers and inside this block defined the individual servers by
saying server with the value being the host name and port of the server.
Like so the remaining to be HP servers 10 thousand to ten thousand three.
And now to proxy this locations requests to the Upstream say proxy pass.
So a standard reverse proxy directive.
GDP p s p underscore servers that upstream pointing to our BHP service reload the configuration file.
Run that loop again curling our engine next load balancer and this time we see a near perfectly distributed
sequence of responses from our BHB service.
So engine X is balancing our requests by sending them to each page piece server in turn.
This default behaviour is referred to as round robin.
Meaning to simply send the next request to the next server in the upstream.
We had a slight variance here for whichever reason but when I slow this down to one second per request
we see a perfect round drop and distribution of course.
The second purpose of a low balances is to provide us with some redundancy.
We can test this by killing one or two of our p p servers whilst the requests are going out.
I'll clear this to make some space.
Start again with one second.
Kill server one.
We see requests continue seamlessly with server 2 and 3 and when I kill server 2 also we see only server
3 responding.
Start server to back up.
It returns in the requests.
And server 1.
And we're back to an even distribution of requests between all three of our upstream servers.
So again an easy robust load balancer in only a few lines of configuration code in the next lesson will
take a look at some different variants of load balancing.