1
00:00:05,890 --> 00:00:12,450
In this lesson we'll see how engine X makes it easy to configure a simple yet robust load balancer.

2
00:00:12,460 --> 00:00:16,580
Now first off let's understand what exactly a load balancer is.

3
00:00:16,660 --> 00:00:20,420
In short a load balances should achieve two main objectives.

4
00:00:20,530 --> 00:00:26,680
One the ability to distribute requests to multiple servers thus reducing the load on those individual

5
00:00:26,680 --> 00:00:33,790
servers and secondly to provide redundancy meaning when one or more of our load balanced servers fail

6
00:00:33,820 --> 00:00:36,580
for whichever reason the load balance in each.

7
00:00:36,580 --> 00:00:43,270
To recognize that and redirect requests to any of the remaining available servers.

8
00:00:43,360 --> 00:00:47,590
When I say distribute or redirect of course I mean proxy.

9
00:00:47,590 --> 00:00:54,760
So again using engine X as a reverse proxy and in doing so keeping the load balancing itself as transparent

10
00:00:54,760 --> 00:00:56,320
as possible.

11
00:00:56,380 --> 00:01:01,960
Taking this into account the first requirement for us to test this then is going to be having multiple

12
00:01:01,960 --> 00:01:06,380
servers to load balance using away in jinich server or load balancer.

13
00:01:06,650 --> 00:01:07,270
Do this.

14
00:01:07,270 --> 00:01:14,170
Are you some BHP servers again and this time I'll simply have them each return and identifying plain

15
00:01:14,200 --> 00:01:18,480
text message so I'll create these response files.

16
00:01:18,610 --> 00:01:26,880
Echo P HP server 1 being our first pitch to server right there to a file called a swan.

17
00:01:26,920 --> 00:01:28,920
No need for an extension here.

18
00:01:29,020 --> 00:01:32,880
Page P server doesn't care about the input file type.

19
00:01:32,890 --> 00:01:40,080
Another call server to s to server 3 file name.

20
00:01:40,150 --> 00:01:41,950
S 3.

21
00:01:41,980 --> 00:01:48,370
I list the contents of this directory where we see those files and when we check the contents of this

22
00:01:48,370 --> 00:01:52,010
one we see that string BHP serve one.

23
00:01:52,390 --> 00:01:55,130
So start the first pitch B server here.

24
00:01:55,180 --> 00:02:01,250
P S Flag local host and this time or have a listen on port.

25
00:02:01,270 --> 00:02:05,200
Ten thousand and one only to have it matched the server name.

26
00:02:05,200 --> 00:02:10,200
Were returning I'll create another terminal window and start the second server.

27
00:02:13,190 --> 00:02:13,570
Or.

28
00:02:13,610 --> 00:02:15,690
Ten thousand two this time.

29
00:02:15,810 --> 00:02:17,760
Worth the is to file.

30
00:02:20,490 --> 00:02:22,830
And finally our third server on port.

31
00:02:22,830 --> 00:02:25,620
Ten thousand three with this three.

32
00:02:28,250 --> 00:02:29,810
Test the first one.

33
00:02:32,240 --> 00:02:39,170
Works second serve on board ten thousand two works and the third.

34
00:02:39,170 --> 00:02:45,710
The HP server 3 so that works right we now have three servers running and we can easily identify which

35
00:02:45,710 --> 00:02:48,880
one have been proxy to by those responses.

36
00:02:48,980 --> 00:02:54,620
Of course in a real world example these servers would much more likely be serving the exact same data

37
00:02:55,010 --> 00:03:00,970
given the same requests but will have to distinguish them in order to test our load balancer.

38
00:03:01,010 --> 00:03:08,160
I'll start fresh by creating a new engine configuration file called this one load balancer dot com.

39
00:03:09,100 --> 00:03:13,530
Open that new file in the editor and start with an event block.

40
00:03:14,660 --> 00:03:16,200
H T T B.

41
00:03:18,480 --> 00:03:21,340
Listening on 8 8 8 8 again.

42
00:03:21,930 --> 00:03:23,730
And a root location block.

43
00:03:23,970 --> 00:03:29,100
There's load balancers simply accepting everything and prok seeing it in before setting up our load

44
00:03:29,100 --> 00:03:31,910
balancing worth with 3 HP servers.

45
00:03:31,920 --> 00:03:34,010
Let's test this with one of them.

46
00:03:34,080 --> 00:03:39,510
I'll use that first one so local host port 10000 and 1.

47
00:03:40,360 --> 00:03:41,920
Save and start.

48
00:03:41,920 --> 00:03:46,020
Engine X with the absolute path to that load balancer configuration file.

