Configuring failover for Internal TCP/UDP Load Balancing

This guide uses an example to teach you how to configure failover for a Google Cloud Platform internal TCP/UDP load balancer. Before following this guide, familiarize yourself with the following:

Permissions

To follow this guide, you need to create instances and modify a network in a project. You should be either a project owner or editor, or you should have all of the following Compute Engine IAM roles:

Task Required Role
Create networks, subnets, and load balancer components Network Admin
Add and remove firewall rules Security Admin
Create instances Instance Admin

Setup

This guide shows you how to configure and test an internal TCP/UDP load balancer that uses failover. The steps in this section describe how to configure the following:

  1. A sample VPC network with custom subnets
  2. Firewall rules that allow incoming connections to backend VMs
  3. Backend VMs:
    • One primary backend in an unmanaged instance group in zone us-west1-a
    • One failover backend in an unmanaged instance group in zone us-west1-c
  4. One client VM to test connections and observe failover behavior
  5. The following internal TCP/UDP load balancer components:
    • A health check for the backend service
    • An internal backend service in the us-west1 region to manage connection distribution among the backend VMs
    • An internal forwarding rule and internal IP address for the frontend of the load balancer

The architecture for this example looks like this:

Simple Failover Example for Internal TCP/UDP Load Balancing (click to enlarge)
Simple Failover Example for Internal TCP/UDP Load Balancing (click to enlarge)

Configuring a network, region, and subnet

This example uses the following VPC network, region, and subnet:

  • Network: The network is a custom mode VPC network named lb-network.

  • Region: The region is us-west1.

  • Subnet: The subnet, lb-subnet, uses the 10.1.2.0/24 IP range.

To create the example network and subnet, follow these steps.

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 lb-network.
  4. In the Subnets section:
    • Set the Subnet creation mode to Custom.
    • In the New subnet section, enter the following information:
      • Name: lb-subnet
      • Region: us-west1
      • IP address range: 10.1.2.0/24
      • Click Done.
  5. Click Create.

gcloud

  1. Create the custom VPC network:

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. Create a subnet in the lb-network network in the us-west1 region:

    gcloud compute networks subnets create lb-subnet \
        --network=lb-network \
        --range=10.1.2.0/24 \
        --region=us-west1
    

Configuring firewall rules

This example uses the following firewall rules:

  • fw-allow-lb-subnet: An ingress rule, applicable to all targets in the VPC network, allowing traffic from sources in the 10.1.2.0/24 range. This rules allows incoming traffic from any source within the lb-subnet to the instances (VMs) being load balanced.

  • fw-allow-ssh: An ingress rule applied to the instances being load balanced, allowing incoming SSH connectivity on TCP port 22 from any address. You can choose a more restrictive source IP range for this rule; for example, you can specify the IP ranges of the systems from which you plan to initiate SSH sessions. This example uses the target tag allow-ssh to identify the VMs to which the firewall rule applies.

  • fw-allow-health-check: An ingress rule, applicable to the instances being load balanced, that allows traffic from the GCP health checking systems (130.211.0.0/22 and 35.191.0.0/16). This example uses the target tag allow-health-check to identify the instances to which it should apply.

Without these firewall rules, the default deny ingress rule blocks incoming traffic to the backend instances.

