Cloud Load Balancers

Cloud offers different types of cloud load balancers that can be divided into two categories: global and regional.

The global load balancers are the HTTP(S), SSL proxy, and TCP proxy load balancers. These load balancers leverage the Cloud Front End (FE) service. FE is a software-defined, distributed system that is available from global points of presence and is distributed globally. The global load balancer manages redundancy, such as routing a request to a nearby region when the desired region is unavailable. Use a global load balancer when your users and instances are globally distributed, you need access to the same workloads and content, and you want to use a single anycast IP address to provide access.

The regional load balancers are the internal TCP/UDP, the network TCP/UDP, the internal HTTP(S), and the external HTTP(s) load balancers. These load balancers distribute traffic to instances that are in a single region.

The internal load TCP/UDP balancer commonly uses a Layer 4 network virtualization stack that is software-defined and made by a cloud provider. The internal HTTP(S) load balancer is a proxy-based Layer 7 load balancer. This load balancer lets you run and scale your services behind a private load balancing IP address. The IP address is accessible only in the region where the load balancer is located.

You choose a load balancer depending on your needs, such as where the clients and workloads are located (from Google architecture center):

Key scenarios that you can accomplish using Load Balancer include:

• Load balance internal and external traffic to virtual machines (VM) or VM sets.
• Increase availability by distributing resources within and across zones. Implementing high availability (HA) solutions
• Configure outbound connectivity for virtual machines.
• Use health probes to monitor load-balanced resources.
• Employ port forwarding to access virtual machines in a virtual network by public IP address and port.
• Enable support for load-balancing of IPv6.
• Load balance services on multiple ports, multiple IP addresses, or both.
• Move internal and external load balancer resources across regions.
• Load balance TCP and UDP flow on all ports simultaneously using HA.

Hybrid load balancing

Hybrid load balancing, which lets you balance traffic between on-premises environments and other public cloud providers.

A hybrid load balancing lets you extend Cloud Load Balancing to workloads that run on your existing infrastructure outside of Cloud. A hybrid strategy is a pragmatic solution for you to adapt to changing market demands and incrementally modernize the backend services that run your workloads.
You can create a hybrid deployment to enable migration to a modern cloud-based solution or a permanent fixture of your organization IT infrastructure. Next, let’s look at a few general examples of hybrid load balancing.

You can use hybrid load balancing with the following:

• Global external (internet-facing) HTTP(S) load balancers and regional external HTTP(S) load balancers. Operates on Level 7. The nodes of an internet-facing load balancer have public IP addresses. The DNS name of an internet-facing load balancer is publicly resolvable to the public IP addresses of the nodes. Therefore, internet-facing load balancers can route requests from clients over the internet
• Internal HTTP(S) load balancers. The nodes of an internal load balancer have only private IP addresses. The DNS name of an internal load balancer is publicly resolvable to the private IP addresses of the nodes. Therefore, internal load balancers can only route requests from clients with access to the VPC for the load balancer
• External TCP/UDP proxy load balancers, External SSL proxy load balancers. Operates on Level 4. That means the connection from internet and the load balancer is terminated, and a new one is created between the load balancer and the backend service.
• Google Cloud provides internal passthrough TCP/UDP load balancing distributes client instance requests to back ends using a different approach, as shown on the right. It uses lightweight load balancing built on top of Andromeda, Google’s network virtualization stack, to provide software-defined load balancing that directly delivers the traffic from the client instance to a back-end instance.

Internal TCP/UDP load balancers are fast.

• An internal TCP/UDP load balancer routes connections directly from clients to the healthy backends without any interruption.
• There’s no intermediate device or single point of failure.
• Client requests to the load balancer IP address go directly to the healthy backend VMs.
• Responses from the healthy backend VMs go directly to the clients, not back through the load balancer

Common use cases of internal pass-through load balancers:

• You need a high-performance, pass-through Layer 4 load balancer for TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, and GRE protocols.
• SSL traffic terminated by your backends instead of by the load balancer. The internal passthrough Network Load Balancer cannot terminate SSL traffic.
• You need to forward the original packets unproxied.
• You have an existing setup that uses a pass-through load balancer, and you want to migrate it without changes.

Traffic management

Traffic management provides enhanced features to route traffic based on criteria that you specify. It commonly leverages the URL map to configure traffic management.

Traffic management provides enhanced features to route load balancer traffic based on criteria that you specify. With traffic management, you can:

