As a cloud engineer, your main objective is to build fault-tolerant, reliable, highly available, and cost-effective systems in the cloud. You want to design auto-scalable solutions that can respond to spikes in demand. You ensure that your architecture design is not over-provisioned and helps your organization optimize costs. In general, you take the following into consideration as you complete your designs:

• How can you add high availability (HA) to your workloads?
• How can you dynamically allocate resources to meet changing capacity requirements?
• How can you distribute traffic across different virtual machines (VMs)?

In AWS, you have built scaling plans that automate how groups of different Elastic Compute Cloud (EC2) resources respond to changes in demand. To accomplish this you have used the following:

• Elastic Load Balancer (ELB) to distribute traffic across multiple targets in multiple Availability Zones and perform health checks regularly
• Custom Amazon Machine Images (AMI) that contain the operating system of your EC2 instances along with different configurations and applications that are needed for your operations and can be used to boot VMs without manually installing all the needed services
• EC2 Launch Templates to define the parameters that are required to launch EC2 instances into Auto Scaling groups, such as the AMI ID, instance type, security group, and user data
• Auto Scaling Groups to dynamically increase and decrease the capacity of your targets to meet demand according to your own scaling policies, as well as to replace unhealthy instances and optimize costs

Now you will explore different services within Google Cloud that will help you build a highly available and scalable solution.

Overview

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, you configure an HTTP load balancer as shown in the diagram below. Then, you stress test the load balancer to demonstrate global load balancing and autoscaling.

Objectives

In this lab, you learn how to perform the following tasks:

• Create a health check firewall rule
• Create a NAT configuration using Cloud Router
• Create a custom image for a web server
• Create an instance template based on the custom image
• Create two managed instance groups
• Configure an HTTP load balancer with IPv4 and IPv6
• Stress test an HTTP load balancer

For each lab, you get a new Google Cloud project and set of resources for a fixed time at no cost.

1. Sign in to Qwiklabs using an incognito window.

2. Note the lab's access time (for example, 1:15:00), and make sure you can finish within that time.
   There is no pause feature. You can restart if needed, but you have to start at the beginning.

3. When ready, click Start lab.

4. Note your lab credentials (Username and Password). You will use them to sign in to the Google Cloud Console.

5. Click Open Google Console.

6. Click Use another account and copy/paste credentials for this lab into the prompts.
   If you use other credentials, you'll receive errors or incur charges.

7. Accept the terms and skip the recovery resource page.

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:

   Property	Value (type value or select option as specified)
   Name	fw-allow-health-checks
   Network	default
   Targets	Specified target tags
   Target tags	allow-health-checks
   Source filter	IPv4 ranges
   Source IPv4 ranges	130.211.0.0/22 and 35.191.0.0/16
   Protocols and ports	Specified protocols and ports

Note: Make sure to include the /22 and /16 in the Source IP ranges.

4. Select tcp and specify port 80.
5. Click Create.

Click Check my progress to verify the objective. Configure health check firewall rule

Task 2. Create a NAT configuration using Cloud Router

The Google Cloud VM backend instances that you set up in Task 3 will not be configured with external IP addresses.

Instead, you will set up 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:

   Property	Value (type value or select option as specified)
   Gateway name	nat-config
   Network	default
   Region	us-central1

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.

Note: Wait until the NAT Gateway Status changes to Running before moving onto the next task.

Click Check my progress to verify the objective. Create a NAT configuration using Cloud Router

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 Instance.

3. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Name	webserver
   Region	us-central1
   Zone	us-central1-a

4. Under Boot disk, click Change and for Version, select Debian GNU/Linux 10 (buster).

5. Click Show Advanced Configuration and for Deletion rule, select Keep boot disk.

6. Click Select.

7. Click Networking, Disks, Security, Management, Sole-tenancy.

8. Click Networking.

   • For Network tags, type allow-health-checks.
   • Under Network interfaces , click default.
   • Under External IPv4 IP dropdown, select None.

9. Click Done.

10. 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:

sudo apt-get update sudo apt-get install -y apache2

4. To start the Apache server, run the following command:

sudo service apache2 start

5. To test the default page for the Apache2 server, run the following command:

curl localhost

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.

1. In the webserver SSH terminal, set the service to start on boot:

