Global load-balancing architectures using DNS routing policies

Last reviewed 2023-01-04 UTC

This document describes how you can combine multiple regional load balancers with Google DNS routing policies to create global load-balancing architectures. The document is aimed at network engineers, solutions architects, and operations professionals. It assumes that you have basic knowledge of Google Compute Engine and are familiar with networking concepts such as load balancers and DNS lookups.

Introduction

When you're building a global service that's implemented as an application running in multiple regions, you can use geolocation DNS routing policies to have a global DNS endpoint for your regional load balancers. In this approach, you create a global endpoint that routes traffic to the closest local service.

Depending on the type of load balancer you're using, you might be able to achieve this scenario with global proxy-based load-balancing options. However, for some use cases, you must use regional load-balancing products—for example, if your service is serving UDP traffic. Geolocation DNS routing policies can also help with providing a single DNS endpoint for hybrid applications that use Google Cloud alongside other cloud service providers or alongside an on-premises deployment.

Architecture

The following diagram shows a sample architecture that uses three regional load balancers in three different regions. The regions are combined using DNS routing policies.

Architecture where Cloud DNS routes traffic to a regional internal load balancer based on where the client is.

The preceding diagram shows how clients in Oregon, Germany, and Singapore do DNS lookups to Cloud DNS for www.example.com. Requests are routed to regional load balancers that are close to each client to reach an application that's hosted in three different regions.

Use cases for geolocation DNS routing policies

This section discusses the following use cases for using geolocation DNS routing policies to create a global service out of multiple regional load balancers:

A globally accessible and globally distributed internal service
A global DNS endpoint for an external service that supports TCP and UDP
A global DNS endpoint for a hybrid service

A globally accessible and globally distributed internal service

You can create a globally accessible and globally distributed internal service by combining multiple regional internal load balancers using geolocation DNS routing policies. You can use either an internal passthrough Network Load Balancer or an internal Application Load Balancer. Without DNS routing policies, an internal Application Load Balancer can use only regional endpoints. With an internal passthrough Network Load Balancer that uses global access, you can have your service available globally; in that case, backends can be in only a single region. However, when you use DNS routing policies, you can have backends in multiple regions.

The following diagram shows this architecture:

Architecture for internal clients where Cloud DNS sends traffic to the internal passthrough Network Load Balancer instance that's in the region where the client is.

The previous diagram shows how internal clients in multiple regions resolve service.corp.example.com using Cloud DNS. Clients always receive a response that has an IP address that belongs to an internal passthrough Network Load Balancer that's in the client's region. The load balancer points to an application that's in the same region. (In this example, the application runs on Google Kubernetes Engine (GKE), but that's not a necessary condition.) Clients send application traffic to a local instance of the application, but they all use the same service.corp.example.com DNS endpoint.

You can create this configuration by using the following steps:

You create the internal load balancers in each region. If you use an internal passthrough Network Load Balancer, you must enable global access to ensure that clients from other regions can connect to the service.
You create a DNS routing policy. In the policy, you set the type to GEO and you set the --routing-policy-data value to a list of target regions that are mapped to the corresponding internal load balancer. You can create the setup that's illustrated in the diagram by using the following command:
```
gcloud beta dns record-sets create service.corp.example.com \
    --ttl=30 \
    --type=A \
    --zone=my-zone \
    --routing-policy-type=GEO \
    --routing-policy-data="europe-west4=fr-eu-w4;asia-east1=fr-as-e1;us-central1=fr-us-c1" \
    --enable-health-checking
```

In the example, a record is created with a TTL value of 30 seconds to ensure that clients refresh the DNS records frequently in case the policy changes.

When you use DNS routing policies, each client receives a DNS response that contains the IP address of the in-region internal load balancer. If the client is outside of a region where internal load balancers are defined, it receives the IP address of the internal load balancer that's in the closest region.

DNS routing policies route traffic based on the closest internal load balancer region. If more than 80% of backends in that region are unhealthy, and if you're using the health checking feature with geographical DNS routing policies, traffic fails over across regions.

If you don't require failover between regions, you can change the command as follows:

Remove the --enable-health-checking flag.
Replace the name of each forwarding rule for the internal load balancer with its IP address.

A global endpoint for an external service that supports TCP and UDP

You can also create a global DNS endpoint for an external service by combining multiple regional external load balancers using geolocation DNS routing policies. The most common use case is using an external passthrough Network Load Balancer for any TCP-based or UDP-based application. This approach is especially useful for applications that use UDP, because no global load-balancing option is available on Google Cloud for UDP.

For applications that use TCP traffic that are supported by the external proxy Network Load Balancer or the external Application Load Balancer, you might be able to use instances of those global load balancers instead of using a DNS endpoint. These load balancers provide cross-region load balancing using anycast, which provides a single IP address as the frontend for all of your backend instances.

The advantages of using global load balancing options over the DNS endpoint are the following:

