Google Professional Data Engineer – Managed Instance Groups and Load Balancing part 3

6. Load Distribution and Firewall Rules

Let’s now see how the Load Balancer distributes load across the various back end services and the corresponding backends every back end is configured with a balancing mode and this is the metric that the Load Balancer uses to determine how loaded a particular backend is and how much capacity it actually has. The balancing mode that we use is CPU Utilization or Request per second per instance you can configure the balancing mode to be either of these based on your requirement, you can basically indicate that there is a certain maximum value for CPU Utilization or Request per second per instance beyond which your back end cannot sustain traffic. If the back end is made up of a managed instance group, this is when the auto scaler will kick in and try to add more VM instances to your back end.

In all of this, though, the back end does allow short bursts of traffic above the limit. It’s only sustained traffic beyond this maximum that isn’t allowed when external traffic first hits the Https load balancer. The load balancer has to make a few decisions. The incoming requests are first sent to the region that is closest to the user. However, this region must have capacity before it has traffic directed to it. Once the region with capacity that is closest to the user has been determined, traffic is then distributed among VM instances that are located in multiple zones, once again based on capacity. Once the zone with capacity has been identified within a zone, the traffic is distributed in a round robin fashion across instances in that zone.

However, if you have Session Affinity configured in your back end service, this round robin distribution can be overridden using Session Affinity. Session Affinity can be set up to use client IP addresses or cookies. We’ve covered all the components of the load balancer in this block diagram. Let’s look at a few additional configuration settings that we need to set up to get our load balancer to work. Specifically the firewall rules. We’ve already discussed this earlier when we spoke about virtual networks, the fact that no packet can go from source to destination without having a route, and a corresponding Firewall rule which allows movement of the packet. Which is why, in order for the load balancer to be able to send traffic to the various back ends and also for the health check to be able to pull specific instances to check whether they are healthy, we require Firewall rules.

So we need to allow traffic from the IP addresses that you see on screen to reach your instances. Set up Firewall rules to enable this. These specific IP ranges are the ones that your load balancer and Health Checker will use to connect to back ends. Both of them have to be allowed. Otherwise, your health checker will basically say your back end is unresponsive and things just won’t work. You also want to ensure that the Firewall Rules allow traffic on the port that the global forwarding rule has been configured to use to forward stuff onto your back ends. We complete our discussion on http https load balancing by talking about the two kinds of load balancing that this offers. The first is cross regional load balancing. Cross regional load balancing allows you to set up a global IP address that can intelligently route users based on proximity.

For example, if you set up an instance in Asia, Europe, and North America, then users around the world will automatically be sent to those regions to which they belong. This, of course, assumes that the back ends in those regions have sufficient capacity. If the closest instances do not have sufficient capacity, the traffic is simply forwarded to the next closest region. The other broad category of load balancing that Google offers is the content based load balancer. This is, of course, for the Https load balancer. Now, based on the incoming https URL, you can redistribute the traffic to different backends. We’ve already seen an example of this where video traffic was sent to some specific backends and all other traffic was sent to some other backends.

7. Lab: HTTP(S) Load Balancing

In this demo for VM automation and load balancing, we will be provisioning three instances in which we will automate the installation of a simple web application by use of a startup script. We will then go on to configure an external load balancer with these instances in the back end. Let us begin though by creating a bucket in which we will load our startup script. So we navigate in the menu to storage and browser and when we create a bucket, note that the name of the bucket must be unique globally. So we find a name which is unique and then when we hit create so we now have our bucket. In order to copy a startup script to this one, let us use the Google Cloud shell. So the startup script which we will use in the demo, you can download from the cloud training bucket which Google provides, so you can just run this gsutil CP command as mentioned on the screen.

However, in my case I already have the startup script somewhere, so I’m just going to copy over the contents into a file called my Startup script. In your case you just download it from the cloud training bucket and once that is in place, this file can just be uploaded into the bucket we just created. So after running the command from the shell, let us just go confirm through the console that the file has indeed been uploaded and we see that that was successful. Moving along, provision the instances which we require for this lab. So we navigate to the Compute Engine VM instances page, create a new instance. This instance let us call Web Server One. We will provision this in one of the US central zones.