Console

  1. Go to the Firewall rules page in the Google Cloud Platform Console.
    Go to the Firewall rules page
  2. Click Create firewall rule and enter the following information to create the rule to allow subnet traffic:
    • Name: fw-allow-lb-subnet
    • Network: lb-network
    • Priority: 1000
    • Direction of traffic: ingress
    • Action on match: allow
    • Targets: All instances in the network
    • Source filter: IP ranges
    • Source IP ranges: 10.1.2.0/24
    • Protocols and ports: Allow all
  3. Click Create.
  4. Click Create firewall rule again to create the rule to allow incoming SSH connections:
    • Name: fw-allow-ssh
    • Network: lb-network
    • Priority: 1000
    • Direction of traffic: ingress
    • Action on match: allow
    • Targets: Specified target tags
    • Target tags: allow-ssh
    • Source filter: IP ranges
    • Source IP ranges: 0.0.0.0/0
    • Protocols and ports: Choose Specified protocols and ports then type: tcp:22
  5. Click Create.
  6. Click Create firewall rule a third time to create the rule to allow GCP health checks:
    • Name: fw-allow-health-check
    • Network: lb-network
    • Priority: 1000
    • Direction of traffic: ingress
    • Action on match: allow
    • Targets: Specified target tags
    • Target tags: allow-health-check
    • Source filter: IP ranges
    • Source IP ranges: 130.211.0.0/22 and 35.191.0.0/16
    • Protocols and ports: Allow all
  7. Click Create.

gcloud

  1. Create the fw-allow-lb-subnet firewall rule to allow communication from with the subnet:

    gcloud compute firewall-rules create fw-allow-lb-subnet \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.1.2.0/24 \
        --rules=tcp,udp,icmp
    
  2. Create the fw-allow-ssh firewall rule to allow SSH connectivity to VMs with the network tag allow-ssh. When you omit source-ranges, GCP interprets the rule to mean any source.

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  3. Create the fw-allow-health-check rule to allow GCP health checks.

    gcloud compute firewall-rules create fw-allow-health-check \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-health-check \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --rules=tcp,udp,icmp
    

Creating backend VMs and instance groups

In this step, you'll create the backend VMs and unmanaged instance groups:

  • The instance group ig-a in us-west1-a is a primary backend with two VMs:
    • vm-a1
    • vm-a2
  • The instance group ig-c in us-west1-c is a failover backend with two VMs:
    • vm-c1
    • vm-c2

The primary and failover backends are placed in separate zones for instructional clarity and to handle failover in case one zone goes down.

Each primary and backup VM is configured to run an Apache web server on TCP ports 80 and 443. Each VM is assigned an internal IP address in the lb-subnet for client access and an ephemeral external (public) IP address for SSH access. For information about removing external IP addresses, see removing external IP addresses from backend VMs.

By default, Apache is configured to bind to any IP address. Internal TCP/UDP load balancers deliver packets by preserving the destination IP.

Ensure that server software running on your primary and backup VMs is listening on the IP address of the load balancer's internal forwarding rule. If you configure multiple internal forwarding rules, ensure that your software listens to the internal IP address associated with each one. The destination IP address of a packet delivered to a backend VM by an internal TCP/UDP load balancer is the internal IP address of the forwarding rule.

For instructional simplicity, all primary and backup VMs run Debian GNU/Linux 9.

Console

Create backend VMs

  1. Go to the VM instances page in the Google Cloud Platform Console.
    Go to the VM instances page
  2. Repeat the following steps to create four VMs, using the following name and zone combinations.
    • Name: vm-a1, zone: us-west1-a
    • Name: vm-a2, zone: us-west1-a
    • Name: vm-c1, zone: us-west1-c
    • Name: vm-c2, zone: us-west1-c
  3. Click Create instance.
  4. Set the Name as indicated in step 2.
  5. For the Region, choose us-west1, and choose a Zone as indicated in step 2.
  6. In the Boot disk section, ensure that the selected image is Debian GNU/Linux 9 Stretch. Click Choose to change the image if necessary.
  7. Click Management, security, disks, networking, sole tenancy and make the following changes:

    • Click Networking and add the following Network tags: allow-ssh and allow-health-check
    • Click the edit button under Network interfaces and make the following changes then click Done:
      • Network: lb-network
      • Subnet: lb-subnet
      • Primary internal IP: Ephemeral (automatic)
      • External IP: Ephemeral
    • Click Management. In the Startup script field, copy and paste the following script contents. The script contents are identical for all four VMs:

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      
  8. Click Create.

