IBM Cloud Docs
Working with global load balancers

Working with global load balancers

IBM Cloud® DNS Services provides global load balancing as a service that offers you high availability and geographical distribution of your traffic, based on the health of your origin servers and the geographical region where the user request originates.

For example, in a DNS zone example.com, a DNS hostname of api.example.com is created as a global load balancer. The hostname api.example.com can resolve to different IP addresses based on the location of the requester and the health of the origins. If any or all of the origins (based on policy) are not available in one region, then healthy origins from different regions are returned in response to the DNS query. This ensures a high degree of availability of the hostname api.example.com. It also ensures that the load is geographically distributed among different origins and routed regionally.

Global load balancers limitations

The following limitations exist for the global load balancing feature.

  • You can have the following, per DNS Services instance:
    • Up to 100 health check monitors
    • Up to 100 health check subnets
    • Up to 100 origin pools
      • Each origin pool can have up to 5 origins
      • Each origin pool can use no more than 2 subnets for health monitoring
    • Up to 100 origins
  • Each DNS zone can have a maximum of 25 global load balancers
  • For cross account linked zone, the location policy is dictated by the owner account's VPC zone map.

Use cases and workflows

The most common use of global load balancers is to direct traffic to healthy origins and distribute loads.

The following workflows are performed from the DNS Services zone dashboard. Navigate to the Global load balancers tab to view your load balancersSoftware or hardware that distributes workload across a set of servers to ensure that servers are not overloaded. The load balancer also directs users to another server if the initial server fails., origin pools, and health checksA process that monitors system resources and conditions to determine whether the system is running efficiently. The health check can be configured to report potential problems and to display warnings and fail levels before the integrity of the system is compromised..

Creating a global load balancer with origin health monitoring

Creating a global load balancer with origin health monitoring combines high availability with geographic load balancing for mission-critical applications. This workflow ensures that traffic is routed only to healthy origins.

Follow this workflow to create a global load balancer with origin health monitoring:

  1. Create a health check.
  2. Create an origin pool and specify the health check to use.
  3. Create a global load balancer.

The HTTP and HTTPS health checks use the following HTTP user-agent: "Mozilla/5.0 (compatible; IBM-Cloud-DNS-Services/1.0; Health-Check/1.0; pool-id=12345678-1234-1234-1234-123456789012)". The pool-id is set as the load balancer pool for which the health check is configured.

Creating a global load balancer without origin health monitoring

In this configuration, DNS Services provides geographical load balancing based on the configured policy, but not high availability features.

After you create a DNS zone and add a permitted network to it, follow this workflow to create a global load balancer:

  1. Create an origin pool.
  2. Create the global load balancer.

Creating a health check

Create a health check to specify how the origin health is monitored. DNS Services supports HTTP, HTTPS and TCP monitoring types. After you create a health check, you can add it to a new or existing origin pool. Health checks exist at the instance level, and can be used by any pool in the instance.

If an origin is marked as unhealthy because of failed health checks, a single passing health check is sufficient to bring the origin back to a healthy state.

Follow these steps to create a health check:

  1. From the DNS Services navigation menu, click Global load balancers, then select the Health checks tab.

  2. Click Create health check to start.

  3. In the Health check name field, give your health check a name.

  4. Optionally, enter a Description for the health check to help you understand what it is monitoring.

  5. Select the Monitor type. Choose the protocol to use for the health check. Supported monitor types are HTTP, HTTPS, and TCP. The default value is HTTP. If HTTPS is selected, the Don't validate certificate checkbox appears after the Advanced options section. Select this box when the HTTPS certificate on the origin is not signed by a certificate authority (for instance, a self-signed certificate).

  6. Enter the endpoint Path against which to perform the health check. The default value is /.

  7. Optionally, enter the Port number that you want to use. For the health check to succeed, a relevant application must be running on the origin that responds to the health monitoring requests.

  8. In the Advanced settings section, select a Test interval (in seconds) between each health check. Shorter intervals can improve failover time, but increase load on the origins, because checks come from multiple locations. The default value is 60.

  9. Choose a Method to use for the health check from the list (HTTP and HTTPS only). The default value is GET.

  10. Select a Timeout interval (in seconds). The timeout interval is how long the health check waits before failing with a timeout error. The default value is 5.

  11. Select the Number of retries to attempt. Decide how many times the health check is tried before declaring that the origin health check has failed. Retries are attempted immediately. The default value is 1. TCP monitor type options end with this step. Click Create to save your changes and create the health check. HTTP and HTTPS monitor types have additional options, which follow.

  12. Enter the Expected response codes, which are the HTTP response codes or code range of the health check. This value must be between 200-299 with wildcards denoted by an x.

  13. Optionally, enter a Response body which is a case-insensitive substring to match against in the response body. If this string is not found, the origin is marked as unhealthy.

  14. In the optional Request headers section, you can add and configure HTTP request headers to send in the health check. Enter a header name and value in the fields provided. Click Add request header to configure additional headers.

  15. Click Create to save your changes and create the health check.

