Setting Up Internal Load Balancing

Internal Load Balancing enables you to run and scale your services behind a private load balancing IP address which is accessible only to instances internal to your Virtual Private Cloud (VPC).

For a quick introduction to Internal Load Balancing, see Internal Load Balancing in 5 mins.

Overview

Google Cloud Platform (GCP) offers Internal Load Balancing for your TCP/UDP-based traffic. Internal Load Balancing enables you to run and scale your services behind a private load balancing IP address that is accessible only to your internal virtual machine instances.

Use Internal Load Balancing to configure an Internal Load Balancing IP address to act as the frontend to your private backend instances. You do not need a public IP for your load balanced service. Your internal client requests stay internal to your VPC network and region, likely resulting in lowered latency since all your load-balanced traffic will stay within Google’s network. Overall, your configuration becomes simpler.

Internal Load Balancing works with auto mode VPC networks, custom mode VPC networks, and legacy networks. Internal Load Balancing can also be implemented with regional managed instance groups. This allows you to autoscale across a region, making your service immune to zonal failures.

This rest of this user guide walks you through the features and configuration for Internal Load Balancing for TCP/UDP.

About Internal Load Balancing

Internal Load Balancing enables you to support use cases such as the traditional 3-tier web services, where your web tier uses external HTTP(S) or external TCP/UDP load balancing and your instances running the application tier or backend databases are deployed behind Internal Load Balancing.

3-tier web app with HTTP(S) load balancing and Internal Load Balancing (click to enlarge)
3-tier web app with HTTP(S) load balancing and Internal Load Balancing (click to enlarge)

With Internal Load Balancing, you can:

  • Load balance TCP/UDP traffic using a private frontend IP
    • You can configure the Internal load-balancing IP from within your VPC network.
  • Load balance across instances in a region
    • Allows you to instantiate instances in multiple availability zones within the same region.
  • Configure health checking for your backends
    • Backend instances are health checked by GCP health checking systems
    • You can configure a TCP, SSL(TLS), HTTP, or HTTPS health check
  • Get all the benefits of a fully managed load balancing service that scales as needed to handle client traffic.
    • The highly-available load balancer is not a choke point.

Architecture

Internal Load Balancing can be implemented in a variety of ways, such as a proxy.

In the traditional proxy model of Internal Load Balancing, as shown below on the left, you configure an internal IP on a load balancing device or instance(s) and your client instance connects to this IP. Traffic coming to the IP is terminated at the load balancer. The load balancer selects a backend and establishes a new connection to it. In effect, there are two connections: Client<->Load Balancer and Load Balancer<->Backend.

Internal Load Balancing for TCP/UDP architecture (click to enlarge)
Internal Load Balancing for TCP/UDP architecture (click to enlarge)

GCP Internal Load Balancing distributes client instance requests to the backends using a different approach, as shown on the right. It uses lightweight load-balancing built on top of Andromeda network virtualization stack to provide software-defined load balancing that directly delivers the traffic from the client instance to a backend instance.

Internal Load Balancing is not a device or an instance-based solution, but software-defined, fully distributed load balancing.

Deploying Internal Load Balancing with GCP clients

When your clients are in the VPC network, Internal Load Balancing distributes internal client traffic across backends that run private services. Your client instances, the Internal Load Balancing IP address, and the backend instances are all configured on your VPC network.

Internal Load Balancing when clients are in a VPC network (click to enlarge)
Internal Load Balancing when clients are in a VPC network (click to enlarge)

In the illustration, the client instance in Subnet 1 connects to the internal load balancing IP address (10.240.0.200). Traffic from that instance is load balanced to a backend instance (10.240.0.2) in Subnet 2.

Deploying Internal Load Balancing with clients across VPN or Interconnect

When your clients connect across a VPN or Interconnect, they can be located in your on-premises network, in another cloud provider's network, or in another GCP network. Traffic from your clients reaches the internal load balancer in the VPC network through Cloud VPN. This traffic is then internally load balanced to a healthy backend instance belonging to the backend service that the forwarding rule points to.