Create instance groups

  1. Go to the Instance groups page in the Google Cloud Platform Console.
    Go to the Instance groups page
  2. Repeat the following steps to create two unmanaged instance groups each with two VMs in them, using these combinations.
    • Instance group: ig-a, zone: us-west1-a, VMs: vm-a1 and vm-a2
    • Instance group: ig-c, zone: us-west1-c, VMs: vm-c1 and vm-c2
  3. Click Create instance group.
  4. Set Name as indicated in step 2.
  5. In the Location section, select Single-zone, choose us-west1 for the Region, and then choose a Zone as indicated in step 2.
  6. In the Group type section, select Unmanaged instance group.
  7. For Network, enter lb-network.
  8. For Subnetwork, enter lb-subnet.
  9. In the VM instances section, add the VMs as indicated in step 2.
  10. Click Create.

gcloud

  1. Create four VMs by running the following command four times, using these four combinations for [VM-NAME] and [ZONE]. The script contents are identical for all four VMs.

    • [VM-NAME] of vm-a1 and [ZONE] of us-west1-a
    • [VM-NAME] of vm-a2 and [ZONE] of us-west1-a
    • [VM-NAME] of vm-c1 and [ZONE] of us-west1-c
    • [VM-NAME] of vm-c2 and [ZONE] of us-west1-c
    gcloud compute instances create [VM-NAME] \
        --zone=[ZONE] \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh,allow-health-check \
        --subnet=lb-subnet \
        --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'
    
  2. Create the two unmanaged instance groups in each zone:

    gcloud compute instance-groups unmanaged create ig-a \
        --zone=us-west1-a
    gcloud compute instance-groups unmanaged create ig-c \
        --zone=us-west1-c
    
  3. Add the VMs to the appropriate instance groups:

    gcloud compute instance-groups unmanaged add-instances ig-a \
        --zone=us-west1-a \
        --instances=vm-a1,vm-a2
    gcloud compute instance-groups unmanaged add-instances ig-c \
        --zone=us-west1-c \
        --instances=vm-c1,vm-c2
    

Creating a client VM

This example creates a client VM (vm-client) in the same region as the load balancer. The client is used to demonstrate how failover works.

Console

  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 the Name to vm-client.
  4. Set the Zone to us-west1-a.
  5. Click Management, security, disks, networking, sole tenancy and make the following changes:
    • Click Networking and add the allow-ssh to Network tags.
    • Click the edit button under Network interfaces and make the following changes then click Done:
      • Network: lb-network
      • Subnet: lb-subnet
      • Primary internal IP: Ephemeral (automatic)
      • External IP: Ephemeral
  6. Click Create.

gcloud

The client VM can be in any zone in the same region as the load balancer, and it can use any subnet in that region. In this example, the client is in the us-west1-a zone, and it uses the same subnet used by the primary and backup VMs.

gcloud compute instances create vm-client \
    --zone=us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=lb-subnet

Configuring load balancer components

These steps configure all of the internal TCP/UDP load balancer components starting with the health check and backend service, and then the frontend components:

  • Health check: This example uses an HTTP health check that simply checks for an HTTP 200 (OK) response. For more information, see the health checks section of the Internal TCP/UDP Load Balancing overview.

  • Backend service: Because the example passes HTTP traffic through the internal load balancer, the configuration specifies TCP, not UDP. To illustrate failover, this backend service has a failover ratio of 0.75.

  • Forwarding rule: This example creates a single internal forwarding rule.

  • Internal IP address: In this example, we specify an internal IP address, 10.1.2.99, when we create the forwarding rule.

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 be-ilb.
  7. Click Backend configuration and make the following changes:
    1. Region: us-west1
    2. Network: lb-network
    3. Under Backends, in the New item section, select the ig-a instance group. Ensure that Use this instance group as a failover group for backup is not checked. Click Done.
    4. Click Add backend. In the New item section that appears, select the ig-c instance group. Check Use this instance group as a failover group for backup. Click Done.
    5. Under Health check, choose Create another health check, enter the following information, and click Save and continue:
      • Name: hc-http-80
      • Protocol: HTTP
      • Port: 80
      • Proxy protocol: NONE
      • Request path: /
    6. Click Advanced configurations. In the Failover policy section, configure the following:
      • Failover ratio: 0.75
      • Check Enable connection draining on failover.
    7. Verify that there is a blue check mark next to Backend configuration before continuing. Review this step if not.
  8. Click Frontend configuration. In the New Frontend IP and port section, make the following changes:
    1. Name: fr-ilb
    2. Subnetwork: ilb-subnet
    3. From Internal IP, choose Reserve a static internal IP address, enter the following information, and click Reserve:
      • Name: ip-ilb
      • Static IP address: Let me choose
      • Custom IP address: 10.1.2.99
    4. Ports: Choose Single, and enter 80 for the Port number.
    5. Verify that there is a blue check mark next to Frontend configuration before continuing. Review this step if not.
  9. Click Review and finalize. Double-check your settings.
  10. Click Create.