Adding an origin pool

Origin pools group your origins for the load balancer to use. An origin can be either an IP or a hostname. Decide whether you want to create a monitored or unmonitored origin pool. For monitored pools, you must specify the health check to use, and from which subnet the health is monitored. Origin pools exist at the instance level, and can be used by any global load balancer in any DNS zone that is configured in the instance.

Before you begin, keep the following considerations in mind when working with origin pools:

  • At least one origin pool is required for each load balancer.
  • Origin health monitoring continues even when an origin pool is disabled. To disable health monitoring on an origin, you can disable the origin.
  • When creating an origin pool, it can take 1 - 10 minutes for the health check to get initiated, during which time the pool appears in a Critical state.
  • You can't delete a subnet that you are using for health monitoring unless you remove the health check from the origin pool that you are monitoring.
  • If a hostname is provided as an origin in a pool, it can be an A, AAAA, or CNAME resource record, as well as another load balancer. However, you might see slower performance when resolving long CNAME chains or load balancers.

You must update your VPC security group to allow traffic from the health monitoring subnet. See Security groups for more information.

To create an origin pool, follow these steps:

  1. From the DNS Services navigation menu, click Global load balancers, then select the Origin pools tab.

  2. Click Create origin pool. Pools are enabled by default.

    Disabling a pool causes any load balancer that uses it to fail over to the next pool, if any. Disabled pools do not receive traffic.

  3. Enter a Name for the pool. Only alphanumeric characters, hyphens, and underscores are allowed.

  4. Optionally, enter a Description for the origin pool.

  5. Enable Origins to add to the list of origins within this pool.

  6. Give the origin a Name and Address. Click Add to add more pools, and move the toggle to switch the pool off or on. Traffic that is directed at this pool is balanced across all currently healthy origins, provided that the pool itself is healthy. Health checks exclude disabled origins.

  7. Select the Healthy origin threshold, which is the minimum number of origins that must be healthy for this pool to serve traffic. If the number of healthy origins falls below this number, the pool is marked unhealthy and fails over to the next available pool. The default value is 1.

  8. In the Health monitoring section, select a Health check to determine what method the health check uses, as well as the health check to use for checking origins within this pool. The default value is no health check.

  9. Select a Health check region from which the health check performs monitoring. Options are Dallas, Frankfurt, London, Madrid, Osaka, Sao Paulo, Sydney, Tokyo, Toronto, Washington, DC, and Paris (Paris is available only for restricted users).

  10. Select the VPC that contains the subnet from where the health check originates.

  11. Choose a Subnet (Location). Select a subnet and location from the list menu. This defines from which subnet the health check is running. You can specify up to two subnets.

  12. Click Create to save your changes and create your origin pool.

When you first create an origin pool, its status is Critical and the origin's status is Down because the initial health check has not completed yet. The status updates after the health check for the origin completes successfully.

Status definitions

The following table describes the possible statuses that you might see in your origins, origin pools, and global load balancers.