The VPN tunnel and the internal load balancer must be in the same region.

Internal Load Balancing when clients connect across VPN (click to enlarge)
Internal Load Balancing when clients connect across VPN (click to enlarge)

The above deployment includes instances in Subnet 2 and 3 that serve content for a shopping cart application. These instances are a part of a GCP Network called shopnet.

In the illustration, the client instance with the IP address 192.168.1.1 resides in your on-premises network and connects to the Internal Load Balancing IP address (10.240.0.200) in GCP using VPN. Traffic from the client is then load balanced to a backend instance (10.240.0.2) in Subnet 2.

Multiple VPN tunnels or Interconnects

When you configure multiple VPN tunnels between your non-GCP and GCP networks, your non-GCP clients access Internal Load Balancing over these tunnels as shown below.

Internal Load Balancing with multiple VPN tunnels (click to enlarge)
Internal Load Balancing with multiple VPN tunnels (click to enlarge)

In the illustration, the client instance with the IP address 192.168.1.1 resides in your on-premises network and connects to the Internal Load Balancing IP address (10.240.0.200) in GCP over VPN. Traffic can be ECMP hashed and load balanced across multiple tunnels.

As long as the number of tunnels does not change, the load balancer sends all traffic for a given session to the same backend. To send all traffic from a given client to the same backend, use session affinity.

If the number of tunnels changes, the on-premises network may choose a different tunnel for a session. The load balancer will attempt to map to the same backend, but a small percentage of connections may get reset.

Deploying Internal Load Balancing

With Internal Load Balancing, you configure a private RFC1918 address as your load balancing IP and configure backend instance groups to handle requests coming to this load balancing IP from client instances.

The backend instance groups can be zonal or regional, which enables you to configure instance groups in line with your availability requirements.

The client instances originating traffic to the Internal Load Balancing IP must belong to the same VPC network and region, but can be in different subnets, as the load balancing IP and the backends.

An Internal Load Balancing deployment example is shown below:

Internal Load Balancing deployment (click to enlarge)
Internal Load Balancing deployment (click to enlarge)

In the above example, you have a VPC network called my-internal-app, comprised of a single subnet A (10.10.0.0/16) in the us-central region. You have two backend instance groups to provide availability across two zones. The load balancing IP ( i.e., the forwarding rule IP) 10.10.10.1 is selected from the same VPC network. An instance, 10.10.100.2, in the network my-internal-app sends a request to the load balancing IP 10.10.10.1. This request gets load balanced to an instance in one of the instance groups, IG1 and IG2.

Configuration details for the above deployment are described below.

Load balancing IP address

With Internal Load Balancing, the load balancing IP is a private RFC1918 address.

You can assign the IP address of an internal load balancer, such as the forwarding rule IP, in one of the following ways:

  • You select your Internal Load Balancing IP

    You can specify an unallocated IP address from the region the forwarding rule is associated with as the load balancing IP. This IP address can be from any subnet in that region that is part of the overall VPC network. If you are configuring Internal Load Balancing in a legacy network, then you can use any unused IP address in the network.

    You need to manually determine which IP addresses are already in use by listing all existing instance IP addresses and other forwarding rule IP addresses for the VPC network/subnet.

    You can select an Internal Load Balancing IP by specifying an ephemeral internal IP or you can reserve a static internal IP address that remains reserved to the project until you remove it.

    Once you select and specify the internal IP address for your forwarding rule, it will remain allocated as long as the forwarding rule exists. When the forwarding rule is deleted, its IP address will either return back to the available pool of IP addresses for the VPC network and may get allocated to an instance or another forwarding rule, or it returns back to the project if it is a static internal IP address, available for you to assign to another resource.

  • Load balancing auto-allocates your frontend IP

    You can have the IP be allocated automatically by creating a forwarding rule without specifying an IP address. In this case, GCP will assign an unallocated internal IP address to the forwarding rule from the VPC network/subnet that it is associated with. The IP address will remain allocated only as long as the forwarding rule exists.