We leave the machine type as is and for the access scope choose to set access for each API and we scroll down to storage and confirm that the read only option is selected. With that done, move along to the automatic firewall rule creation and check the box to allow Http traffic. And with that done, let us move along to the management section. And over here under metadata, enter two values, the first being the one for our startup script. Over here we specify the location of the script in our cloud storage bucket. And the other entry here is a variable called My Server ID, which we will set to Web Server One. And this is something which is going to be used by our little web application in order to identify the instance and we will soon see how that works.

So we hit Create in order to provision this VM and once it is ready, go ahead and provision a second instance. So we just go through the same steps. Over here we call this Web Server Two. The other details are exactly the same, except eventually when we enter the metadata, the value for My Server ID is going to be Web Server Two. And with that done, let us move along to our third instance. And again, this is going to be nearly identical to our other two instances, except the name will be Web Server Three. And once again in the metadata the value for my server ID is going to be Web Server Three. So we now have our three instances. Next, check that the web app on each of these instances is up and running.

So we just click on the external IP addresses which should take us to the home page of the web app on each of these. And if the page is taking a really long time to load, there may be something in the firewall which is blocking access to this. So we navigate to the firewalls page and it could be that the Allow Http firewall rule which should be created is not configured correctly. So in this example, the source filter is only set to allow certain IP addresses to hit the instances using the Http port 80. So I’m just going to set it to allow all traffic. So once that is complete, go back to the instances and see if we’re able to bring up the home page and we see that the firewall is no longer blocking access. And we can see here that the page shows the server name over here.

And this value which is Web Server One, Two or three, is being picked up from that my Server ID attribute which we set in the metadata for each instance. Now, moving on to configuring our load balancer, edit each of the instances first and add a new network tag to it. So this tag will be used by the load balancer to identify its back end instances. So our instances should already have a tag called Http Server and we’re going to add another one called Network LB. So we just have to repeat this process for all three instances and we move along now to the second instance. So in case you’re wondering where that Http server tag came from, this was when provisioning the instance, we had checked a box to allow Http traffic so that automatically added this tag to the instance and created a firewall rule to allow Http traffic to instances which had that tag linked to it.

So we moved right along and now we have added the new tag for Network LB to all three instances. The next step for our load balancer is for us to reserve a static IP address. So for that, we navigate to the external IP addresses page and choose to reserve a new address. We give this one a name and we also leave the IP version as before. For the region we choose a US central one. And now that we have reserved this address, we see on this page that there is nothing which is using it at the moment. We will be addressing that soon. But first let us go ahead and create a health check. So we navigate to compute engine and health checks. And for this health check we will be using it to monitor the health of our web application instances.

And these are listening on port 80. So we leave the protocol at Http and the port at. So aside from the name, we just leave all the default values and hit Create. And with our health check ready, we can now add it to a target pool which we will do by first bringing up the Google cloud shell and from over here create a new target pool. So we specify the region and the health check as well. And once the pool is created, let us go ahead and add our instances to it. So we just run another command to add instances and we specify each of our instances web servers one, two and three as well as a zone. And now we have added our instances to the target pool. So our load balancer will be using the static IP address which we had just created.

So let us take a look here at that static IP address so we can see that it’s still there and we will copy over that address and use it in the forwarding rule which we will just create. So what this command says is that any incoming traffic which hits that static IP address will be distributed among the instances in our target pool. So once we run that, our load balancer is ready. So let us go and take a look at the static IP address first. And when we refresh the page we see that it is in use by a forwarding rule.Let us now take a look at our load balancer from the console and see what it looks like over there. So we navigate to load balancing under network services and this is how our load balancer looks in the console.

Now put this balancer to the test by sending it a lot of traffic. So we first get the static IP address and then we put in a continuous loop to run a curl command against it. And we will be getting the web pages in response, so we can see how the load balancer is distributing traffic among each of the instances. Next, go ahead and force an outage to see how the load balancer copes with it. So we go over to our first web server instance and then we just delete it. So we just wait for the termination to begin. And while that is happening, we see in the shell that we are seeing a few connection timed out messages and that is because the server is still unreachable, but it’s not quite terminated.

