1
00:00:05,820 --> 00:00:12,110
Continuing from our previous lesson where we created a basic round robin load balancer in this video

2
00:00:12,120 --> 00:00:18,780
we'll see how to load balance based on different criteria the first being what's refer to sticky sessions

3
00:00:19,230 --> 00:00:26,590
meaning a request is bound to a user's IP address and always when possible proxy to the same server.

4
00:00:26,850 --> 00:00:31,890
This allows us to maintain user sessions for things like log in state etc..

5
00:00:31,890 --> 00:00:34,590
I'll start with 3 HP Service again.

6
00:00:36,210 --> 00:00:41,560
And before we start this load balancer we can implement sticky sessions by simply adding an option to

7
00:00:41,560 --> 00:00:42,880
this upstream.

8
00:00:43,880 --> 00:00:45,970
Say IP hash.

9
00:00:46,780 --> 00:00:52,550
So create and maintain a memory of IP addresses and proxy requests accordingly.

10
00:00:52,570 --> 00:00:58,030
Save that and start in Genex with that load balance head at conf file.

11
00:00:58,030 --> 00:01:05,440
I'll run the Y loop again curling the load balance every second and this time despite having three servers

12
00:01:05,500 --> 00:01:06,620
in upstream.

13
00:01:06,760 --> 00:01:10,690
We only get reverse proxy to that first P P server.

14
00:01:10,690 --> 00:01:15,900
We do however still maintain that same redundancy where when one server goes down.

15
00:01:17,780 --> 00:01:22,780
We get switched to the next available server being server 2 in this case.

16
00:01:23,680 --> 00:01:25,680
Start over one back up.

17
00:01:29,200 --> 00:01:34,760
And we get moved back to server one again so that sticky sessions or I'd be hashing.

18
00:01:34,810 --> 00:01:42,640
Very useful for load balancing website or services that rely heavily on server sessions or sition state.

19
00:01:42,640 --> 00:01:48,700
The next variant of load balancing is to distribute requests based on active connections or load.

20
00:01:48,940 --> 00:01:54,910
So instead of simply picking the next turn in the Upstream queue engine X will proxy request to the

21
00:01:54,910 --> 00:01:57,970
one with the least number of active connections.

22
00:01:57,970 --> 00:01:58,840
Demonstrate this.

23
00:01:58,840 --> 00:02:03,250
I'll create a new BHB server file to run with server 1.

24
00:02:03,250 --> 00:02:04,790
Call it slow dot patch.

25
00:02:04,790 --> 00:02:11,270
Be open that file and all this needs to do is delay its response.

26
00:02:11,290 --> 00:02:16,870
So keeping that connection open for a while so we can see engine X load balancing to the remaining two

27
00:02:16,870 --> 00:02:18,040
servers.

28
00:02:18,250 --> 00:02:27,580
Do this so add a simple sleep function meaning just wait 20 seconds and then eCard a response.

29
00:02:30,030 --> 00:02:31,160
Sleepy server.

30
00:02:31,180 --> 00:02:32,370
Finally done.

31
00:02:36,020 --> 00:02:37,910
Start server one back up.

32
00:02:37,910 --> 00:02:40,200
With that slowed up HP file.

33
00:02:41,410 --> 00:02:43,950
Run the Kur loop to the load balancer.

34
00:02:44,080 --> 00:02:51,730
That very first request goes to server 1 and we can see the delayed response start a second Kur loop.

35
00:02:53,670 --> 00:02:55,140
And we get the same.

36
00:02:55,290 --> 00:03:01,070
This of course being as our IP is being proxy to the same server each time so to implement load balancing

37
00:03:01,080 --> 00:03:03,110
based on the least number of connections.

38
00:03:03,120 --> 00:03:11,090
Then we can change this IP hashed out rechter have to least underscore common or least connect it.

39
00:03:11,950 --> 00:03:15,800
Reload the configuration and start that first loop.

40
00:03:18,360 --> 00:03:20,730
We get stuck on server one again.

41
00:03:21,890 --> 00:03:28,480
But when we run the second Kur loop we only see responses from server 2 and server 3 as engine Xist

42
00:03:28,500 --> 00:03:32,460
now cleverly avoiding server one due to that active connection.

43
00:03:37,740 --> 00:03:43,680
At which point our first request finishes and we get a couple server two and three responses before

44
00:03:43,680 --> 00:03:45,430
being back to server one.