Internal Load Balancing selection algorithm

The backend instance for a client is selected using a hashing algorithm that takes instance health into consideration.

By default, the load balancer directs connections from a client to a backend instance using a 5-tuple hash, which uses the following five parameters for hashing:

  • client source IP address
  • client port
  • destination IP address (the load balancing IP address)
  • destination port
  • protocol (either TCP or UDP).

If you wish the load balancer to direct all traffic from a client to a specific backend instance, then use one of the following options for session affinity:

  • Hash based on 3-tuple (Client IP, Dest IP, Protocol)
  • Hash based on 2-tuple (Client IP, Dest IP)

The Session affinity section provides more details on these options.

Session affinity

As described in the previous section on selection algorithm, the default behavior is that connections from a client get load balanced across all backend instance using a 5-tuple hash. The 5-tuple hash uses the client source IP, client port, destination IP (load balancing IP), destination port, and the protocol (either TCP or UDP).

However, in many instances such as the case where web applications store state locally on the instance and require all the traffic from a client to be load balanced to the same backend instance, you want all traffic from the client instance to be load balanced to the same backend instance. In absence of this capability, the traffic might fail or end up being serviced sub-optimally.

With Internal Load Balancing, you can enable all traffic from a client to stick to a specific backend instance by enabling the affinity feature.

You can enable the following types of affinity:

  • Hash based on 3-tuple (client_ip_proto) (Client IP, Dest IP, Protocol)
    • Use this affinity if you want all traffic from a client to be directed to the same backend instance based on a hash of the above three parameters.
  • Hash based on 2-tuple (client_ip) (Client IP, Dest IP)
    • Use this affinity if you want all traffic from a client irrespective of the protocol to be directed to the same backend instance based on a hash of the above two parameters.

In general, if you enable 3- or 2- tuple affinity, your client traffic will be load balanced to the same backend, but overall the traffic may not be as evenly distributed as the default 5-tuple hash. In general, a given connection will stay on the same backend instance as long as it is healthy.

Health Checking

Health checks determine which instances can receive new connections. The health checker probes instances at specified intervals. Instances that do not respond successfully to the probe a specified number of times in a row are marked as UNHEALTHY. No new connections are sent to the instance, though existing connections are allowed to continue. The health checker continues to poll unhealthy instances. If an instance responds successfully to the probes a specified number of times in a row, it is marked HEALTHY again and can receive new connections.

Internal Load Balancing supports four types of health checks:

  • TCP health checks
  • SSL (TLS) health checks
  • HTTP health checks
  • HTTPS health checks

If your traffic is HTTP(S), then HTTP(S) health checks provide the highest fidelity check because they verify that the web server is up and serving traffic, not just that the instance is healthy. Configure the SSL health checks if your traffic is not HTTPS but is encrypted via SSL(TLS). For all TCP traffic that is not HTTP(S) or SSL(TLS), you can configure a TCP health check.

For an HTTP(S) health check probe to be deemed successful, the instance must return a valid HTTP response with code 200 and close the connection normally within the configured period. If it does this a specified number of times in a row, the health check returns a status of HEALTHY for that instance. If an instance fails a specified number of health check probes in a row, it is marked UNHEALTHY without any notification being sent. UNHEALTHY instances do not receive new connections, but existing connections are allowed to continue. If an instance later passes a health check (successfully responds to a specified number of health check probes), it again starts receiving new connections, again without any notification.

When you configure the health check to be of type SSL, an SSL connection is opened to each of your instances. When you configure the health check to be of type TCP, a TCP connection is opened. In both cases, if the handshake is successful, the health check probe is considered to be successful. The health check is passed if a specified number of probes are successful, and it is failed if a specified number of handshakes in a row are unsuccessful. Existing connections are allowed to continue on instances that have failed their health check. A TCP or SSL health check probe can use one of the following checks:

  • Simple handshake health check (default): the health checker attempts a simple TCP or SSL handshake. If it is successful, the instance passes that round of the probe.
  • Request/response health check: you provide a request string for the health checker to send after completing the TCP or SSL handshake. If the instance returns the response string you've configured, the instance passes that round of the probe. Both the request and response strings can be up to 1024 bytes.