sudo update-rc.d apache2 enable

2. In the Cloud Console, select webserver, and then click More actions .

3. Click Reset.

4. In the confirmation dialog, click Reset.

Note: 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.

5. Check the server by connecting via SSH to the VM and entering the following command:

sudo service apache2 status Note: If you see the Connection via Cloud Identity-Aware Proxy Failed popup, click Retry.

6. 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 Storage > Boot disk, verify that When deleting instance is set to Keep disk.
3. Return to the VM instances page, select webserver, and then click More actions () .
4. Click Delete.
5. In the confirmation dialog, click Delete.
6. 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:

   Property	Value (type value or select option as specified)
   Name	mywebserver
   Source	Disk
   Source disk	webserver

4. Click Create.

Note: 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.

Click Check my progress to verify the objective. Create a custom image for a web server

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, for Source project for images make sure that Qwiklabs project ID is selected.
8. For Image, Select mywebserver.
9. Click Select.
10. Click Networking, Disks, Security, Management, Sole-tenancy.
11. Click Networking.
    • For Network tags, type allow-health-checks.
    • Under Network interfaces , click default.
    • Under External IPv4 IP dropdown, select None.
    • Click Done.
12. Click Create.

Create the health check for managed instance groups

1. On the Navigation menu, click Compute Engine > Health checks.

2. Click Create health check.

3. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (select option as specified)
   Name	http-health-check
   Protocol	TCP
   Port	80

4. Click Create.

Managed instance group health checks proactively signal to delete and recreate instances that become unhealthy.

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:

   Property	Value (type value or select option as specified)
   Name	us-central1-mig
   Instance template	mywebserver-template
   Location	Multiple zones
   Region	us-central1

4. Under Autoscaling, enter Minimum number of instances 1 and Maximum number of instances 2.

5. Under Autoscaling signals, click on the CPU utilization.

6. Under Signal type, select HTTP load balancing utilization.

7. Enter Target HTTP load balancing utilization to 80.

8. Click Done.

9. Click Initialization period and set to 60 seconds.

Note: 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. In Autohealing, for health check type http-health-check

11. Select http-health-check (TCP)

12. 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.

13. Click Create.

14. Click Confirm in the dialog window.

Note: Wait a few minutes for the Instance Group to be created before repeating the same procedure for europe-west1-mig in europe-west1: Click Refresh until the Status changes to Transforming. Note: If a warning window appears, or you see a red exclamation mark to the left of the instance group after creation stating 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.

15. Click Create Instance Group.

16. Specify the following, and leave the remaining settings as their defaults:

    Property	Value (type value or select option as specified)
    Name	europe-west1-mig
    Instance template	mywebserver-template
    Location	Multiple zones
    Region	europe-west1
    Autoscaling > Minimum number of instances	1
    Autoscaling > Maximum number of instances	2
    Autoscaling signals > Signal Type	HTTP load balancing utilization
    Target HTTP load balancing utilization	80
    Initialization period	60

17. For Health check, select http-health-check (TCP).

18. For Initial delay, type 60.

19. Click Create.

20. Click Confirm in the dialog window.

Click Check my progress to verify the objective. Configure an instance template and create instance groups

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. Under Internet facing or internal only, select From Internet to my VMs or serverless services.
5. Under Global or Regional, select Global HTTP(S) Load Balancer (classic).
6. Click Continue.
7. For Name, type http-lb.

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:

   Property	Value (type value or select option as specified)
   Protocol	HTTP
   IP version	IPv4
   IP address	Ephemeral
   Port	80

3. Click Done.

4. Click Add Frontend IP and Port.

5. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (type value or select option as specified)
   Protocol	HTTP
   IP version	IPv6
   IP address	Ephemeral
   Port	80

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.

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. Click Backend services & backend buckets > Create a Backend Service.

3. Specify the following, and leave the remaining settings as their defaults:

   Property	Value (select option as specified)
   Name	http-backend
   Backend type	Instance group
   Instance group	us-central1-mig
   Port numbers	80
   Balancing mode	Rate
   Maximum RPS	50
   Capacity	100

Note: 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:

   Property	Value (select option as specified)
   Instance group	europe-west1-mig
   Port numbers	80
   Balancing mode	Utilization
   Maximum backend utilization	80
   Capacity	100