49
00:03:48,650 --> 00:03:50,620
Carlo engine X server.

50
00:03:54,820 --> 00:04:00,820
And we get the response from BHP serve a one as I expect it right now to monitor the load balancing

51
00:04:00,850 --> 00:04:06,670
I'm going to issue these cold commands to the engineer server using a simple while loop on the command

52
00:04:06,670 --> 00:04:12,100
line bearse will just allow us to monitor subsequent requests without having to run them individually

53
00:04:12,850 --> 00:04:24,940
say while sleep or zero point five or half a second do kearl HTC be local host a date a date.

54
00:04:25,540 --> 00:04:26,410
Done.

55
00:04:26,860 --> 00:04:33,190
So basically we are creating a loop which sleeps for half a second on every iteration and then performs

56
00:04:33,220 --> 00:04:36,040
the call command on our engine X load balancer.

57
00:04:36,100 --> 00:04:39,460
Feel free to run these manually or in any other way you prefer.

58
00:04:39,460 --> 00:04:41,590
This is just a quick way using what we have.

59
00:04:41,590 --> 00:04:48,520
Yeah I'll run that and we get that page piece server one response every half a second as we only proxy's

60
00:04:48,550 --> 00:04:50,710
to that first server at the moment.

61
00:04:50,710 --> 00:04:53,090
Let's implement the actual load balancing now.

62
00:04:53,260 --> 00:04:56,210
First we have to create what's called an upstream.

63
00:04:56,410 --> 00:05:02,800
This is a context or block in engine X that group several servers with the ability to add some options

64
00:05:02,830 --> 00:05:04,210
to the Upstream.

65
00:05:04,210 --> 00:05:09,200
Think of it as a named collection of servers that share somewhere the commonality.

66
00:05:09,400 --> 00:05:12,540
In most cases being that they serve the same content.

67
00:05:12,580 --> 00:05:18,820
This gets defined in our HTP context by saying upstream give it a name.

68
00:05:19,030 --> 00:05:26,320
I'll call this one patch P underscore servers and inside this block defined the individual servers by

69
00:05:26,320 --> 00:05:31,390
saying server with the value being the host name and port of the server.

70
00:05:31,390 --> 00:05:39,480
Like so the remaining to be HP servers 10 thousand to ten thousand three.

71
00:05:39,790 --> 00:05:45,860
And now to proxy this locations requests to the Upstream say proxy pass.

72
00:05:45,910 --> 00:05:48,880
So a standard reverse proxy directive.

73
00:05:49,060 --> 00:05:58,400
GDP p s p underscore servers that upstream pointing to our BHP service reload the configuration file.

74
00:05:59,270 --> 00:06:06,350
Run that loop again curling our engine next load balancer and this time we see a near perfectly distributed

75
00:06:06,350 --> 00:06:09,630
sequence of responses from our BHB service.

76
00:06:09,680 --> 00:06:15,240
So engine X is balancing our requests by sending them to each page piece server in turn.

77
00:06:16,000 --> 00:06:19,260
This default behaviour is referred to as round robin.

78
00:06:19,330 --> 00:06:23,780
Meaning to simply send the next request to the next server in the upstream.

79
00:06:23,810 --> 00:06:29,920
We had a slight variance here for whichever reason but when I slow this down to one second per request

80
00:06:29,980 --> 00:06:33,300
we see a perfect round drop and distribution of course.

81
00:06:33,310 --> 00:06:37,240
The second purpose of a low balances is to provide us with some redundancy.

82
00:06:37,300 --> 00:06:42,930
We can test this by killing one or two of our p p servers whilst the requests are going out.

83
00:06:43,180 --> 00:06:45,540
I'll clear this to make some space.

84
00:06:45,880 --> 00:06:48,150
Start again with one second.

85
00:06:49,310 --> 00:06:50,900
Kill server one.

86
00:06:52,320 --> 00:07:00,630
We see requests continue seamlessly with server 2 and 3 and when I kill server 2 also we see only server

87
00:07:00,630 --> 00:07:01,890
3 responding.

88
00:07:05,330 --> 00:07:07,210
Start server to back up.

89
00:07:13,620 --> 00:07:15,530
It returns in the requests.

90
00:07:17,080 --> 00:07:18,990
And server 1.

91
00:07:20,650 --> 00:07:26,020
And we're back to an even distribution of requests between all three of our upstream servers.

92
00:07:26,470 --> 00:07:33,170
So again an easy robust load balancer in only a few lines of configuration code in the next lesson will

93
00:07:33,190 --> 00:07:36,590
take a look at some different variants of load balancing.