High availability

Internal Load Balancing is a fully managed Google Cloud Platform service, so you do not need any configuration to ensure high availability of the load balancer itself. It is a fully distributed service which will scale as needed to handle client traffic. Limits are described in the Limits section.

You can configure multiple instance groups to deliver high availability for your service. Instance groups are zonal in scope, so you can configure instance groups in multiple zones to guard against instance failures in a single zone.

When you configure more than one instance group, then the instances in all these instance groups are treated as one pool of instances and Internal Load Balancing distributes your user requests across the healthy instances in this group using the hash algorithm described in the Internal Load Balancing selection algorithm section.

Instance groups in multiple zones for HA (click to enlarge)
Instance groups in multiple zones for HA (click to enlarge)

In effect, you can think of your deployment as logically comprised of one large pool that spans one or more zones in the region where you have deployed Internal Load Balancing.

In the above diagram, assuming all instances are healthy, the client instances are load balanced to a pool composed of instances 1, 2, 3, and 4.

Setting up Internal Load Balancing

Setting up Internal Load Balancing (click to enlarge)
Setting up Internal Load Balancing (click to enlarge)

An Internal Load Balancing configuration consists of several components. All these components must belong to the same VPC network and region. The client instances originating traffic must belong to the same VPC network and region as the load balancing forwarding rule IP, backend services, and instance groups. The client instances do not have to be in the same subnet as the load balanced instances.

This example sets up an internal load balancer for testing purposes.

We will configure the following:

  1. Four instances spread across two zones in the same region
  2. Instance groups for holding the instances
  3. Backend components, which include the following:
    • health check - used to monitor instance health
    • backend service - monitors instance groups and prevents them from exceeding configured usage
    • backends - hold the instance groups
  4. A forwarding rule, with an internal IP address, that sends user traffic to the proxy
  5. A firewall rule that allows traffic from the load balancer IP address range
  6. A standalone client instance that can be used to test the load balancer

After that, we'll test our configuration.

Configure a test environment

The following sections walk you through creating the components of the test environment.

Configure a VPC network and subnet

Internal Load Balancing works with auto mode VPC networks, custom mode VPC networks, and legacy networks. For this example, we'll use a custom mode VPC network.

Console


  1. Go to the VPC networks page in the Google Cloud Platform Console.
    Go to the VPC network page
  2. Click Create VPC network.
  3. Enter a Name of my-custom-network.
  4. Under subnets, enter a Name of my-custom-subnet.
  5. Set Region to us-central1.
  6. Enter an IP address range of 10.128.0.0/20.
  7. Click Create.

gcloud


Create a custom VPC network

gcloud compute networks create my-custom-network --subnet-mode custom

Created     [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/my-custom-network].
NAME               MODE    IPV4_RANGE  GATEWAY_IPV4
my-custom-network  custom

Create a new subnet in your custom VPC network

gcloud compute networks subnets create my-custom-subnet \
    --network my-custom-network \
    --range 10.128.0.0/20 \
    --region us-central1

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/subnetworks/my-custom-subnet].
NAME              REGION       NETWORK            RANGE
my-custom-subnet  us-central1  my-custom-network  10.128.0.0/20

  • my-custom-network - the name of the VPC network you create, in which you then create a custom subnet.
  • my-custom-subnet - the name of the subnet you are creating.
  • 10.128.0.0/20 - For the range, this can be any valid RFC1918 range that does not overlap another range in the same network. If you are creating your subnet in an existing VPC network, you may have to choose a different range.

Configure firewall rules

Instances on this VPC network will not be reachable until firewall rules are created. As an example, you can allow all internal traffic between instances and allow SSH, RDP, and ICMP traffic from all sources.

Console