• Implement traffic steering based on HTTPS parameters, such as the host, path, headers, and other request parameters.
• Perform request-based and response-based actions, such as redirects and header transformations.
• Use traffic policies to fine-tune load balancing behavior, such as retry policies, request mirroring, and cross-origin resource sharing (CORS).

The URL map contains rules that define the criteria to use to route incoming traffic to a backend service. Traffic management features are configured in a URL map. In other words, the load balancer uses the URL map to determine where to route incoming traffic. Each URL rule in a URL map is composed of a route rule, a rule match, and a rule action. Let’s look at an example, using simple routing.

Internal TCP/UDP load balancers as next hops

Internal TCP/UDP load balancers don’t have the overhead associated with other types of Cloud load balancers; the reduced overhead makes them fast.
An internal TCP/UDP load balancer routes connections directly from clients to the healthy backend without any interruption. There’s no intermediate device or single point of failure. Client requests to the load balancer IP address go directly to the healthy backend VMs. Unlike other types of load balancers, there’s minimal processing of the incoming traffic. Responses from the healthy backend VMs go directly to the clients, not back through the load balancer. TCP responses use direct server return.

• You can load-balance traffic across multiple VMs that are functioning as gateway or router VMs.
• You can use gateway virtual appliances as the next hop for a default route. With this configuration, VM instances in your virtual private cloud (VPC) network send traffic to the internet through a set of load balanced virtual gateway VMs.
• You can send traffic through multiple load balancers in two or more directions by using the same set of multi-NIC gateway or router VMs as backends. To accomplish this result, you create a load balancer and use it as the next hop for a custom static route in each VPC network. Each internal TCP/UDP load balancer operates within a single VPC network; distributing traffic to the network interfaces of backend VMs in that network.
• In these use cases, the backend services are the gateway VMs, gateway virtual appliances, multi-NIC gateways, and router VMs. Because these resources are all internal, it makes sense to access them through an internal TCP/UDP load balancer.

This use case load balances traffic from internal VMs to multiple network address translation (NAT) gateway instances that route traffic to the internet.

Another common use case is building hub and spoke topology with internal load balancers:

Benefits when the load balancer is a next hop for a static route:

• No special configuration is needed within the guest operating systems of the client VMs in the VPC network where the route is defined.
• Client VMs send packets to the load balancer backends through VPC network routing, in a bump-in-the-wire fashion.
• It also provides the same benefits as Internal TCP/UDP Load Balancing.

Cloud CDN

Cloud Content Delivery Network (CDN) caches content at the edges of the cloud provider network. This caching provides faster content delivery to users while reducing transmission costs.

In this example, the HTTP(S) load balancer has two types of backends. There are managed VM instance groups in the us-central1 and asia-east1 regions, and there’s a Cloud Storage bucket in us-east1. A URL map decides which backend to send the content to: the Cloud Storage bucket could be used to serve static content and the instance groups could handle PHP traffic.

When a user in San Francisco is the first to access content, the cache site in San Francisco sees that it can’t fulfill the request. This situation is called a cache miss. If content is in a nearby cache, Cloud CDN might attempt to get the content from it, for example if a user in Los Angeles has already accessed the content. Otherwise, the request is forwarded to the HTTP(S) load balancer, which in turn forwards the request to one of your backends.

Depending on the content that is being served, the request will be forwarded to the us-central1 instance group or the us-east1 storage bucket.

If the content from the backend is cacheable, the cache site in San Francisco can store it for future requests. In other words, if another user requests the same content in San Francisco, the cache site might now be able to serve that content. This approach shortens the round trip time and saves the origin server from having to process the request. This is called a cache hit.

Benefits of CDN:

• Reduce latency by delivering data through 600+ globally dispersed Points of Presence (PoPs) with automated network mapping and intelligent routing.
• Improve security with traffic encryption and access controls, and use AWS Shield Standard to defend against DDoS attacks at no additional charge.
• Cut costs with consolidated requests, customizable pricing options, and zero fees for data transfer out from origins.
• If using AWS CDN, it customizes the code you run at the edge using serverless compute features to balance cost, performance, and security.

In the article, we covered the load balancers that support external, internal and hybrid load balancing and an overview of the components that you must configure. We reviewed traffic management strategy based on URL map and how CDN improves performance and reduces costs.

I hope you like the topic. If yes, please follow me on Twitter and subscribe to our newsletter to be in touch with our latest network solutions.

Save your privacy, be ethical!