Note: 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.
9. Click check for the Enable logging checkbox.
10. Specify Sample rate as 1.
11. Click Create.
12. Click OK.

Review and create the HTTP load balancer

1. 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.

Note: The IPv6 address is the one in hexadecimal format.

Click Check my progress to verify the objective. Configure the HTTP load balancer

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. On the Google Cloud Console title bar, click Activate Cloud Shell ().
2. If prompted, click Continue.
3. To check the status of the load balancer, run the following command, replace [LB_IP_v4] with the IPv4 address of the load balancer:

LB_IP=[LB_IP_v4] while [ -z "$RESULT" ] ; do echo "Waiting for Load Balancer"; sleep 5; RESULT=$(curl -m1 -s $LB_IP | grep Apache); done Note: Once the load balancer is ready, the command will exit.

4. 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.

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:

   Property	Value (type value or select option as specified)
   Name	stress-test
   Region	us-west1
   Zone	us-west1-b
   Series	N1
   Machine type	f1-micro (1 vCPU)

Note: 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, for Source project for images make sure that Qwiklabs project ID is selected.

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:

echo $LB_IP

12. To place a load on the load balancer, run the following command:

ab -n 500000 -c 1000 http://$LB_IP/

Click Check my progress to verify the objective. Stress test the HTTP load balancer

13. In the Cloud Console, on the Navigation menu (), click Network Services > Load balancing.
14. Click http-lb.
15. Click Monitoring.
16. Monitor the Frontend Location (Total inbound traffic) between North America and the two backends for a couple of minutes.

Note: 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.

Note: Depending on the load, you might see the backends scale to accommodate the load.

Task 7. Review

In this lab, you configured an HTTP load balancer with backends in us-central1 and europe-west1. Then you stress-tested the load balancer with a VM to demonstrate global load balancing and autoscaling.

In AWS, a common pattern for a highly available architecture includes the following:

• Auto Scaling groups that are launching new Elastic Compute Cloud (EC2) instances— based on health checks and scaling policies, scaling in/out as needed—and replacing unhealthy instances
• Custom Amazon Machine Images (AMI) and launch templates that define the parameters of the EC2 instances that are launched within an Auto Scaling group, such as the following:

• Operating System
• Preconfigured apps
• Type of instance
• User data
• Type of mounted storage
• Security

• Elastic Load Balancers (ELBs) that can distribute traffic across target groups in different Availability Zones.

In Google Cloud, you can use the following services to achieve high availability (HA) in your workloads:

• Custom operating system (OS) images for Compute Engine: These are reusable OS images that you create from your VM’s boot disk or from other images and are preconfigured with the apps that your organization needs. These OS images can be used to launch new instances.
• Managed Instance Group (MIG): This is a collection of VMs that you can manage as a single entity and can automatically adapt to demand by growing the number of instances in the group. When resources are no longer needed, autoscaled MIGs can get rid of extra instances to reduce costs. Another feature of the MIGs is the ability to perform health checks that proactively signal to replace instances with the unhealthy state.
• Google Cloud Load Balancer: This distributes the incoming traffic across multiple instances, reducing the risk of performance issues and improving availability. In Google Cloud, you can find two main different types of load balancers:

• Internal: distribute traffic to instances inside of Google Cloud
• External: distribute traffic coming from the public internet to your Google Cloud Virtual Private Cloud (VPC) network

Also, you can choose from regional or, in the case of an external load balancer, global load balancing. An additional aspect to consider when selecting an appropriate load balancer is the type of traffic, for example TCP/UDP, HTTP and HTTPS, or SSL.

End your lab

When you have completed your lab, click End Lab. Qwiklabs removes the resources you’ve used and cleans the account for you.

You will be given an opportunity to rate the lab experience. Select the applicable number of stars, type a comment, and then click Submit.

The number of stars indicates the following:

• 1 star = Very dissatisfied
• 2 stars = Dissatisfied
• 3 stars = Neutral
• 4 stars = Satisfied
• 5 stars = Very satisfied

You can close the dialog box if you don't want to provide feedback.

For feedback, suggestions, or corrections, please use the Support tab.

Copyright 2022 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.