Create firewall rule that allows all traffic within the subnet

  1. Go to the Firewall rules page in the Google Cloud Platform Console.
    Go to the Firewall rules page
  2. Click Create firewall rule.
  3. Enter a Name of allow-all-10-128-0-0-20.
  4. Set Network to my-custom-network.
  5. Set Source filter to IP ranges.
  6. Set Source IP ranges to 10.128.0.0/20.
  7. Set Specified protocols and ports to tcp;udp;icmp.
  8. Click Create.

Create firewall rule that allows SSH, RDP, and ICMP from anywhere

  1. Create a second firewall rule with a Name of allow-tcp22-tcp3389-icmp.
  2. Set Network to my-custom-network.
  3. Set Source filter to IP ranges.
  4. Set Source IP ranges to 0.0.0.0/0 (allow from any source).
  5. Set Specified protocols and ports to tcp:22;tcp:3389;icmp.
  6. Click Create.

gcloud


Create firewall rule that allows all traffic within the subnet

gcloud compute firewall-rules create allow-all-10-128-0-0-20 \
    --network my-custom-network \
    --allow tcp,udp,icmp \
    --source-ranges 10.128.0.0/20

Create firewall rule that allows SSH, RDP, and ICMP from anywhere

gcloud compute firewall-rules create allow-tcp22-tcp3389-icmp \
    --network my-custom-network \
    --allow tcp:22,tcp:3389,icmp

Configure instances and instance groups

A production system would normally use managed instance groups based on instance templates, but this setup is quicker for initial testing.

Create two instances in each zone

For testing purposes, we'll install Apache on each instance. These instance are all being created with a tag of int-lb. This tag is used later by the firewall rule.

The four instances are named ig-us-central1-1 through ig-us-central1-4.

Console


Create instances

  1. Go to the VM instances page in the Google Cloud Platform Console.
    Go to the VM instances page
  2. Click Create instance.
  3. Set Name to ig-us-central1-1.
  4. Set the Zone to us-central1-b.
  5. Click Management, disk, networking, SSH keys to reveal advanced settings.
  6. Under Management, click Networking and populate the Tags field with int-lb.
  7. Under Networking, edit the network interface under Network interfaces.
  8. Under Networking, ​set Network to my-custom-network and Subnetwork to my-custom-subnet.
  9. Leave the default values for rest of the fields.
  10. Click Management and set the Startup script to
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-1</h1></body></html>' | sudo tee /var/www/html/index.html
  11. Create ig-us-central1-2 with the same settings, except with Startup script set to
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-2</h1></body></html>' | sudo tee /var/www/html/index.html
  12. Create ig-us-central1-3 with the same settings, except with Zone set to us-central1-c and Startup script set to
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-3</h1></body></html>' | sudo tee /var/www/html/index.html
  13. Create ig-us-central1-4 with the same settings, except with Zone set to us-central1-c and Startup script set to
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>' | sudo tee /var/www/html/index.html

gcloud


gcloud compute instances create ig-us-central1-1 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-b \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-1</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-1].
NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
ig-us-central1-1 us-central1-b n1-standard-1             10.128.0.3  23.251.150.133 RUNNING

gcloud compute instances create ig-us-central1-2 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-b \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-2</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-2].
NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
ig-us-central1-2 us-central1-b n1-standard-1             10.128.0.11 23.251.148.160 RUNNING

gcloud compute instances create ig-us-central1-3 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-c \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-3</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-c/instances/ig-us-central1-3].
NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
ig-us-central1-3 us-central1-c n1-standard-1             10.128.0.12 104.196.31.214 RUNNING

gcloud compute instances create ig-us-central1-4 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-c \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-c/instances/ig-us-central1-4].
NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
ig-us-central1-4 us-central1-c n1-standard-1             10.128.0.13 104.196.25.101 RUNNING

Create an instance group for each zone and add instances