And once the instance is finally gone, we see that we don’t see the connection timed out messages anymore and the traffic is just being distributed among the two instances which are still alive. Let us next navigate back to the load balancing page in the console. And in the meantime we can see that the traffic is still being distributed among the two instances which are still up and running. So let us expand our load balancer in the console and upon scrolling further down under the back end section we can see that there is a warning symbol right next to the web server. One to indicate that it is not quite healthy. So our load balancer was able to successfully handle an outage. With that, we conclude our demo on VM automation and load balancing. Thank you.

8. Lab: Content Based Load Balancing

In this demo we would be creating an Http load balancer which will distribute traffic to different instances based on the path in the request URL. So for example, if the URL path contains slash video, this will be routed to one instance group and all other traffic will be sent to another instance group. Let me start by showing a couple of resources which I have created in advance, but you will need to provision these before starting the lab. The first resource is a VPC network which I have called dub dub dub network. This is where we will be creating our instances. And also there is an external IP address which we will attach to our load balancer later in the lab. Let us create our first instance which will serve as our main web server.

So this was created in US east and let us attach a network tag which we will name Http tag. This will be in our custom Vpc network, and this instance will also have a startup script. You can get this startup script in the Google Cloud Documents page for content based load balancing. The gist of what it does is it installs Apache and then loads an index HTML page in the varw HTML directory and the page simply says dub dub dub. With our main web server ready, let us clone this now to create our video server. So we changed the name, but everything else remains pretty much the same, including the network tag. However, we do change the startup script.

This script can also be obtained from the Google Cloud Documents page previously cited. And what it does is it loads an index HTML page in the varw HTML video directory and the page reads W Video. Now that we have our instances, let us create the firewall rule which will allow us to access them. So we go and create a new rule. We attach it to our custom Vpc network. We then specify that we want the rule to apply to any instance with the Http tag network tag associated with it. For now, we want the instances to be accessed from anywhere. And we want to restrict the ports to ports 80 and 22. So access is only possible through Http or Ssh. Okay, so now we have our Firewall rule. Let us go ahead and create our instance groups.

Our first instance group is going to be for our main web server. So we call this dub dubdub Resources. We create them in the US East zone, and for this we would like an unmanaged instance group. We create this in our custom Vpc network and we add our main web server instance to it. Once that instance group is created, we create a second one for our video server. This is also an unmanaged instance group, and in this case we add our video server instance. So we now have two instance groups set up. The next step is to create a health check which will monitor the state of our instances. So let us go over to health checks and create a new one. We call this dub. Dubhealth. And since we want this to monitor the state of our web app on port 80, we can leave the default values as is.

Okay, so now we have our health check. Let us move over to the next step and create a load balancer. We navigate to the load balancing section under Network Services and choose to create a load balancer. The kind of balancer we will use for this exercise is an Http load balancer. So we choose star option. We name this webmap, and under backend configuration we create our first back end service. This is a back end service for our main web server. So we first give it a name, and since this is an Http server, we can leave the protocol value unchanged. We then attach the instance group for our main web server and we attach the health check which we just created. We now create a second backend service for the video server.

Again, we give this a name and the instance group which we attach is going to be the one for our video server. We attach the same health check with our back end services in place. Let us now create the host and path rules which will determine the distribution of traffic based on the URL path. So in the host and Path rule which we can specify, we say that all incoming traffic containing the URL path video will be directed to our video server which is map to our video service back end service. And you can see that all other traffic will be directed to the first back end service which we created, which maps to our main web server. We now go and create a frontend configuration which entails mapping the static IP address which we have created previously to this load balancer. Once this is complete, we can just quickly review the details which we entered for this load balancer.

And if everything looks good, we just go ahead and hit Create. This can take a while, but maybe after a minute or so our load balancer is ready. So we quickly take a look at our load balancer and ensure that all the instances backing it up are healthy. Note that these health checks may take a while to pass. We then quickly take a look at the back ends and then we go over to the front ends and grab the IP address and see if our web app is accessible from the browser. So once we go over to a new browser tab and yes, we can see that our main web page is being served, let us see if the video server is accessible. All right, so we have confirmed that our load balancer is able to distribute traffic based on the URL path just as we had configured it to.