WEBVTT 00:05.820 --> 00:12.110 Continuing from our previous lesson where we created a basic round robin load balancer in this video 00:12.120 --> 00:18.780 we'll see how to load balance based on different criteria the first being what's refer to sticky sessions 00:19.230 --> 00:26.590 meaning a request is bound to a user's IP address and always when possible proxy to the same server. 00:26.850 --> 00:31.890 This allows us to maintain user sessions for things like log in state etc.. 00:31.890 --> 00:34.590 I'll start with 3 HP Service again. 00:36.210 --> 00:41.560 And before we start this load balancer we can implement sticky sessions by simply adding an option to 00:41.560 --> 00:42.880 this upstream. 00:43.880 --> 00:45.970 Say IP hash. 00:46.780 --> 00:52.550 So create and maintain a memory of IP addresses and proxy requests accordingly. 00:52.570 --> 00:58.030 Save that and start in Genex with that load balance head at conf file. 00:58.030 --> 01:05.440 I'll run the Y loop again curling the load balance every second and this time despite having three servers 01:05.500 --> 01:06.620 in upstream. 01:06.760 --> 01:10.690 We only get reverse proxy to that first P P server. 01:10.690 --> 01:15.900 We do however still maintain that same redundancy where when one server goes down. 01:17.780 --> 01:22.780 We get switched to the next available server being server 2 in this case. 01:23.680 --> 01:25.680 Start over one back up. 01:29.200 --> 01:34.760 And we get moved back to server one again so that sticky sessions or I'd be hashing. 01:34.810 --> 01:42.640 Very useful for load balancing website or services that rely heavily on server sessions or sition state. 01:42.640 --> 01:48.700 The next variant of load balancing is to distribute requests based on active connections or load. 01:48.940 --> 01:54.910 So instead of simply picking the next turn in the Upstream queue engine X will proxy request to the 01:54.910 --> 01:57.970 one with the least number of active connections. 01:57.970 --> 01:58.840 Demonstrate this. 01:58.840 --> 02:03.250 I'll create a new BHB server file to run with server 1. 02:03.250 --> 02:04.790 Call it slow dot patch. 02:04.790 --> 02:11.270 Be open that file and all this needs to do is delay its response. 02:11.290 --> 02:16.870 So keeping that connection open for a while so we can see engine X load balancing to the remaining two 02:16.870 --> 02:18.040 servers. 02:18.250 --> 02:27.580 Do this so add a simple sleep function meaning just wait 20 seconds and then eCard a response. 02:30.030 --> 02:31.160 Sleepy server. 02:31.180 --> 02:32.370 Finally done. 02:36.020 --> 02:37.910 Start server one back up. 02:37.910 --> 02:40.200 With that slowed up HP file. 02:41.410 --> 02:43.950 Run the Kur loop to the load balancer. 02:44.080 --> 02:51.730 That very first request goes to server 1 and we can see the delayed response start a second Kur loop. 02:53.670 --> 02:55.140 And we get the same. 02:55.290 --> 03:01.070 This of course being as our IP is being proxy to the same server each time so to implement load balancing 03:01.080 --> 03:03.110 based on the least number of connections. 03:03.120 --> 03:11.090 Then we can change this IP hashed out rechter have to least underscore common or least connect it. 03:11.950 --> 03:15.800 Reload the configuration and start that first loop. 03:18.360 --> 03:20.730 We get stuck on server one again. 03:21.890 --> 03:28.480 But when we run the second Kur loop we only see responses from server 2 and server 3 as engine Xist 03:28.500 --> 03:32.460 now cleverly avoiding server one due to that active connection. 03:37.740 --> 03:43.680 At which point our first request finishes and we get a couple server two and three responses before 03:43.680 --> 03:45.430 being back to server one.