Proxy-only subnets for internal HTTP(S) load balancers

This page describes how to work with proxy-only subnets for Internal HTTP(S) Load Balancing. For a general overview of Internal HTTP(S) Load Balancing, see Internal HTTP(S) Load Balancing Concepts.

The internal HTTP(S) load balancer provides a pool of proxies for your network. The proxies evaluate where each HTTP(S) request should go based on the URL map, the backend service's session affinity, the balancing mode of each backend instance group or NEG, and other factors.

  1. A client makes a connection to the IP address and port of the load balancer's forwarding rule.

  2. One of the proxies receives and terminates the client's network connection.

  3. The proxy establishes a connection to the appropriate backend VM or endpoint in a NEG, as determined by the load balancer's URL map and backend services.

Each of the load balancer's proxies is assigned an internal IP address. The proxies for all internal HTTP(S) load balancers in a region use internal IP addresses from a single, proxy-only subnet in that region, in your VPC network. This subnet is reserved exclusively for Internal HTTP(S) Load Balancing proxies and cannot be used for other purposes. A proxy-only subnet must provide 64 or more IP addresses. This corresponds to a prefix length of /26 or shorter. Only one proxy-only subnet per region, per VPC network can be active.

Only the proxies created by GCP for a region's internal HTTP(S) load balancers use the proxy-only subnet. The IP address for the load balancer's forwarding rule doesn't come from the proxy-only subnet. Also, the IP addresses of the backend VMs and endpoints don't come from the proxy-only subnet.

Each proxy listens on the IP address and port specified by the corresponding load balancer's forwarding rule. Each packet sent from a proxy to a backend VM or endpoint has a source IP address from the proxy-only subnet.

The following diagram provides a high-level view of the traffic flow.

Internal services with Layer 7-based load balancing (click to enlarge)
Internal services with Layer 7-based load balancing (click to enlarge)

How proxy-only subnets fit into the load balancer's architecture

The following diagram shows the GCP resources required for an HTTP(S) internal load balancer.

Internal HTTP(S) Load Balancing components (click to enlarge)
Internal HTTP(S) Load Balancing components (click to enlarge)

As shown in the diagram, an internal HTTP(S) load balancer deployment requires at least two subnets:

  • The load balancer's internal managed forwarding rule and the IP addresses of backend VMs and backend endpoints use a single subnet whose primary IP address range is 10.1.2.0/24. This subnet isn't the proxy-only subnet. You can use multiple subnets for your backend VMs and endpoints, if the subnets are in the same region as the load balancer.

  • The proxy-only subnet is 10.129.0.0/26.

Creating a proxy-only subnet

Reserving a subnet for an HTTP(S) load balancer is essentially the same procedure as creating any subnet, except with the addition of some flags.

You must create a proxy-only subnet for use by the load balancers' proxies, before creating forwarding rules for your internal HTTP(S) load balancers. If you try to configure an internal HTTP(S) load balancer without first creating a proxy-only subnet for the region, the load balancer creation process fails.

You must create one proxy-only subnet in each region of a virtual network (VPC) in which you use internal HTTP(S) load balancers. This subnet is shared by all of your internal HTTP(S) load balancers in the region.

You must create proxy-only subnets regardless of whether your network is auto-mode or custom. The recommended subnet size is /24 (256 proxy-only addresses). It must be at least /26 (64 proxy-only addresses).

The gcloud compute networks subnets create command creates a proxy-only a subnet.

gcloud beta compute networks subnets create SUBNET_NAME \
    --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

Where:

  • SUBNET_NAME is the name of the proxy-only subnet
  • REGION is the region of the proxy-only subnet
  • VPC_NETWORK_NAME is the name of the VPC network that contains the subnet
  • CIDR_RANGE is the primary IP range of the subnet. You must use a subnet mask no longer than 26 so that at least 64 IP addresses are available for proxies in the region.

For a complete configuration example, refer to Creating the proxy-only subnet.

If you're using the GCP Console, you can create the proxy-only subnet in the Load Balancing UI, as described the following sections:

You must configure a firewall rule for your backends to accept connections from the proxy-only subnet. See the l7-ilb-firewall configuration in Configuring firewall rules.

Changing the size or address range of a proxy-only subnet