gcloud

  1. Create a new HTTP health check to test TCP connectivity to the VMs on 80.

    gcloud compute health-checks create http hc-http-80 \
        --port=80
    
  2. Create the backend service for HTTP traffic:

    gcloud beta compute backend-services create be-ilb \
        --load-balancing-scheme=internal \
        --protocol=tcp \
        --region=us-west1 \
        --health-checks=hc-http-80 \
        --failover-ratio 0.75
    
  3. Add the primary backend to the backend service:

    gcloud compute backend-services add-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-a \
        --instance-group-zone=us-west1-a
    
  4. Add the failover backend to the backend service:

    gcloud beta compute backend-services add-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-c \
        --instance-group-zone=us-west1-c \
        --failover
    
  5. Create a forwarding rule for the backend service. When you create the forwarding rule, specify 10.1.2.99 for the internal IP in the subnet.

    gcloud compute forwarding-rules create fr-ilb \
        --region=us-west1 \
        --load-balancing-scheme=internal \
        --network=lb-network \
        --subnet=lb-subnet \
        --address=10.1.2.99 \
        --ip-protocol=TCP \
        --ports=80 \
        --backend-service=be-ilb \
        --backend-service-region=us-west1
    

Testing

These tests show how to validate your load balancer configuration and learn about its expected behavior.

Client test procedure

This procedure contacts the load balancer from the client VM. You'll use this procedure to complete the other tests.

  1. Connect to the client VM instance.

    gcloud compute ssh vm-client --zone=us-west1-a
    
  2. Make a web request to the load balancer using curl to contact its IP address.

    curl http://10.1.2.99
    
  3. Note the text returned by the curl command. The name of the backend VM generating the response is displayed in that text; for example: Page served from: vm-a1

Testing initial state

After you've configured the example load balancer, all four of the backend VMs should be healthy:

  • the two primary VMs, vm-a1 and vm-a2
  • the two backup VMs, vm-c1 and vm-c2

Follow the client test procedure. Repeat the second step a few times. The expected behavior is for traffic to be served by the two primary VMs, vm-a1 and vm-a2, because both of them are healthy. You should see each primary VM serve a response approximately half of the time because no session affinity has been configured for this load balancer.

Testing failover

This test simulates the failure of vm-a1 so you can observe failover behavior.

  1. Connect to the vm-a1 VM.

    gcloud compute ssh vm-a1 --zone=us-west1-a
    
  2. Stop the Apache web server. After ten seconds, GCP considers this VM to be unhealthy. (The hc-http-80 health check that you created in the setup uses the default check interval of five seconds and unhealthy threshold of two consecutive failed probes.)

    sudo apachectl stop
    
  3. Follow the client test procedure. Repeat the second step a few times. The expected behavior is for traffic to be served by the two backup VMs, vm-c1 and vm-c2. Because only one primary VM, vm-a2, is healthy, the ratio of healthy primary VMs to total primary VMs is 0.5. This number is less than the failover threshold of 0.75, so GCP reconfigured the load balancer's active pool to use the backup VMs. You should see each backup VM serve a response approximately half of the time as long as no session affinity has been configured for this load balancer.