Console


  1. Go to the Instance groups page in the Google Cloud Platform Console.
    Go to the Instance groups page
  2. Click Create instance group.
  3. Set the Name to us-ig1.
  4. Set the Zone to us-central1-b.
  5. Under Group type, select Unmanaged instance group.
  6. Set Network to my-custom-network.
  7. Set Subnetwork to my-custom-subnet.
  8. From VM instances select ig-us-central1-1 and ig-us-central1-2.
  9. Leave other settings as they are.
  10. Click Create.
  11. Repeat steps, but set the following:
    • Name: us-ig2
    • Zone: us-central1-c
    • Instances: ig-us-central1-3 and ig-us-central1-4.
  12. Confirm that you now have two instance groups, each with two instances.

gcloud


  1. Create the us-ig1 instance group.

    gcloud compute instance-groups unmanaged create us-ig1 \
        --zone us-central1-b
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].
    NAME   ZONE          NETWORK MANAGED INSTANCES
    us-ig1 us-central1-b                 0

  2. Add ig-us-central1-1 and ig-us-central1-2 to us-ig1

    gcloud compute instance-groups unmanaged add-instances us-ig1 \
        --instances ig-us-central1-1,ig-us-central1-2 --zone us-central1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].

  3. Create the us-ig2 instance group.

    gcloud compute instance-groups unmanaged create us-ig2 \
        --zone us-central1-c
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-c/instanceGroups/us-ig2].
    NAME   ZONE          NETWORK MANAGED INSTANCES
    us-ig2 us-central1-c                  0

  4. Add ig-us-central1-3 and ig-us-central1-4 to us-ig2

    gcloud compute instance-groups unmanaged add-instances us-ig2 \
        --instances ig-us-central1-3,ig-us-central1-4 \
        --zone us-central1-c
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/ig-us-central1-c/instanceGroups/us-ig2].

Configure the load balancer

Console


Create the load balancer and configure a backend service

  1. Go to the Load balancing page in the Google Cloud Platform Console.
    Go to the Load balancing page
  2. Click Create load balancer.
  3. Under TCP load balancing, click Start configuration.
  4. Under Internet facing or internal only select Only between my VMs.
  5. Click Continue.
  6. Set the Name to my-int-lb.

Configure backend services

  1. Click Backend configuration.
  2. The Name of the backend service appears as my-int-lb.
  3. Set Region to us-central1.
  4. Set Network to my-custom-network.
  5. Under Backends, select instance group us-ig1.
  6. Click Add backend.
  7. Select instance group us-ig2.
  8. Under Health check, select Create another health check.
    1. Set the health check Name to my-tcp-health-check.
    2. Set Protocol to TCP.
    3. Leave the other settings the same.
    4. Click Save and continue.
  9. Verify that there is a blue check mark next to Backend configuration in the Google Cloud Platform Console. If not, double-check that you have completed all the steps above.

Configure frontend services

  1. Click Frontend configuration.
  2. Under Subnetwork, select my-custom-subnet.
  3. Under Internal IP, select Ephemeral (Automatic).
  4. Set Ports to 80.
  5. Verify that there is a blue check mark next to Frontend configuration in the Google Cloud Platform Console. If not, double-check that you have completed all the steps above.

Review and finalize

  1. Click Review and finalize.
  2. Double-check your settings.
  3. Click Create.

gcloud


Create a health check

gcloud compute health-checks create tcp my-tcp-health-check \
    --port 80

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/my-tcp-health-check].
NAME                PROTOCOL
my-tcp-health-check TCP

Create a backend service

gcloud compute backend-services create my-int-lb \
    --load-balancing-scheme internal \
    --region us-central1 \
    --health-checks my-tcp-health-check \
    --protocol tcp

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/backendServices/my-int-lb].
NAME               BACKENDS PROTOCOL
my-int-lb          TCP

Add instance groups to your backend service

Internal Load Balancing spreads incoming connections based on the session affinity setting. If session affinity is not set, the load balancer spreads all connections across all available instances as evenly as possible regardless of current load.

gcloud compute backend-services add-backend my-int-lb \
    --instance-group us-ig1 \
    --instance-group-zone us-central1-b \
    --region us-central1

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/backendServices/my-int-lb].

gcloud compute backend-services add-backend my-int-lb \
    --instance-group us-ig2 \
    --instance-group-zone us-central1-c \
    --region us-central1
<