Google Cloud HTTP(S) load balancing is implemented at the edge of Google’s network in Google’s points of presence (POP) around the world. User traffic directed to an HTTP(S) load balancer enters the POP closest to the user and is then load-balanced over Google’s global network to the closest backend that has sufficient available capacity.
In this lab, we will configure an HTTP load balancer as shown in the diagram below. Then, we will stress test the load balancer to demonstrate global load balancing and autoscaling.
Task 1. Configure a health check firewall rule
Health checks determine which instances of a load balancer can receive new connections. For HTTP load balancing, the health check probes to your load-balanced instances come from addresses in the ranges 130.211.0.0/22 and 35.191.0.0/16. Your firewall rules must allow these connections.
Create the health check rule
Create a firewall rule to allow health checks.
1. In the Cloud Console, on the Navigation menu , click VPC network > Firewall. Notice the existing ICMP, internal, RDP, and SSH firewall rules.
Each Google Cloud project starts with the default network and these firewall rules.
2. Click Create Firewall Rule.
3. Specify the following, and leave the remaining settings as their defaults:
Make sure to include the /22 and /16 in the Source IP ranges.
4. Select tcp and specify port 80.
5. Click Create.
Task 2: Create a NAT configuration using Cloud Router
The Google Cloud VM backend instances that you setup in Task 3 will not be configured with external IP addresses.
Instead, you will setup the Cloud NAT service to allow these VM instances to send outbound traffic only through the Cloud NAT, and receive inbound traffic through the load balancer.
Create the Cloud Router instance
1. In the Cloud Console, on the Navigation menu , click Network services > Cloud NAT.
2. Click Get started.
3. Specify the following, and leave the remaining settings as their defaults:
4. Click Cloud Router, and select Create new router.
5. For Name, type nat-router-us-central1.
6. Click Create.
7. In Create a NAT gateway, click Create.
Wait until the NAT Gateway Status changes to Running before moving onto the next task.
Task 3: Create a custom image for a web server
Create a custom web server image for the backend of the load balancer.
Create a VM
1. In the Cloud Console, on the Navigation menu , click Compute Engine > VM instances.
2. Click Create.
3. Specify the following, and leave the remaining settings as their defaults:
4. Click Management, security, disks, networking, sole tenancy.
5. Click Disks, and clear Delete boot disk when instance is deleted.
6. Click Networking.
· For Network tags, type allow-health-checks.
· Under Network interfaces , click default.
· Under External IP dropdown, select None.
4. Click Done.
5. Click Create.
Customize the VM
1. For webserver, click SSH to launch a terminal and connect.
2. If you see the Connection via Cloud Identity-Aware Proxy Failed popup, click Retry.
3. To install Apache2, run the following commands:
4. To start the Apache server, run the following command:
5. To test the default page for the Apache2 server, run the following command:
The default page for the Apache2 server should be displayed.
Set the Apache service to start at boot
The software installation was successful. However, when a new VM is created using this image, the freshly booted VM does not have the Apache web server running. Use the following command to set the Apache service to automatically start on boot. Then test it to make sure it works.
- In the webserver SSH terminal, set the service to start on boot:
2. In the Cloud Console, select webserver, and then click Reset.
3. In the confirmation dialog, click Reset.
Reset will stop and reboot the machine. It keeps the same IPs and the same persistent boot disk, but memory is wiped. Therefore, if the Apache service is available after the reset, the update-rc command was successful.
4. Check the server by connecting via SSH to the VM and entering the following command:
NOTE: If you see the Connection via Cloud Identity-Aware Proxy Failed popup, click Retry .
5. The result should show Started The Apache HTTP Server.
Prepare the disk to create a custom image
Verify that the boot disk will not be deleted when the instance is deleted.
1. On the VM instances page, click webserver to view the VM instance details.
2. Under Boot disk, verify that When deleting instance is set to Keep disk.
3. Return to the VM instances page, click webserver, and click Delete.
4. In the confirmation dialog, click Delete.
5. In the left pane, click Disks and verify that the webserver disk exists.
Create the custom image
1. In the left pane, click Images.
2. Click Create image.
3. Specify the following, and leave the remaining settings as their defaults:
4. Click Create.
You have created a custom image that multiple identical webservers can be started from. At this point, you could delete the webserver disk.
The next step is to use that image to define an instance template that can be used in the managed instance groups.
Task 4. Configure an instance template and create instance groups
A managed instance group uses an instance template to create a group of identical instances. Use these to create the backends of the HTTP load balancer.
Configure the instance template
An instance template is an API resource that you can use to create VM instances and managed instance groups. Instance templates define the machine type, boot disk image, subnet, labels, and other instance properties.
1. In the Cloud Console, on the Navigation menu , click Compute Engine > Instance templates.
2. Click Create instance template.
3. For Name, type mywebserver-template.
4. For Series, select N1.
5. For Machine type, select f1-micro (1 vCPU).
6. For Boot disk, click Change.
7. Click Custom images.
8. For Image, Select mywebserver.
9. Click Select.
10. Click Management, security, disks, networking, sole tenancy.
11. Click Networking.
· For Network tags, type allow-health-checks.
· Under External IP dropdown, select None.
12. Click Create.
Create the managed instance groups
Create a managed instance group in us-central1 and one in europe-west1.
1. On the Navigation menu, click Compute Engine > Instance groups.
2. Click Create Instance group.
3. Specify the following, and leave the remaining settings as their defaults:
4. Under Autoscaling metrics, click on the edit pencil icon.
5. Under Metric type, select HTTP load balancing utilization.
6. Enter Target HTTP load balancing utilization to 80.
7. Click Done.
8. Set Cool down period to 60 seconds.
9. Enter Minimum number of instances 1 and Maximum number of instances 2.
Managed instance groups offer autoscaling capabilities that allow you to automatically add or remove instances from a managed instance group based on increases or decreases in load. Autoscaling helps your applications gracefully handle increases in traffic and reduces cost when the need for resources is lower. You just define the autoscaling policy, and the autoscaler performs automatic scaling based on the measured load.
10. For Health check, select Create a health check.
11. Specify the following, and leave the remaining settings as their defaults:
Managed instance group health checks proactively signal to delete and recreate instances that become unhealthy.
12. Click Save and continue.
13. For Initial delay, type 60. This is how long the Instance Group waits after initializing the boot-up of a VM before it tries a health check. You don’t want to wait 5 minutes for this during the lab, so you set it to 1 minute.
14. Click Create.
15. Click OK.
NOTE: If a warning window will appear stating that There is no backend service attached to the instance group. Ignore this; you will configure the load balancer with a backend service in the next section of the lab.
Repeat the same procedure for europe-west1-mig in europe-west1:
16. Click Create Instance group.
17. Specify the following, and leave the remaining settings as their defaults:
18. For Health check, select http-health-check (TCP).
19. For Initial delay, type 60.
20. Click Create.
21. Click OK in the dialog window.
Verify the backends
Verify that VM instances are being created in both regions.
- On the Navigation menu, click Compute Engine > VM instances. Notice the instances that start with us-central1-mig and europe-west1-mig. These instances are part of the managed instance groups.
Task 5. Configure the HTTP load balancer
Configure the HTTP load balancer to balance traffic between the two backends (us-central1-mig in us-central1 and europe-west1-mig in europe-west1) as illustrated in the network diagram:
Start the configuration
1. On the Navigation menu, click Network Services > Load balancing.
2. Click Create load balancer.
3. Under HTTP(S) Load Balancing, click Start configuration.
4. Select From Internet to my VMs, then click Continue.
5. For Name, type http-lb.
Configure the backend
Backend services direct incoming traffic to one or more attached backends. Each backend is composed of an instance group and additional serving capacity metadata.
1. Click Backend configuration.
2. For Backend services & backend buckets, click Create or select backend services & backend buckets > Backend services > Create a backend service.
3. Specify the following, and leave the remaining settings as their defaults:
This configuration means that the load balancer attempts to keep each instance of us-central1-mig at or below 50 requests per second (RPS).
4. Click Done.
5. Click Add backend.
6. Specify the following, and leave the remaining settings as their defaults:
This configuration means that the load balancer attempts to keep each instance of europe-west1-mig at or below 80% CPU utilization.
7. Click Done.
8. For Health Check, select http-health-check (TCP).
9. Expand Advanced configurations (Session affinity, connection draining timeout, security policies) option and check the Enable logging checkbox.
10. Specify Sample rate as 1.
11. Click Create.
Configure the frontend
The host and path rules determine how your traffic will be directed. For example, you could direct video traffic to one backend and direct static traffic to another backend. However, you are not configuring the host and path rules in this lab.
1. Click Frontend configuration.
2. Specify the following, and leave the remaining settings as their defaults:
3. Click Done.
4. Click Add Frontend IP and port.
5. Specify the following, and leave the remaining settings as their defaults:
6. Click Done.
HTTP(S) load balancing supports both IPv4 and IPv6 addresses for client traffic. Client IPv6 requests are terminated at the global load balancing layer and then proxied over IPv4 to your backends.
Review and create the HTTP load balancer
- Click Review and finalize.
2. Review the Backend services and Frontend.
3. Click Create. Wait for the load balancer to be created.
4. Click on the name of the load balancer (http-lb).
5. Note the IPv4 and IPv6 addresses of the load balancer for the next task. They will be referred to as [LB_IP_v4] and [LB_IP_v6], respectively.
The IPv6 address is the one in hexadecimal format.
Task 6. Stress test the HTTP load balancer
Now that you have created the HTTP load balancer for your backends, it is time to verify that traffic is forwarded to the backend service.
Access the HTTP load balancer
1.Open a new tab in your browser and navigate to http://[LB_IP_v4]. Make sure to replace [LB_IP_v4] with the IPv4 address of the load balancer.
Accessing the HTTP load balancer might take a couple of minutes. In the meantime, you might get a 404 or 502 error. Keep trying until you see the page of one of the backends.
Stress test the HTTP load balancer
Create a new VM to simulate a load on the HTTP load balancer. Then determine whether traffic is balanced across both backends when the load is high.
1. In the Cloud Console, on the Navigation menu , click Compute Engine > VM instances.
2. Click Create instance.
3. Specify the following, and leave the remaining settings as their defaults:
Because us-west1 is closer to us-central1 than to europe-west1, traffic should be forwarded only to us-central1-mig (unless the load is too high).
4. For Boot Disk, click Change.
5. Click Custom images.
6. For Image, select mywebserver.
7. Click Select.
8. Click Create. Wait for the stress-test instance to be created.
9. For stress-test, click SSH to launch a terminal and connect.
10. To create an environment variable for your load balancer IP address, run the following command:
export LB_IP=<Enter your [LB_IP_v4] here>
11. Verify it with echo:
12. To place a load on the load balancer, run the following command:
13. In the Cloud Console, on the Navigation menu , click Network Services > Load balancing.
14. Click Backends.
15. Click http-backend.
16. Monitor the Frontend Location (Total inbound traffic) between North America and the two backends for a couple of minutes.
At first, traffic should just be directed to us-central1-mig, but as the RPS increases, traffic is also directed to europe-west1-mig. This demonstrates that by default traffic is forwarded to the closest backend, but if the load is very high, traffic can be distributed across the backends.
17. In the Cloud Console, on the Navigation menu , click Compute Engine > Instance groups.
18. Click on us-central1-mig to open the instance group page.
19. Click Monitoring to monitor the number of instances and LB capacity.
20. Repeat the same for the europe-west1-mig instance group.
Depending on the load, you might see the backends scale to accommodate the load.
That Concludes our tutorial for Configuring an HTTP Load Balancer with Autoscaling.
Happy Learning !!!
Google Cloud HTTP(S) load balancing is implemented at the edge of Google’s network in Google’s points of presence (POP) around the world. User traffic directed to an HTTP(S) load balancer enters the POP closest to the user and is then load-balanced over Google’s global network to the closest backend that has sufficient available capacity.
In this lab, we will configure an HTTP load balancer as shown in the diagram below. Then, we will stress test the load balancer to demonstrate global load balancing and autoscaling.
Task 1. Configure a health check firewall rule
Health checks determine which instances of a load balancer can receive new connections. For HTTP load balancing, the health check probes to your load-balanced instances come from addresses in the ranges 130.211.0.0/22 and 35.191.0.0/16. Your firewall rules must allow these connections.
Create the health check rule
Create a firewall rule to allow health checks.
1. In the Cloud Console, on the Navigation menu , click VPC network > Firewall. Notice the existing ICMP, internal, RDP, and SSH firewall rules.
Each Google Cloud project starts with the default network and these firewall rules.
2. Click Create Firewall Rule.
3. Specify the following, and leave the remaining settings as their defaults:
Make sure to include the /22 and /16 in the Source IP ranges.
4. Select tcp and specify port 80.
5. Click Create.
Task 2: Create a NAT configuration using Cloud Router
The Google Cloud VM backend instances that you setup in Task 3 will not be configured with external IP addresses.
Instead, you will setup the Cloud NAT service to allow these VM instances to send outbound traffic only through the Cloud NAT, and receive inbound traffic through the load balancer.
Create the Cloud Router instance
1. In the Cloud Console, on the Navigation menu , click Network services > Cloud NAT.
2. Click Get started.
3. Specify the following, and leave the remaining settings as their defaults:
4. Click Cloud Router, and select Create new router.
5. For Name, type nat-router-us-central1.
6. Click Create.
7. In Create a NAT gateway, click Create.
Wait until the NAT Gateway Status changes to Running before moving onto the next task.
Task 3: Create a custom image for a web server
Create a custom web server image for the backend of the load balancer.
Create a VM
1. In the Cloud Console, on the Navigation menu , click Compute Engine > VM instances.
2. Click Create.
3. Specify the following, and leave the remaining settings as their defaults:
4. Click Management, security, disks, networking, sole tenancy.
5. Click Disks, and clear Delete boot disk when instance is deleted.
6. Click Networking.
· For Network tags, type allow-health-checks.
· Under Network interfaces , click default.
· Under External IP dropdown, select None.
4. Click Done.
5. Click Create.
Customize the VM
1. For webserver, click SSH to launch a terminal and connect.
2. If you see the Connection via Cloud Identity-Aware Proxy Failed popup, click Retry.
3. To install Apache2, run the following commands:
4. To start the Apache server, run the following command:
5. To test the default page for the Apache2 server, run the following command:
The default page for the Apache2 server should be displayed.
Set the Apache service to start at boot
The software installation was successful. However, when a new VM is created using this image, the freshly booted VM does not have the Apache web server running. Use the following command to set the Apache service to automatically start on boot. Then test it to make sure it works.
- In the webserver SSH terminal, set the service to start on boot:
2. In the Cloud Console, select webserver, and then click Reset.
3. In the confirmation dialog, click Reset.
Reset will stop and reboot the machine. It keeps the same IPs and the same persistent boot disk, but memory is wiped. Therefore, if the Apache service is available after the reset, the update-rc command was successful.
4. Check the server by connecting via SSH to the VM and entering the following command:
NOTE: If you see the Connection via Cloud Identity-Aware Proxy Failed popup, click Retry .
5. The result should show Started The Apache HTTP Server.
Prepare the disk to create a custom image
Verify that the boot disk will not be deleted when the instance is deleted.
1. On the VM instances page, click webserver to view the VM instance details.
2. Under Boot disk, verify that When deleting instance is set to Keep disk.
3. Return to the VM instances page, click webserver, and click Delete.
4. In the confirmation dialog, click Delete.
5. In the left pane, click Disks and verify that the webserver disk exists.
Create the custom image
1. In the left pane, click Images.
2. Click Create image.
3. Specify the following, and leave the remaining settings as their defaults:
4. Click Create.
You have created a custom image that multiple identical webservers can be started from. At this point, you could delete the webserver disk.
The next step is to use that image to define an instance template that can be used in the managed instance groups.
Task 4. Configure an instance template and create instance groups
A managed instance group uses an instance template to create a group of identical instances. Use these to create the backends of the HTTP load balancer.
Configure the instance template
An instance template is an API resource that you can use to create VM instances and managed instance groups. Instance templates define the machine type, boot disk image, subnet, labels, and other instance properties.
1. In the Cloud Console, on the Navigation menu , click Compute Engine > Instance templates.
2. Click Create instance template.
3. For Name, type mywebserver-template.
4. For Series, select N1.
5. For Machine type, select f1-micro (1 vCPU).
6. For Boot disk, click Change.
7. Click Custom images.
8. For Image, Select mywebserver.
9. Click Select.
10. Click Management, security, disks, networking, sole tenancy.
11. Click Networking.
· For Network tags, type allow-health-checks.
· Under External IP dropdown, select None.
12. Click Create.
Create the managed instance groups
Create a managed instance group in us-central1 and one in europe-west1.
1. On the Navigation menu, click Compute Engine > Instance groups.
2. Click Create Instance group.
3. Specify the following, and leave the remaining settings as their defaults:
4. Under Autoscaling metrics, click on the edit pencil icon.
5. Under Metric type, select HTTP load balancing utilization.
6. Enter Target HTTP load balancing utilization to 80.
7. Click Done.
8. Set Cool down period to 60 seconds.
9. Enter Minimum number of instances 1 and Maximum number of instances 2.
Managed instance groups offer autoscaling capabilities that allow you to automatically add or remove instances from a managed instance group based on increases or decreases in load. Autoscaling helps your applications gracefully handle increases in traffic and reduces cost when the need for resources is lower. You just define the autoscaling policy, and the autoscaler performs automatic scaling based on the measured load.
10. For Health check, select Create a health check.
11. Specify the following, and leave the remaining settings as their defaults:
Managed instance group health checks proactively signal to delete and recreate instances that become unhealthy.
12. Click Save and continue.
13. For Initial delay, type 60. This is how long the Instance Group waits after initializing the boot-up of a VM before it tries a health check. You don’t want to wait 5 minutes for this during the lab, so you set it to 1 minute.
14. Click Create.
15. Click OK.
NOTE: If a warning window will appear stating that There is no backend service attached to the instance group. Ignore this; you will configure the load balancer with a backend service in the next section of the lab.
Repeat the same procedure for europe-west1-mig in europe-west1:
16. Click Create Instance group.
17. Specify the following, and leave the remaining settings as their defaults:
18. For Health check, select http-health-check (TCP).
19. For Initial delay, type 60.
20. Click Create.
21. Click OK in the dialog window.
Verify the backends
Verify that VM instances are being created in both regions.
- On the Navigation menu, click Compute Engine > VM instances. Notice the instances that start with us-central1-mig and europe-west1-mig. These instances are part of the managed instance groups.
Task 5. Configure the HTTP load balancer
Configure the HTTP load balancer to balance traffic between the two backends (us-central1-mig in us-central1 and europe-west1-mig in europe-west1) as illustrated in the network diagram:
Start the configuration
1. On the Navigation menu, click Network Services > Load balancing.
2. Click Create load balancer.
3. Under HTTP(S) Load Balancing, click Start configuration.
4. Select From Internet to my VMs, then click Continue.
5. For Name, type http-lb.
Configure the backend
Backend services direct incoming traffic to one or more attached backends. Each backend is composed of an instance group and additional serving capacity metadata.
1. Click Backend configuration.
2. For Backend services & backend buckets, click Create or select backend services & backend buckets > Backend services > Create a backend service.
3. Specify the following, and leave the remaining settings as their defaults:
This configuration means that the load balancer attempts to keep each instance of us-central1-mig at or below 50 requests per second (RPS).
4. Click Done.
5. Click Add backend.
6. Specify the following, and leave the remaining settings as their defaults:
This configuration means that the load balancer attempts to keep each instance of europe-west1-mig at or below 80% CPU utilization.
7. Click Done.
8. For Health Check, select http-health-check (TCP).
9. Expand Advanced configurations (Session affinity, connection draining timeout, security policies) option and check the Enable logging checkbox.
10. Specify Sample rate as 1.
11. Click Create.
Configure the frontend
The host and path rules determine how your traffic will be directed. For example, you could direct video traffic to one backend and direct static traffic to another backend. However, you are not configuring the host and path rules in this lab.
1. Click Frontend configuration.
2. Specify the following, and leave the remaining settings as their defaults:
3. Click Done.
4. Click Add Frontend IP and port.
5. Specify the following, and leave the remaining settings as their defaults:
6. Click Done.
HTTP(S) load balancing supports both IPv4 and IPv6 addresses for client traffic. Client IPv6 requests are terminated at the global load balancing layer and then proxied over IPv4 to your backends.
Review and create the HTTP load balancer
- Click Review and finalize.
2. Review the Backend services and Frontend.
3. Click Create. Wait for the load balancer to be created.
4. Click on the name of the load balancer (http-lb).
5. Note the IPv4 and IPv6 addresses of the load balancer for the next task. They will be referred to as [LB_IP_v4] and [LB_IP_v6], respectively.
The IPv6 address is the one in hexadecimal format.
Task 6. Stress test the HTTP load balancer
Now that you have created the HTTP load balancer for your backends, it is time to verify that traffic is forwarded to the backend service.
Access the HTTP load balancer
1.Open a new tab in your browser and navigate to http://[LB_IP_v4]. Make sure to replace [LB_IP_v4] with the IPv4 address of the load balancer.
Accessing the HTTP load balancer might take a couple of minutes. In the meantime, you might get a 404 or 502 error. Keep trying until you see the page of one of the backends.
Stress test the HTTP load balancer
Create a new VM to simulate a load on the HTTP load balancer. Then determine whether traffic is balanced across both backends when the load is high.
1. In the Cloud Console, on the Navigation menu , click Compute Engine > VM instances.
2. Click Create instance.
3. Specify the following, and leave the remaining settings as their defaults:
Because us-west1 is closer to us-central1 than to europe-west1, traffic should be forwarded only to us-central1-mig (unless the load is too high).
4. For Boot Disk, click Change.
5. Click Custom images.
6. For Image, select mywebserver.
7. Click Select.
8. Click Create. Wait for the stress-test instance to be created.
9. For stress-test, click SSH to launch a terminal and connect.
10. To create an environment variable for your load balancer IP address, run the following command:
export LB_IP=<Enter your [LB_IP_v4] here>
11. Verify it with echo:
12. To place a load on the load balancer, run the following command:
13. In the Cloud Console, on the Navigation menu , click Network Services > Load balancing.
14. Click Backends.
15. Click http-backend.
16. Monitor the Frontend Location (Total inbound traffic) between North America and the two backends for a couple of minutes.
At first, traffic should just be directed to us-central1-mig, but as the RPS increases, traffic is also directed to europe-west1-mig. This demonstrates that by default traffic is forwarded to the closest backend, but if the load is very high, traffic can be distributed across the backends.
17. In the Cloud Console, on the Navigation menu , click Compute Engine > Instance groups.
18. Click on us-central1-mig to open the instance group page.
19. Click Monitoring to monitor the number of instances and LB capacity.
20. Repeat the same for the europe-west1-mig instance group.
Depending on the load, you might see the backends scale to accommodate the load.
That Concludes our tutorial for Configuring an HTTP Load Balancer with Autoscaling.
Happy Learning !!!
Can you be more specific about the content of your article? After reading it, I still have some doubts. Hope you can help me.