Testing failback

This test simulates failback by restarting the Apache server on vm-a1.

  1. Connect to the vm-a1 VM.

    gcloud compute ssh vm-a1 --zone=us-west1-a
    
  2. Start the Apache web server and wait 10 seconds.

    sudo apachectl start
    
  3. Follow the client test procedure. Repeat the second step a few times. The expected behavior is for traffic to be served by the two primary VMs, vm-a1 and vm-a2. With both primary VMs being healthy, the ratio of healthy primary VMs to total primary VMs is 1.0, greater than the failover threshold of 0.75, so GCP configured the active pool to use the primary VMs again.

Adding more backend VMs

This section extends the example configuration by adding more primary and backup VMs to the load balancer. It does so by creating two more backend instance groups to demonstrate that you can distribute primary and backup VMs among multiple zones in the same region:

  • A third instance group, ig-d in us-west1-c, serves as a primary backend with two VMs:
    • vm-d1
    • vm-d2
  • A fourth instance group, ig-b in us-west1-a, serves as a failover backend with two VMs:
    • vm-b1
    • vm-b2

The modified architecture for this example looks like this:

Multi-zone Internal TCP/UDP Load Balancing failover (click to enlarge)
Multi-zone Internal TCP/UDP Load Balancing failover (click to enlarge)

Create additional VMs and instance groups

Follow these steps to create the additional primary and backup VMs and their corresponding unmanaged instance groups.

Console

Create backend VMs

  1. Go to the VM instances page in the Google Cloud Platform Console.
    Go to the VM instances page
  2. Repeat the following steps to create four VMs, using the following name and zone combinations.
    • Name: vm-b1, zone: us-west1-a
    • Name: vm-b2, zone: us-west1-a
    • Name: vm-d1, zone: us-west1-c
    • Name: vm-d2, zone: us-west1-c
  3. Click Create instance.
  4. Set the Name as indicated in step 2.
  5. For the Region, choose us-west1, and choose a Zone as indicated in step 2.
  6. In the Boot disk section, ensure that the selected image is Debian GNU/Linux 9 Stretch. Click Choose to change the image if necessary.
  7. Click Management, security, disks, networking, sole tenancy and make the following changes:

    • Click Networking and add the following Network tags: allow-ssh and allow-health-check
    • Click the edit button under Network interfaces and make the following changes then click Done:
      • Network: lb-network
      • Subnet: lb-subnet
      • Primary internal IP: Ephemeral (automatic)
      • External IP: Ephemeral
    • Click Management. In the Startup script field, copy and paste the following script contents. The script contents are identical for all four VMs:

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      
  8. Click Create.

Create instance groups

  1. Go to the Instance groups page in the Google Cloud Platform Console.
    Go to the Instance groups page
  2. Repeat the following steps to create two unmanaged instance groups each with two VMs in their one, using these combinations.
    • Instance group: ig-b, zone: us-west1-a, VMs: vm-b1 and vm-b2
    • Instance group: ig-d, zone: us-west1-c, VMs: vm-d1 and vm-d2
  3. Click Create instance group.
  4. Set Name as indicated in step 2.
  5. In the Location section, select Single-zone, choose us-west1 for the Region, and then choose a Zone as indicated in step 2.
  6. In the Group type section, select Unmanaged instance group.
  7. For Network, enter lb-network.
  8. For Subnetwork, enter lb-subnet.
  9. In the VM instances section, add the VMs as indicated in step 2.
  10. Click Create.

