Internal HTTP(S) Load Balancing concepts

Internal HTTP(S) Load Balancing is a proxy-based, regional Layer 7 load balancer that enables you to run and scale your services behind a private load balancing IP address that is accessible only in the load balancer's region in your VPC network.

Overview

Google Cloud Platform (GCP) Internal HTTP(S) Load Balancing is a private, proxy-based HTTP and HTTPS load balancer. It distributes traffic to backend VM instances or endpoints in network endpoint groups (NEGs) in a single region of your VPC network using a URL map. The load balancer is accessible only in the chosen region of your VPC network on a private, internal (RFC 1918) IP address.

For information about how an internal HTTP(S) load balancer compares to other GCP load balancers, refer to Choosing a load balancer.

Traffic types, scheme, and scope

An internal HTTP(S) load balancer is defined by a single URL map, which references one or more backend services with an internal managed load balancing scheme. Each backend service supports one of the following protocols — HTTP, HTTPS, or HTTP/2 — and either backend VMs or endpoints in a network endpoint group (NEG).

Because the scope of an internal HTTP(S) load balancer is regional, not global, clients and backend VMs or endpoints must all be in the same region. Clients in connected networks can use a Cloud VPN tunnel or Cloud Interconnect attachment in the same region as the load balancer.

High-level diagram

Each internal HTTP(S) load balancer has a private IP address that acts as the frontend to its backend VMs or endpoints. Your internal client requests stay internal to your network and region.

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

Use cases

Services

One common use case is load balancing traffic among services. In this example, the user gets video and image content using the same base URL, mygcpservice.internal, with paths /video and /images.

The internal HTTP(S) load balancer's URL map directs traffic to one backend service for video and another backend service for images, based on the URL map's path matcher.

The following diagram shows three services: video, images, and payments.

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

3-tier web services

You can use Internal HTTP(S) Load Balancing to support traditional 3-tier web services.

In the following diagram, three different types of load balancers scale the three tiers:

The diagram shows three types of GCP load balancers.

  1. A global, external HTTP(S) load balancer distributes traffic from the Internet to a set of Web frontend instance groups in various regions.
  2. These frontends send the HTTP(S) traffic to a set of regional, internal HTTP(S) load balancers (the subject of this overview).
  3. The HTTP(S) load balancers distribute the traffic to middleware instance groups.
  4. These middleware instances send the traffic to internal TCP/UDP load balancers, which load balance the traffic to data storage clusters.
Layer 7-based routing for internal tiers in multi-tier app (click to enlarge)
Layer 7-based routing for internal tiers in multi-tier app (click to enlarge)

Architecture and resources

An internal HTTP(S) load balancer's frontend consists of an internal IP address, an internal forwarding rule, and a target HTTP or HTTPS proxy. A single URL map directs traffic to one or more backend services with a load balancing scheme of INTERNAL_MANAGED. Each backend service distributes traffic among its backend instance groups or backend NEGs according to a configurable balancing mode. Within each instance group or NEG, traffic is further distributed according to a configurable policy. Refer to traffic distribution for details about how this works.

Each backend service is regional. All of the backends in a given backend service must either be instance groups or NEGs. Unmanaged instance groups, managed zonal instance groups, and managed regional instance groups are supported.

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)

The following resources define an internal HTTP(S) load balancer:

  • A regional internal forwarding rule, which specifies the internal IP address and port of your load balancer (the address used when clients connect to the load balancer), and the target proxy to which it forwards each incoming request.

  • A regional target HTTP(S) proxy receives a request from the user and forwards it to the URL map. A target HTTPS proxy supports up to a documented number of SSL certificates that allow the proxy to prove its identity to the clients.

  • A regional URL map parses the URL of a request and forwards requests to specific backend services based on the host and path of the request URL.

  • A regional backend service distributes requests to healthy backends (instance groups or NEGs).

  • A regional health check reports the readiness of your backends.

  • One or more backends must be connected to the backend service. Backends can be any of the following types:

    • Managed instance groups (zonal or regional)
    • Unmanaged instance groups (zonal)
    • Network endpoint groups (zonal)

    You cannot use instance groups and NEGs on the same backend service.

  • A proxy-only subnet whose IP addresses are the source of traffic from the load balancer to your backends. You must create one proxy-only subnet in each region of a VPC network 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.

  • A firewall for your backends to accept connections from the proxy-only subnet. Refer to the example in Configuring firewall rules.

Limitations

  • Internal HTTP(S) Load Balancing operates at a regional level. There's no guarantee that a request from a client in one zone of the region is sent to a backend that's in the same zone as the client. Session affinity doesn't reduce communication between zones.

  • Internal HTTP(S) Load Balancing isn't compatible with the following features:

  • Internal HTTP(S) Load Balancing isn't compatible with VPC Network Peering. If you need an internal load balancer that is compatible with VPC Network Peering, use Internal TCP/UDP Load Balancing.

  • The WebSocket protocol is not supported.

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

What's next

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

Enviar comentarios sobre…