Transitioning a network load balancer from target pool to backend service

This guide provides instructions for transitioning an existing network load balancer from a target pool backend to a regional backend service.

Moving to a regional backend service allows you to take advantage of features such as non-legacy health checks (for TCP, SSL, HTTP, HTTPS, and HTTP/2), managed instance groups, connection draining, and failover policy.

This guide walks you through transitioning the following sample target pool-based network load balancer to use a regional backend service instead.

Network load balancer with a target pool
Before:Network Load Balancing with a target pool

Your resulting backend service-based network load balancer deployment will look like this.

Network load balancer with a regional backend service
After: Network Load Balancing with a regional backend service

This example assumes you have a traditional target pool-based network load balancer with two instances in zone us-central-1a, and 2 instances in zone us-central-1c.

The high-level steps required for such a transition are:

  1. Group your target pool instances into instance groups.
    Backend services only work with managed or unmanaged instance groups. Note that while there is no limit on the number of instances that can be placed into a single target pool, instance groups do have a maximum size. If your target pool has more than this maximum number of instances, you'll need to split its backends across multiple instance groups.
    If your existing deployment includes a backup target pool, create a separate instance group for those instances. This instance group will be configured as a failover group.
  2. Create a regional backend service.
    If your deployment includes a backup target pool, you will need to specify a failover ratio while creating the backend service. This should match the failover ratio previously configured for the target pool deployment.
  3. Add instance groups (created previously) to the backend service.
    If your deployment includes a backup target pool, mark the corresponding failover instance group with a --failover flag when adding it to the backend service.
  4. Configure a forwarding rule that points to the new backend service.
    You have 2 options here:
    • (Recommended) Update the existing forwarding rule to point to the backend service.
      OR
    • Create a new forwarding that points to the backend service. This requires you to create a new IP address for the load balancer's frontend. Then modify your DNS settings to seamlessly transition from the old target pool-based load balancer's IP address to the new IP address.

Before you begin

Install the gcloud command-line tool. For a complete overview of the tool, see the gcloud Tool Guide. You can find commands related to load balancing in the gcloud compute command group.

If you haven't run the gcloud command-line tool previously, first run gcloud init to authenticate.

This guide assumes that you are familiar with bash.

Creating the zonal unmanaged instance groups

Create a zonal unmanaged instance group for each of the zones in which you have backends. Depending on your setup, you can divide your instances across as many instance groups as needed. For our example, we are only using two instance groups, one for each zone, and placing all the backend VMs in a given zone in the associated instance group.

For this example, we create two instance groups: one in the uc-central1-a zone and one in the us-central1-c zone.

Set up the instance groups

Cloud Console

  1. Go to the Instance groups page in the Cloud Console.

    Go to the Instance groups page

  2. Click Create instance group.
  3. Choose New unmanaged instance group on the left.
  4. For the Name, enter ig-us-1.
  5. Under Location, select Single zone.
  6. For the Region, select us-central1.
  7. For the Zone, select us-central1-a.
  8. Select the Network and Subnetwork depending on where your instances are located. In this example, the existing target pool instances are in the default network and subnetwork.
  9. Under VM Instances, select the two instances to be added to this instance group.
  10. Click Create.
  11. Repeat these steps to create a second instance group with the following specifications:
    • Name: ig-us-2
    • Region: us-central1
    • Zone: us-central1-c Add the two instances in the us-central1-c zone to this instance group.

gcloud

  1. Create an unmanaged instance group in the us-central1-a zone with the gcloud compute instance-groups unmanaged create command.

    gcloud compute instance-groups unmanaged create ig-us-1 \
        --zone us-central1-a
    
  2. Create a second managed instance group in the us-central1-c zone.

    gcloud compute instance-groups unmanaged create ig-us-2 \
        --zone us-central1-c
    
  3. Add instances to the us-ig-1 instance group.

    gcloud compute instance-groups unmanaged add-instances us-ig-1 \
        --instances BACKEND_INSTANCE_1,BACKEND_INSTANCE_2 \
        --zone us-central1-a
    
  4. Add instances to the us-ig-2 instance group.

    gcloud compute instance-groups unmanaged add-instances us-ig-2 \
        --instances BACKEND_INSTANCE_3,BACKEND_INSTANCE_4 \
        --zone us-central1-c
    

If your existing load balancer deployment also has a backup target pool, repeat these steps to create a separate failover instance group for those instances.

Create a health check

Create a health check to determine the health of the instances in your instance groups. Your existing target pool-based network load balancer will likely have a legacy HTTP health check associated with it.