gcloud

  1. Create four VMs by running the following command four times, using these four combinations for [VM-NAME] and [ZONE]. The script contents are identical for all four VMs.

    • [VM-NAME] of vm-b1 and [ZONE] of us-west1-a
    • [VM-NAME] of vm-b2 and [ZONE] of us-west1-a
    • [VM-NAME] of vm-d1 and [ZONE] of us-west1-c
    • [VM-NAME] of vm-d2 and [ZONE] of us-west1-c
    gcloud compute instances create [VM-NAME] \
        --zone=[ZONE] \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh,allow-health-check \
        --subnet=lb-subnet \
        --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'
    
  2. Create the two unmanaged instance groups in each zone:

    gcloud compute instance-groups unmanaged create ig-b \
        --zone=us-west1-a
    gcloud compute instance-groups unmanaged create ig-d \
        --zone=us-west1-c
    
  3. Add the VMs to the appropriate instance groups:

    gcloud compute instance-groups unmanaged add-instances ig-b \
        --zone=us-west1-a \
        --instances=vm-b1,vm-b2
    gcloud compute instance-groups unmanaged add-instances ig-d \
        --zone=us-west1-c \
        --instances=vm-d1,vm-d2
    

Adding a primary backend

You can use this procedure as a template for how to add an unmanaged instance group to an existing internal TCP/UDP load balancer's backend service as a primary backend. For the example configuration, this procedure shows you how to add instance group ig-d as a primary backend to the be-ilb load balancer.

Console

  1. Go to the Load balancing page in the Google Cloud Platform Console.
    Go to the Load balancing page
  2. In the Load balancers tab, click the name of an existing internal TCP or internal UDP load balancer (in this example, be-ilb).
  3. Click Edit.
  4. In the Backend configuration, click Add backend and select an unmanaged instance group (in this example, ig-d).
  5. Ensure that Use this instance group as a failover group for backup is not checked.
  6. Click Done and then click Update.

gcloud

Use the following gcloud command to add a primary backend to an existing internal TCP/UDP load balancer's backend service.

gcloud beta compute backend-services add-backend [BACKEND_SERVICE_NAME] \
   --instance-group [INSTANCE_GROUP_NAME] \
   --instance-group-zone [INSTANCE_GROUP_ZONE] \
   --region [REGION]

where:

  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service. For the example, use be-ilb.
  • [INSTANCE_GROUP_NAME] is the name of the instance group to add as a primary backend. For the example, use ig-d.
  • [INSTANCE_GROUP_ZONE] is the zone where the instance group is defined. For the example, use us-west1-c.
    • [REGION] is the region of the load balancer. For the example, use us-west1.

api

Add a primary backend to an existing backend service with the regionBackendServices.patch method

POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "backends":
  [
    {
      "balancingMode": "connection",
      "failover": false,
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[INSTANCE_GROUP_ZONE]/instanceGroups/[INSTANCE_GROUP_NAME]"
    }
  ]
}

where:

  • [PROJECT_ID] is your project ID.
  • [REGION] is the region of the load balancer. For the example, use us-west1.
  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service. For the example, use be-ilb.
  • [INSTANCE_GROUP_ZONE] is the zone where the instance group is defined. For the example, use us-west1-c.
  • [INSTANCE_GROUP_NAME] is the name of the instance group to add as a primary backend. For the example, use ig-d.

Adding a failover backend

You can use this procedure as a template for how to add an unmanaged instance group to an existing internal TCP/UDP load balancer's backend service as a failover backend. For the example configuration, this procedure shows you how to add instance group ig-b as a failover backend to the be-ilb load balancer.

Console

  1. Go to the Load balancing page in the Google Cloud Platform Console.
    Go to the Load balancing page
  2. In the Load balancers tab, click the name of an existing internal TCP or internal UDP load balancer (in this example, be-ilb).
  3. Click Edit.
  4. In the Backend configuration, click Add backend and select an unmanaged instance group (in this example, ig-b).
  5. Check Use this instance group as a failover group for backup.
  6. Click Done and then click Update.

gcloud

Use the following gcloud command to add a failover backend to an existing internal TCP/UDP load balancer's backend service.

gcloud beta compute backend-services add-backend [BACKEND_SERVICE_NAME] \
   --instance-group [INSTANCE_GROUP_NAME] \
   --instance-group-zone [INSTANCE_GROUP_ZONE] \
   --region [REGION] \
   --failover