Failover is immediate. Failover happens with no visible change in traffic flow from the user side.
Internet routing determines the load-balancing target. Internet routing protocols forward traffic based on the shortest path, instead of Cloud DNS choosing a target location.
Cross-region load balancing. Google's global load balancing supports cross-region failover. In contrast, there's no health checking with DNS routing policies when you use an external passthrough Network Load Balancer.

Therefore, we recommend that you use Google's global load balancing option when your application is TCP-based and is supported by those products.

The following diagram shows the architecture using a global DNS endpoint:

Architecture for external clients where the clients get an IP address for the internal passthrough Network Load Balancer instance that's in the region where the client is.

The preceding diagram shows how external clients in multiple regions resolve www.example.com using Cloud DNS. Clients receive a response with an IP address that belongs to a network TCP/UDP load balancer that's in the client's region. The client can then connect to an application that's running in that same region. Each client sends application traffic to a local instance of the service, but they all use the same www.example.com DNS endpoint.

You can create this configuration by using the following steps:

You create the network TCP/UDP load balancers in each region.
You create a DNS routing policy. In the policy, you set the type to GEO and you set the --routing-policy-data value to a list of target regions that are mapped to the corresponding network TCP/UDP load balancer. You can create the setup that's illustrated in the diagram by using the following command:
```
gcloud dns record-sets create www.example.com \
    --ttl=30 \
    --type=A \
    --zone=my-zone \
    --routing-policy-type=GEO \
    --routing-policy-data="europe-west4=192.0.2.5;asia-east1=198.51.100.10;us-central1=203.0.113.33"
```

After you apply this policy, when clients make DNS requests, each client receives a DNS response that contains the IP address of the external passthrough Network Load Balancer that's in the region that's closest to that client.

The global endpoint www.example.com can't be used to automatically perform failover for traffic between regions, because when you use an external passthrough Network Load Balancer, there's no health checking. It's your responsibility to manually trigger failover by changing DNS records.

Another use case that you can address with this approach is that you have an application using HTTP(S) with regionality requirements for your data, but you still want to serve data using a global endpoint. You can implement this scenario by combining multiple regional external Application Load Balancer instances using geolocation DNS routing policies. If you don't have regionality requirements, you can use a global external Application Load Balancer.

A global DNS endpoint for a hybrid service

In some cases, you can provide a single endpoint for a hybrid application by using geolocation DNS routing policies.

The following diagram shows this architecture:

Architecture for a hybrid scenario where Cloud DNS sends traffic to the internal passthrough Network Load Balancer instance for clients that are in Asia and in the USA, and to a load balancers that's on-premises for clients that are in Europe.

The preceding diagram shows how external clients in multiple regions resolve www.example.com using Cloud DNS. Cloud DNS points internet users in Asia and in the USA to an IP address that belongs to a network TCP/UDP load balancer that's in a region close to them. The application that the load balancer points to is running on GKE in the same region. For internet users in Europe, Cloud DNS returns an IP address that points to a load balancer in a European on-premises data center, with the application hosted on GKE on VMware. (In this example, the applications run on GKE on VMware and on GKE, but that's not a necessary condition.)

You can create this configuration by using the following steps:

You create the network TCP/UDP load balancers and the on-premises load balancer in each region.
You create a DNS routing policy. In the policy, you set the type to GEO and you set the --routing-policy-data value to a list of target regions that are mapped to the corresponding network TCP/UDP load balancer. You can create the setup that's illustrated in the diagram by using the following command:
```
gcloud dns record-sets create www.example.com \
    --ttl=30 \
    --type=A \
    --zone=my-zone \
    --routing-policy-type=GEO \
    --routing-policy-data="europe-west4=192.0.2.51;asia-east1=198.51.100.10;us-central1=203.0.113.33"
```

By setting the --routing-policy-data flag, you can have Cloud DNS return different IP addresses based on the closest Google Cloud region. However, you can't route traffic based on the exact country or geographical region of the client. In the preceding example, most users are sent to a region or to the on-premises data center that's on their continent. However, the algorithm that Cloud DNS uses to determine the closest Google Cloud region might not align with specific country or geography boundaries. You therefore can't use geolocation DNS routing policies for compliance use cases.

Other use cases that require more granularity than the continent-level granularity shown in this example aren't possible with this hybrid approach. For example, in cases where you might have an on-premises data center in a country where no Google Cloud region exists, it's not possible to send traffic on-premises for users from that country or region—you can only configure the load balancer to return IP addresses based on the closest Google Cloud region. If you want to restrict or route traffic based on exact geographical location or country, you can use a third-party provider that offers a DNS-based global server load-balancing (GSLB) service.

What's next

Manage DNS routing policies.
DNS best practices.
Load balancer features.
Optimizing application latency with load balancing.
For more reference architectures, diagrams, and best practices, explore the Cloud Architecture Center.