You can create a new health check that matches the protocol of the traffic that the load balancer will be distributing. Backend service-based network load balancers can use TCP, SSL, HTTP(S), and HTTP/2 health checks.

Console

  1. Go to the Health checks page in the Cloud Console.

    Go to the Health checks page

  2. Enter a Name.
  3. Set Scope to Regional.
  4. For the Region, select us-central1.
  5. For the Protocol, select HTTP.
  6. For the Port, enter 80.
  7. Click Create.

gcloud

  1. For this example, we create a non-legacy HTTP health check to be used with the backend service.

    gcloud compute health-checks create http http-health-check \
    --region us-central1 \
    --port 80
    

Configure the backend service

Use one of the following sections to create the backend service. If your existing network load balancer has a backup target pool, you will need to configure a failover ratio while creating the backend service.

You will also need to designate the failover instance group with the --failover flag when adding backends to the backend service.

Deployments without a backup target pool

gcloud

  1. Create a regional backend service in the us-central1 region.

    gcloud compute backend-services create network-lb-backend-service \
       --region us-central1 \
       --health-checks http-health-check \
       --health-checks-region us-central1 \
       --protocol TCP
    
  2. Add the two instance groups (us-ig-1 and us-ig-2) as backends to the backend service.

    gcloud compute backend-services add-backend network-lb-backend-service \
       --instance-group us-ig-1 \
       --instance-group-zone us-central1-a \
       --region us-central1
    
    gcloud compute backend-services add-backend network-lb-backend-service \
       --instance-group us-ig-2 \
       --instance-group-zone us-central1-c \
       --region us-central1
    

Deployments with a backup target pool

gcloud

  1. Create a regional backend service in the us-central1 region. Configure the backend service failover ratio to match the failover ratio previously configured for the target pool.

    gcloud compute backend-services create network-lb-backend-service \
       --region us-central1 \
       --health-check http-health-check \
       --failover-ratio 0.5
    
  2. Add the two instance groups (us-ig-1 and us-ig-2) as backends to the backend service.

    gcloud compute backend-services add-backend network-lb-backend-service \
       --instance-group us-ig-1 \
       --instance-group-zone us-central1-a \
       --region us-central1
    
    gcloud compute backend-services add-backend network-lb-backend-service \
       --instance-group us-ig-2 \
       --instance-group-zone us-central1-c \
       --region us-central1
    
  3. If you created a failover instance group, add it to the backend service. Mark this backend with the --failover flag when you add it to the backend service.

    gcloud compute backend-services add-backend network-lb-backend-service \
       --instance-group FAILOVER_INSTANCE_GROUP \
       --instance-group-zone ZONE \
       --region us-central1 \
       --failover
    

Configure the forwarding rule

You have two options to configure the forwarding rule to direct traffic to the new backend service. You can either update the existing forwarding rule or create a new forwarding rule with a new IP address.

Use the set-target flag to update the existing forwarding rule to point to the new backend service.

gcloud compute forwarding-rules set-target network-lb-forwarding-rule  \
    --backend-service network-lb-backend-service \
    --region us-central1

Create a new forwarding rule

If you don't want to update the existing forwarding rule, you can create a new forwarding rule with a new IP address. Since a given IP address can only be associated with a single forwarding rule at a time, you will need to manually modify your DNS setting to transition incoming traffic from the old IP address to the new one.

Use the following command to create a new forwarding rule with a new IP address. You can use the use the --address flag if you want to specify an IP address already reserved in the us-central1 region.

gcloud compute forwarding-rules create network-lb-forwarding-rule \
    --load-balancing-scheme external \
    --region us-central1 \
    --ports 80 \
    --backend-service network-lb-backend-service

Testing the load balancer

Test the load balancer to confirm that the forwarding rule is directing incoming traffic as expected.

Look up the load balancer's external IP address

gcloud

Enter the following command to view the external IP address of the network-lb-forwarding-rule forwarding rule used by the load balancer.

gcloud compute forwarding-rules describe network-lb-forwarding-rule
    --region us-central1

Use the nc command to access the external IP address

In this example we used the default hashing method for session affinity, so requests from the nc command will be distributed randomly to the backend VMs based on the source port assigned by your operating system.

Repeat the command a few times until you see all the backend VMs responding.

$ nc IP_ADDRESS 80

Remove resources associated with the old load balancer

Once you have confirmed that the new network load balancer works as expected, you can delete the old target pool resources and old forwarding rule (if applicable).

What's next