Status definitions for origins, origin pools, and global load balancers
Feature Status Definition
Origin up down Up: The origin is functioning normally.
Down: The origin is down.
At least 50% of the origin's health checks must be up for origin health to remain healthy.
Origin pool healthy degraded critical Healthy: All of the origins in the pool are up.
Degraded: At least one origin status is down.
Critical: The number of healthy origins in the pool is less than the healthy origin pool threshold. For example, if your threshold is 2, and only one origin is up, the pool status is Critical.
Global load balancer healthy degraded critical Healthy: All the origin pools that are associated with the global load balancer are healthy.
Degraded: At least one of the origin pools is in degraded status.
Critical: The global load balancer status is critical when all of the origin pools associated with the global load balancer are critical.

The fallback pool status is not taken into account for assessing the health of the global load balancer.

Security groups

Update the security group of the VPC to allow incoming health check traffic from the IP address that the health checker on the health monitoring subnet is using. Currently, this can be done by allowing traffic for the whole subnet CIDR.

Creating a global load balancer

Load balancers help to distribute your traffic across multiple origin pools.

Follow these steps to create a load balancer:

To set up a global load balancer, you must first create an origin pool.

  1. From the DNS Services navigation menu, click Global load balancers, then select the Load balancers tab.
  2. Select a DNS zone from the list.
  3. Click Create load balancer.
  4. Enter the DNS Balancer hostname to associate it with your load balancer.
  5. Optionally, enter a Description for the global load balancer.
  6. Select the TTL (time-to-live) of the DNS entry for the IP address returned by this load balancer.
  7. Add or select a Default policy. A default policy specifies which origin pools are used for all availability zones (AZ) for which a location-based policy is not specified. When multiple pools are selected within a policy, you can change their priority by using the arrow keys in the Priority column.
  8. Add or select a Fallback policy. A fallback policy specifies the origin pool to use when all other origin pools in the default or location policy are in a critical state. There can be only one origin pool in the fallback policy.
  9. Optionally, add or select a Location policy. The location policy allows you to associate one or more origin pools for a specific AZ. Any AZ that is not explicitly defined as a location policy uses the default policy.

How DNS resolvers prioritize global load balancing pools

The DNS resolver uses the following order to return origins from the origin pool.

Location policy > Default policy > Fallback policy

The location policy (if one is defined in the AZ), has the highest priority and is used first. If every origin pool in the location policy is down, then the DNS resolver uses origin pools from default policy. If all of the origin pools in the default policy are also down, then the DNS resolver goes to the origin pool designated in the fallback policy.

How DNS resolvers handle resource record TTLs for DNS responses

As noted earlier, if an origin's address is a hostname, then this hostname can represent the name to an A, AAAA, or CNAME resource record. In these scenarios, a DNS query resolved using a global load balancer might require the resolver to consider multiple resource records at the same time.

When the DNS resolver responses to a query, it chooses the lowest TTL observed among the set of resource records considered and the TTL configured on the global load balancer itself as the TTL for the resource records in the response.

The resulting DNS response that is based on a global load balancer might only contain the necessary A or AAAA records, referring to the load-balanced IP addresses. However, the configuration of other items that a global load balancer depends on can also affect the TTL in the DNS response. This is especially true when there are origins with an address which refers to a CNAME resource record that is part of a CNAME chain to the desired A or AAAA resource record.

There might be other scenarios where an origin's address refers to a resource record, or leads to a chain of other resource records, configured on a different DNS zone on the public internet. As a result, some resource records considered by DNS resolvers can come from other, upstream DNS resolvers. If an upstream DNS resolver's cached resource records contains a lower TTL in its cache as a result of its particular caching method, then the minimum TTL observed among all considered resource records might be pushed lower. This results in a DNS response that contains resource records with TTLs lower than the maximum expected duration.

Viewing, editing, or deleting components of a global load balancer

To view, edit or delete a load balancer, or one of its components, click an action from the overflow menu overflow icon on the table row of the load balancer.

The following options are provided for each list.

  • Health Checks

    • Edit health check - Redirects to the edit flow.
    • Delete health check - Shows the confirmation dialog box for the deletion flow.

  • Origin Pools

    • Edit pool - Redirects to the edit flow.
    • Delete pool - Shows the confirmation dialog box for the deletion flow.

  • Load Balancers

    • Edit load balancer - Redirects to the edit flow.
    • Delete load balancer - Shows the confirmation dialog box for the deletion flow.