where:

  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service. For the example, use be-ilb.
  • [INSTANCE_GROUP_NAME] is the name of the instance group to add as a failover backend. For the example, use ig-b.
  • [INSTANCE_GROUP_ZONE] is the zone where the instance group is defined. For the example, use us-west1-a.
  • [REGION] is the region of the load balancer. For the example, use us-west1.

api

Add a failover backend to an existing backend service with the regionBackendServices.patch method

POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "backends":
  [
    {
      "balancingMode": "connection",
      "failover": true,
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[INSTANCE_GROUP_ZONE]/instanceGroups/[INSTANCE_GROUP_NAME]"
    }
  ]
}

where:

  • [PROJECT_ID] is your project ID.
  • [REGION] is the region of the load balancer. For the example, use us-west1.
  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service. For the example, use be-ilb.
  • [INSTANCE_GROUP_ZONE] is the zone where the instance group is defined. For the example, use us-west1-a.
  • [INSTANCE_GROUP_NAME] is the name of the instance group to add as a failover backend. For the example, use ig-b.

Converting a primary or failover backend

You can use convert a primary backend to a failover backend, or vice versa, without having to remove the instance group from the internal TCP/UDP load balancer's backend service.

Console

  1. Go to the Load balancing page in the Google Cloud Platform Console.
    Go to the Load balancing page
  2. In the Load balancers tab, click the name of an existing internal TCP or internal UDP load balancer.
  3. Click Edit.
  4. In the Backend configuration, click the name of one of the backend instance groups. Then:
    • To make the instance group a failover backend, check Use this instance group as a failover group for backup.
    • To make the instance group a primary backend, un-check Use this instance group as a failover group for backup.
  5. Click Done and then click Update.

gcloud

Use the following gcloud command to convert an existing primary backend to a failover backend:

gcloud beta compute backend-services update-backend [BACKEND_SERVICE_NAME] \
   --instance-group [INSTANCE_GROUP_NAME] \
   --instance-group-zone [INSTANCE_GROUP_ZONE] \
   --region [REGION] \
   --failover

Use the following gcloud command to convert an existing failover backend to a primary backend:

gcloud beta compute backend-services update-backend [BACKEND_SERVICE_NAME] \
   --instance-group [INSTANCE_GROUP_NAME] \
   --instance-group-zone [INSTANCE_GROUP_ZONE] \
   --region [REGION] \
   --no-failover

where:

  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service.
  • [INSTANCE_GROUP_NAME] is the name of the instance group.
  • [INSTANCE_GROUP_ZONE] is the zone where the instance group is defined.
  • [REGION] is the region of the load balancer.

api

Convert a primary backend to a failover backend, or vice versa, by using the regionBackendServices.patch method

To convert a primary backend to a failover backend:

POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "backends":
  [
    {
      "failover": true,
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[INSTANCE_GROUP_ZONE]/instanceGroups/[INSTANCE_GROUP_NAME]"
    }
  ]
}

To convert a failover backend to a primary backend:

POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "backends":
  [
    {
      "failover": false,
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[INSTANCE_GROUP_ZONE]/instanceGroups/[INSTANCE_GROUP_NAME]"
    }
  ],
}

where:

  • [PROJECT_ID] is your project ID.
  • [REGION] is the region of the load balancer.
  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service.
  • [INSTANCE_GROUP_ZONE] is the zone where the instance group is defined.
  • [INSTANCE_GROUP_NAME] is the name of the instance group.

Configuring failover policies

This section describes how to manage a failover policy for an internal TCP/UDP load balancer's backend service. A failover policy consists of the:

  • Failover ratio
  • Dropping traffic when all backend VMs are unhealthy
  • Connection draining on failover

For more information on the parameters of a failover policy, see:

Defining a failover policy

The following instructions describe how to define the failover policy for an existing internal TCP/UDP load balancer.