Because only one proxy-only subnet can be active per region and per VPC network, and because you can only expand a subnet's primary IP range, you must use the following procedure to modify the proxy-only subnet:

  1. Create a backup proxy-only subnet in the same region, specifying a primary IP range that meets your needs, using the gcloud compute networks subnets create command.

    gcloud beta compute networks subnets create subnet-name \
       --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
       --role=BACKUP \
       --region=region \
       --network=vpc-network-name \
       --range=cidr-range
    
  2. Create or modify ingress allow firewall rules that apply to your backend VMs or endpoints so they include the primary IP range of the backup proxy-only subnet.

  3. The following gcloud command promotes a backup proxy-only subnet to the active role and demotes the previously active proxy-only subnet to the backup role:

    gcloud beta compute networks subnets update backup-proxy-subnet \
       --role=ACTIVE \
       --drainTimeoutSeconds=connection-draining-timeout<\var>
    

    Replace the placeholders with valid values:

    • <var>backup-proxy-subnet</var> is the name of the newly-created proxy-only subnet.
    • <var>connection-draining-timeout<\var> is the amount of time, in seconds, that GCP uses to migrate existing connections away from proxies in the previously-active proxy-only subnet.

    Switching a proxy-only subnet from backup to active does not interrupt new connections:

    • The newly activated proxy-only subnet is used for new connections.
    • The previously active (now backup) proxy-only subnet is no longer used for new connections.
    • GCP begins draining existing connections from proxies in the previously active (now backup) proxy-only subnet.
  4. After the connection draining timeout, or after you're confident that connections to your backend VMs or endpoints aren't coming from proxies in the previously active (now backup) proxy-only subnet, you can do the following:

    • Modify ingress allow firewall rules that apply to your backend VMs or endpoints so they don't include the primary IP range of the previously active (now backup) proxy-only subnet.
    • Delete the previously active (now backup) proxy-only subnet to release the IP addresses that subnet used for its primary IP address range.

Requirements and limitations

The following constraints apply to proxy-only subnets:

  • You can create only one active and one backup proxy-only subnet in each region in each VPC network.

  • You cannot create a backup proxy-only subnet unless you have already created an active proxy-only subnet in that region and network.

  • You can change the role of a proxy-only subnet from backup to active by updating the subnet. When you do that, GCP automatically changes the previously active proxy-only subnet to backup. You cannot explicitly set the role of a proxy-only subnet to backup by updating it.

  • During a proxy-only subnet's connection draining period (drainTimeoutSeconds), you cannot change the role of a proxy-only subnet from backup to active.

  • Before you can create your first internal HTTP(S) load balancer in a given region and VPC network, you must already have an active proxy-only subnet in that region and network.

  • GCP doesn't warn you if your proxy-only subnet runs out of IP addresses.

Example

  1. Create a backup proxy-only subnet dedicated to the region.

    gcloud beta compute networks subnets create new-l7ibackend-subnet-us-west1 \
       --purpose INTERNAL_HTTPS_LOAD_BALANCER \
       --role BACKUP \
       --region us-west1 \
       --network default \
       --addresses 10.130.0.0/26
    
  2. Update your backend firewall to accept connections from the new subnet.

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.129.0.0/26,10.130.0.0/26
    
  3. Update the new subnet, setting it to be the ACTIVE proxy-only subnet in the region and waiting for the old subnet to drain.

    gcloud beta compute networks subnets update new-l7ilb-ip-range-us-west1 \
       --drain-timeout 1h --role ACTIVE
    

    To drain an IP address range immediately, set the --drain-timeout to 0s. This promptly ends all connections to proxies that have assigned addresses in the subnet that is being drained.

  4. Monitor the status of the drain by using a list or describe command. The status of the subnet is DRAINING while it is being drained.

    gcloud beta compute networks subnets list
    

    Wait for draining to complete. When the old proxy-only subnet is drained, the status of the subnet is READY.

  5. Update your backend firewall rule to only allow connections from the new subnet.

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.130.0.0/26
    
  6. Delete the old subnet.

    gcloud beta compute networks subnets delete l7ilb-ip-range-us-west1 \
       --region us-west1
    

Deleting a proxy-only subnet

Deleting a proxy-only subnet releases its primary IP range so you can use the range for another purpose. GCP enforces the following rules when it receives a request to delete a proxy-only subnet:

  • An active proxy-only subnet cannot be deleted if there is at least one internal HTTP(S) load balancer in the same region and VPC network.

  • An active proxy-only subnet cannot be deleted if there exists a backup proxy-only subnet in the same region and VPC network.

Practically, these rules have the following effect:

  • If no internal HTTP(S) load balancer is defined in a given region and VPC network, you can delete the proxy-only subnets in that region. If a backup proxy-only subnet exists, you must first delete it before you can delete the active proxy-only subnet.

  • If you have at least one internal HTTP(S) load balancer defined in a given region and VPC network, you cannot delete the active proxy-only subnet; however, you can promote a backup proxy-only subnet to the active role, which automatically demotes the previously active proxy-only subnet to the backup role. After connections are drained, you can delete the backup (previously active) proxy-only subnet.

Refer to deleting subnets in the VPC network documentation for more information.

What's next

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…