Console

To define a failover policy using the GCP Console you must have at least one failover backend.

  1. Go to the Load balancing page in the Google Cloud Platform Console.
    Go to the Load balancing page
  2. From the Load balancers tab, select a TCP (internal) or UDP (internal) load balancer.
  3. Click Edit.
  4. Make sure you have at least one failover backend. At least one of the load balancer's backends must have the Use this instance group as a failover group for backup selected.
  5. Click Advanced configurations.
    • Under Failover Policy, set the Failover ratio to a value between 0.0 and 1.0, inclusive.
    • Check the box next to Enable drop traffic if you want to drop traffic when all active VMs and all backup VMs are unhealthy.
    • Check the box next to Enable connection draining on failover if you want to terminate existing connections quickly during failover.
  6. Click Review and finalize and then click Update.

gcloud

To define a failover policy using the gcloud command line tool, update the load balancer's backend service:

gcloud beta compute backend-services update [BACKEND_SERVICE_NAME] \
   --region [REGION] \
   --failover-ratio [FAILOVER_RATIO] \
   --drop-traffic-if-unhealthy \
   --no-connection-drain-on-failover

where:

  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service. For the example, use be-ilb.
  • [REGION] is the region of the load balancer. For the example, use us-west1.
  • [FAILOVER_RATIO] is the failover ratio. Possible values are between 0.0 and 1.0, inclusive. For the example, use 0.75.
  • --drop-traffic-if-unhealthy instructs the load balancer to drop traffic when all primary VMs and all backup VMs are unhealthy. Change this to --no-drop-traffic-if-unhealthy if you want to distribute traffic among all primary VMs when all backend VMs are unhealthy.
  • --no-connection-drain-on-failover instructs the load balancer to terminate existing TCP connections quickly during failover. Use --connection-drain-on-failover to enable connection draining during failover.

api

Use the regionBackendServices.patch method to define the failover policy.

PATCH https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "failoverPolicy":
  {
    "failoverRatio": [FAILOVER_RATIO],
    "dropTrafficIfUnhealthy": [true|false],
    "disableConnectionDrainOnFailover": [true|false]
  }
}

where:

  • [PROJECT_ID] is your project ID.
  • [REGION] is the region of the load balancer.
  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service.
  • [FAILOVER_RATIO] is the failover ratio. Possible values are between 0.0 and 1.0, inclusive.
  • Setting dropTrafficIfUnhealthy to true instructs the load balancer to drop traffic when all primary VMs and all backup VMs are unhealthy. Set this to false if you want to distribute traffic among all primary VMs when all backend VMs are unhealthy.
  • Setting disableConnectionDrainOnFailover to true instructs the load balancer to terminate existing TCP connections quickly when doing a failover. Set this to false to enable connection draining during failover.

Viewing a failover policy

The following instructions describe how to view the existing failover policy for an internal TCP/UDP load balancer.

Console

The GCP Console shows the existing failover policy settings when you edit an internal TCP/UDP load balancer. Refer to defining a failover policy for instructions.

gcloud

To list the failover policy settings using the gcloud command line tool, use the following command. Undefined settings in a failover policy use the default failover policy values.

gcloud beta compute backend-services describe [BACKEND_SERVICE_NAME] \
   --region [REGION] \
   --format="get(failoverPolicy)"

where:

  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service. For the example, use be-ilb.
  • [REGION] is the region of the load balancer. For the example, use us-west1.

api

Use the regionBackendServices.get method to view the failover policy.

The response to the API request shows the failover policy. An example is shown below.

GET https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

where:

  • [PROJECT_ID] is your project ID.
  • [REGION] is the region of the load balancer.
  • [BACKEND_SERVICE_NAME] is the name of the load balancer's backend service.
{
...
"failoverPolicy": {
"disableConnectionDrainOnFailover": false,
"dropTrafficIfUnhealthy": false,
"failoverRatio": 0.75
...
}

What's next

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…